Security and trust, by architecture.

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. Plaintext is never persisted, logged, or forwarded to AI providers or sub-processors.
• Tenant isolation. Every multi-tenant table enforces row-level security keyed on tenant_id. Cross-tenant reads are structurally impossible from the application layer.
• Bring Your Own Key (BYOK). Tenant signing keys (P-256 ECDSA for VC issuance) are generated and rotated under the tenant's control. We do not hold keys we do not need.
• Cryptographic erasure. The Purpose-Bound PII Vault stores AES-256-GCM ciphertext keyed per tenant. Deleting the key renders the data unrecoverable, satisfying GDPR Article 17 even when backup copies exist.
• Vault-keyed evidence intake. Contact details submitted through the public SOC 2 evidence-request form are encrypted at rest with AES-256-GCM 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 sessions, admin mutations, and DSAR shredding events are written to immutable audit tables. Records are never deleted.

Cryptography

• In transit. TLS 1.3 with modern cipher suites enforced at every public endpoint and Cloudflare edge.
• 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. Hybrid ML-DSA-65 (NIST FIPS 204) co-signs identity assertions alongside a classical HMAC-SHA-256 layer, providing forward security against future quantum adversaries. ML-DSA-87 (Category 5, highest NIST PQC strength) is available as an Enterprise add-on and is production-deployed for tenants with extended cryptographic-horizon requirements.
• Entropy. QRNG-seeded entropy is available on Enterprise for cryptographic key material. All other key generation uses platform CSPRNGs.
• DPoP. RFC 9449 sender-constrained tokens with server-issued nonces and one-time-use proof consumption. A shadow-telemetry mode captures coverage metrics through the api-key-auth chokepoint without rejecting unbound traffic, with a 15-minute re-attestation 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. Inbound CAEP events dispatch directly into the in-process revocation cascade on the same request, with 24-hour jti idempotency caching and signature verification against configured Transmitter JWKs.
• BLAST tunnels. X25519 ECDH plus AES-256-GCM zero-transmission key agreement for sensitive Enterprise signal resolution.

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 daily and alerts on regressions.
• Internal pentest suite. An automated penetration testing suite (shield-pentest-suite) exercises authentication, RLS boundaries, SSRF surfaces, and rate limits on every release candidate.
• 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 at the edge prevent noisy-neighbor effects across plans. Outbound HTTP from edge functions flows through a safeFetch helper that enforces an egress allowlist, blocking SSRF and unauthorized data-exfiltration paths at the network boundary.
• Anomaly scanner. A platform-wide infrastructure scanner watches traffic surges, error-rate spikes, latency regressions, egress volume, cascade depth, and tenant-concentration anomalies, alerting on threshold breach.
• Canary mesh. Honeypot endpoints distributed across the edge surface record probe attempts to shield_canary_hits and dispatch SSRF-guarded Slack alerts when scanners or unauthorized clients touch them. End-to-end probes are run on demand by platform admins.
• 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. Sampled health snapshots for nine independently checked components persist to a public-read table and back the public /status page, with a 30-day retention window.

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). Identifiers that reach us already pre-hashed, and any legacy unkeyed digests, are the exception—they carry only the resistance of however they were originally computed.

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.

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 203 / 204. Hybrid post-quantum signatures align with the published NIST PQC standards.
• W3C VC 2.0 / OpenID4VP. Verifiable Credential issuance and presentation conform to the published specifications.
• ISO 27001. On the post-SOC 2 roadmap.

Patent portfolio

The platform's novel mechanisms (Atomic Fingerprints, hybrid post-quantum signatures, BLAST zero-transmission key agreement, and the Revocation Cascade) are protected by an active USPTO filing programme. The PBCORE non-provisional (App. No. 19/553,357) anchors a chain of 16 filings spanning continuation-in-part and standalone provisional applications.

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.

Full reporting guidelines are published in the repository's SECURITY.md.

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