Security
How Passura is built
What protects credentials and sessions today, stated at the level of detail an engineer can check — and an honest account of what is not in place yet.
Measures in place
Password hashing
Passwords are hashed with Argon2id at the OWASP 2024 minimum parameters or above. The plaintext is never stored, never logged, and never leaves the request that supplied it. New passwords are checked against known-breached credential corpora before being accepted.
Session and refresh-token handling
Refresh tokens rotate on every use within a token family. If a token that has already been rotated is presented again — the signature of a stolen token being replayed — the entire family is revoked immediately, ending both the attacker’s session and the legitimate one. Rotation is settled under a conditional update, so two concurrent refreshes cannot both succeed.
Encryption of sensitive fields
TOTP seeds and tenant OAuth client secrets are encrypted with AES-256-GCM before they reach the database, with additional authenticated data binding each ciphertext to the user or tenant it belongs to, so a row moved between records fails to decrypt. Keys are versioned to allow rotation without downtime.
Encryption in transit
All traffic is served over TLS, with certificates issued by Let’s Encrypt and renewed automatically over the ACME DNS-01 challenge. There is no unencrypted listener.
Rate limiting
Authentication endpoints — login, signup, code request, code verification, and token refresh — are rate limited per client against a shared Redis store, so limits hold across every API replica rather than per process.
Tenant isolation
Every data-bearing route is scoped to a tenant resolved from the request path, and queries are constrained to that tenant. Soft-deleted tenants and users resolve as absent rather than as accessible records.
Data residency
Customer and end-user data is stored on OVHcloud infrastructure in Gravelines, France. Sub-processors, including those established outside the EU, are disclosed in full.
Reporting a vulnerability
If you believe you have found a security vulnerability in Passura, report it to PENDING — confirm before launch. Include enough detail to reproduce the issue. A machine-readable version of this policy is published at /.well-known/security.txt.
What you can expect: acknowledgement within three working days.
What we ask: give us a reasonable window to fix the issue before disclosing it publicly, do not access or modify data belonging to anyone else, and do not run automated scanning that degrades the service for other users. Testing against your own tenant is fine.
We do not currently run a paid bug bounty. We will credit reporters who want to be credited.
What we do not have yet
Silence about certifications reads worse than an honest roadmap, so here is the state of things. Passura is in closed beta and operated by a single person.
- No SOC 2 or ISO 27001. Neither is in progress. Both are planned once the service is generally available and there is revenue to fund an audit, in that order.
- No third-party penetration test. The codebase has not been reviewed by an external security firm. This is the first item on the list above, because it is the one that would change our confidence rather than just our paperwork.
- No published uptime history. There is no status page yet. Until there is, we will not make an availability claim.
- Host-level disk encryption is not asserted. Sensitive fields are encrypted by the application before they are written, as described above. We do not additionally claim full-disk encryption on the host, because we have not verified it end to end.
If any of these is a blocker for your procurement process, say so at PENDING — confirm before launch. We would rather tell you Passura is not ready for you yet than have you find out during an audit. Passura is operated by PENDING — confirm before launch.