Security and trust

Architectural commitments

These are properties of the system, enforced in code rather than policies layered on top of the product.

• Zero-PII at the edge. Phone numbers and other low-entropy identifiers (email and IP addresses, CAEP/SSE subject identifiers) are hashed with keyed HMAC-SHA-256 under a server-held pepper at the ingestion boundary, which makes them non-enumerable rather than merely digested. The plaintext is never stored or logged. A phone number leaves the platform only for a carrier lookup a tenant requests, to that lookup's provider; the sub-processor table below lists what each provider receives.
• Tenant isolation. Every multi-tenant table enforces row-level security keyed on tenant_id, so a dashboard session reads only its own organization's rows. Edge functions run with a service role that bypasses row-level security; each authenticates the tenant first and scopes every query to it in code.
• Bring Your Own Key (BYOK). A tenant can import its own EC P-256 or P-384 signing key for credentials and attestations; otherwise the platform generates one. Either way the private key is stored only as AES-256-GCM ciphertext. BYOK covers signing keys; it does not apply to the PII vault.
• Erasure. The Purpose-Bound PII Vault stores AES-256-GCM ciphertext under a single platform key, not per-tenant keys, so erasure is not done by deleting a key. A DSAR erasure tombstones the subject's rows: identifier columns are nulled and encrypted columns are overwritten.
• Vault-keyed evidence intake. Contact details submitted through the public SOC 2 evidence-request form are encrypted at rest with pgcrypto's OpenPGP symmetric encryption under a key held in the managed secrets vault. Decryption is gated through admin-only RPCs and the dedicated notification path; no other surface can read the plaintext.
• Append-only audit trails. Breakglass actions, admin mutations, and DSAR erasure events are written to the audit log, which no client can update or delete. The only changes to a row are clearing its IP digest and user agent after 90 days, and a row is removed only with its organization.

Cryptography

• In transit. TLS on every public endpoint and at the Cloudflare edge, negotiated at TLS 1.3 where the client supports it.
• At rest. AES-256-GCM for tenant secrets and PII vault payloads. Database storage is encrypted at the disk layer by the managed provider.
• Hashing. Keyed HMAC-SHA-256 under a server-held pepper for low-entropy personal identifiers (phone, email, IP, CAEP/SSE subject, behavioral fingerprints) so a leaked digest column cannot be reversed by enumeration. Plain SHA-256 for high-entropy secrets (API keys) and content/attestation digests, where enumeration is not a threat and content-addressability must be preserved. HMAC-SHA-256 for callback signing.
• Post-quantum signatures. Since August 8, 2026, credentials and attestations are signed by default with a classical ES256 (P-256 ECDSA) signature plus a detached ML-DSA-65 (NIST FIPS 204) signature over the same input. ML-DSA-87 (NIST Level 5), paired with ES384 on P-384, is an Enterprise add-on selected per tenant; tenants can opt into an older envelope that pairs HMAC-SHA-256 with ML-DSA. Post-quantum protection covers signatures only; encryption and key agreement remain classical.
• Entropy. A quantum-seeded generator (a QRNG seed mixed with local CSPRNG output, every draw health-tested per NIST SP 800-90B) produces the nonces bound into signed payloads, BLAST key-derivation salts and session identifiers. Keys and ML-DSA signing randomness do not come from it: they come from the platform CSPRNG or from key derivation.
• DPoP. RFC 9449 sender-constrained tokens with server-issued nonces and one-time-use proof consumption. A shadow-telemetry mode records whether each authenticated API request carries a well-formed DPoP header, without rejecting unbound traffic. DPoP applies no re-attestation interval; a separate re-attestation service tracks sessions, agents and API keys on a 15-minute cadence.
• SSF/CAEP. OpenID Shared Signals Framework 1.0 and Continuous Access Evaluation Profile 1.0 (both final, August 29, 2025) as Transmitter and Receiver. An inbound token must be signed under the configured Transmitter JWKS; an event reporting a revoked session, a credential revoked, rotated, compromised or deleted, or a non-compliant device then runs the in-process revocation cascade on the same request, a token issued more than 24 hours earlier is refused, and redelivered tokens are deduplicated on issuer, jti and event type.
• BLAST tunnels. X25519 ECDH key agreement, so the session key itself is never transmitted, plus AES-256-GCM, for delivering shadow proxy values (Enterprise).

Implementation detail is published in our technical whitepaper and the public Software Design Specification.

Operational security

• Least-privilege CI. GitHub Actions workflows pin third-party actions to commit SHAs and request the minimum permissions required for each job.
• Dependency auditing. Every pull request runs a high-severity dependency audit. A separate live-monitoring workflow re-runs the audit every two hours and alerts on regressions.
• Internal pentest suite. An automated penetration-testing suite runs weekly against production: anonymous reads and writes against row-level security, authentication fuzzing of edge functions, sensitive-column exposure, cross-tenant reads, admin-scope escalation, and secret configuration checks. A probe that cannot run is reported as not executed, never as a pass.
• Bundle integrity. Production builds are post-build scanned to block accidental inclusion of internal hostnames, debug emojis, or hardcoded credentials.
• Breakglass protocol. Emergency access requires multi-party approval with severity-based thresholds. Self-approval is structurally prevented and every session is time-bounded.
• Per-tenant quotas & egress allowlist. Per-tenant request quotas, set by plan and counted in the database on each request, prevent noisy-neighbor effects. Outbound HTTP from edge functions to vendors flows through a safeFetch helper that enforces an egress allowlist and refuses private destinations before any connection is made.
• Anomaly scanner. A platform-wide infrastructure scanner runs hourly and watches traffic surges, error-rate spikes, latency regressions, egress denials, revocation cascade runs, and tenant-concentration anomalies, recording each threshold breach in the platform audit log for operator review.
• Canary mesh. Honeypot canary endpoints with webhook alerting record probe attempts to shield_canary_hits and, for a real hit, post to the operator alert webhook. An end-to-end probe of the mesh runs every four hours and on demand from the admin console. That probe is synthetic and does not post.
• Function-status observability. Per-status-code edge function metrics surface 4xx/5xx ratios for the top instrumented functions in the admin dashboard, with synthetic traffic excluded from the per-status breakdown.
• Public status snapshots. Snapshots of the platform health check, written every 15 minutes, persist to a public-read table and back the uptime history on the public /status page, with a 13-month retention window; the page's nine component rows are checked live from the visitor's browser.

Privacy & data residency

Because primary identifiers are keyed-hashed at the edge, the data we subsequently store cannot be reversed to a person without the server-held pepper, which lives outside the database. This is intentional and materially reduces the impact of any subprocessor exposure or cross-border transfer concern (including the considerations raised by Schrems II/III). A digest a tenant computes itself is keyed the same way before it is stored, and the digests written before the keyed scheme shipped were keyed in place on October 1, 2026, so no stored identifier digest carries only the resistance of plain SHA-256.

We act as a data processor under GDPR and PIPEDA. The full Data Processing Addendum is incorporated into our Terms of Service §10 and is available for execution as a standalone DPA on request to dpo@passkeybridge.io.

AI connector (MCP)

An organization's administrator can let an AI client that supports the Model Context Protocol, such as Claude or Grok, read the organization's security data. Nothing is shared until an administrator approves a client, and the client can change nothing.

• Approval. OAuth 2.1 with PKCE (S256). The administrator approves on our consent page, which shows the client's name, the host it returns to and what it may read, and confirms with a fresh passkey check. An administrator without a registered passkey cannot approve.
• What a client can read. Signal counts, audit events (action, time, actor type, resource type and result), fired alerts, posture findings, passkey coverage counts and pending recovery requests. Never names, email addresses, phone numbers, IP addresses or user IDs; rows are referred to by keyed HMAC-SHA-256 references. Passkey coverage and pending recovery counts from 1 to 4 are withheld, and an organization with fewer than 5 active members gets no coverage counts.
• No database credential at the edge. The connector runs on Cloudflare and holds no database key. Every request for data goes to one edge function that finds the organization from the approval record, checks that the approval is live, that the approving administrator is still an administrator and that the organization is neither closed nor quarantined, and allows 60 requests per minute per approval.
• Tokens. Authorization codes last 2 minutes and work once. Access tokens last 30 minutes. Refresh tokens last 30 days, never past the approval, and rotate on every use; presenting a used one revokes the whole approval. Codes and tokens are stored only under a keyed HMAC-SHA-256 digest.
• Revocation and audit. An approval lasts at most 90 days. Any administrator can revoke it under Settings, AI connectors, and the client's next request for data is refused. Every approval, request and revocation is written to the organization's audit log.

Sub-processors

The following providers process tenant-related data on our behalf. We give 30 days' notice before engaging a new sub-processor.

Compliance posture

• GDPR & PIPEDA. Data Processing Addendum incorporated into Terms §10; DPO contactable at the address below.
• WCAG 2.2 AA. Public surfaces target WCAG 2.2 AA, including reduced-motion respect and skip-to-content affordances.
• NIST FIPS 204. Hybrid post-quantum signatures use ML-DSA as published in FIPS 204. ML-KEM (FIPS 203) is not implemented; key agreement is X25519 ECDH.
• W3C VC 2.0 / OpenID4VP. Verifiable Credential issuance and presentation implement the published specifications (JWT-VC and SD-JWT-VC credentials, OpenID4VP presentation exchange). No conformance certification is claimed.
• ISO 27001. Readiness only: controls are designed against ISO 27001 criteria. No audit firm is engaged yet and no audit is scheduled.

Patent portfolio

The platform's novel mechanisms (Atomic Fingerprints, hybrid post-quantum signatures, BLAST zero-transmission key agreement, and the Revocation Cascade) are the subject of an active USPTO filing programme. 20 US patent applications filed (7 non-provisional, 13 provisional). No patent has been granted.

The full register, family tree, and per-claim novelty review (intended for counsel, investors, and enterprise security buyers conducting diligence) is published at /patents.

Vulnerability disclosure

We welcome coordinated disclosure. Please report suspected vulnerabilities to security@passkeybridge.io. We acknowledge reports within one business day and aim to triage within five. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service degradation, and give us a reasonable window to remediate before public disclosure.

Include a description of the issue and its impact, steps to reproduce, and the affected endpoint. Do not test against production tenants you do not own; denial-of-service testing and social engineering are out of scope. Contact details are also published at /.well-known/security.txt.

Incident & breach response

On confirmation of a personal-data breach we notify affected customers without undue delay and within 72 hours of becoming aware, in line with GDPR Article 33. Notifications include the nature of the breach, the categories of data involved, the likely consequences, and the remediation steps taken.

Operational incidents (degraded availability, latency excursions, regional carrier outages) are surfaced in real time on the public status page.

Contact