Privacy Policy

PasskeyBridge LLC is a Wyoming limited liability company located at 5830 E 2nd St., Ste 7000 #33652, Casper, WY 82609 that operates the PasskeyBridge™ platform at passkeybridge.io. For the purposes of GDPR, we act as a data processor for orchestrated signal data and a data controller for tenant account data.

This Privacy Policy applies to all users worldwide and is designed to comply with:

• GDPR (EU General Data Protection Regulation)
• PIPEDA (Canada's Personal Information Protection and Electronic Documents Act)
• CCPA/CPRA (California Consumer Privacy Act / California Privacy Rights Act)

Where this policy refers to "personal information," we include all data classified as personal under GDPR, PIPEDA, or CCPA.

We process personal information under the following lawful bases:

• Contract performance (Art. 6(1)(b)): Processing account data to provide the Service.
• Legitimate interests (Art. 6(1)(f)): Security logging and fraud prevention.
• Consent (Art. 6(1)(a)): Marketing communications (opt-in only).
• Legal obligation (Art. 6(1)(c)): Tax and billing records.

• Email address (for authentication and notifications).
• Organization name (for tenant identification).
• Payment information (processed by Stripe; we do not store card details).
• IP addresses and user agents in audit logs (anonymized after 90 days).

• Phone numbers are hashed with keyed HMAC-SHA-256 (server-held pepper, E.164-normalized) before storage. Raw values are never written to disk.
• Verifiable Credentials issued via our self-hosted engine or third-party providers are never cached on our servers. The VC Wallet SDK stores credentials locally on the user's device (IndexedDB). Only SHA-256 hashed subject identifiers are transmitted during verification.
• Biometric data remains on the user's device. Only public keys and credential IDs are transmitted.
• Device fingerprints (ambient magnetic field, accelerometer motion, network jitter, and a coarse thermal-state signal) are SHA-256 hashed on-device before storage. Raw sensor data is never persisted.
• Hosted passkey relying party. When a tenant runs its passkey ceremonies through our hosted relying-party service, we hold for each of that tenant's end users the WebAuthn credential public key, credential identifier, signature counter, transports, authenticator model identifier (AAGUID) and backup state, and a keyed HMAC-SHA-256 digest of the tenant's user handle, namespaced per tenant and relying party under the server-held pepper. We never hold the handle itself, a name, an email address or any biometric; the tenant keeps the mapping between its users and their handles. In-flight ceremony challenges are single-use and deleted after five minutes.
• Carrier lookups. When a tenant asks for carrier intelligence on a phone-based signal, the phone number is sent to the carrier-data provider for that one lookup (Twilio or Vonage, section 10) and is not stored by us; the result is kept under the number's keyed digest only.

We use your account data to authenticate access, process billing, send transactional emails, provide support, and improve the Service. We do not sell your data. We do not use your data for profiling or automated decision-making.

• Account data: retained for account duration, deleted within 30 days of account closure.
• Signal event logs: 90-day retention, then purged.
• Audit log PII (IP addresses, user agents): anonymized automatically after 90 days via scheduled database function. IPs are zeroed and user agents are truncated.
• Usage records: 12-month retention for billing.
• Hosted passkey credentials: kept until the tenant deletes the credential or the user through the API, or until the tenant's account closes (deleted within 30 days). Ceremony challenges are deleted after five minutes.

PasskeyBridge™ infrastructure is hosted in the United States. If you are located in the EU/EEA, UK, or Canada, your data is transferred to the US. We rely on:

• Standard Contractual Clauses (SCCs) for EU/EEA and UK transfers.
• PIPEDA adequacy recognitions and contractual safeguards for Canadian transfers.

Our zero-PII architecture significantly reduces the risk of international transfers, as no plaintext personal data is stored.

PasskeyBridge™ uses only strictly necessary cookies for authentication session management. We do not use analytics cookies, advertising trackers, or third-party tracking scripts. No consent banner is required under GDPR Article 5(3) as only essential cookies are used.

We use the following sub-processors:

• Stripe, Inc.—Payment processing (San Francisco, CA, USA).
• Supabase, Inc.—Primary database, authentication, and edge-compute hosting (San Francisco, CA, USA).
• Vercel, Inc.—Frontend application hosting and content delivery (San Francisco, CA, USA).
• Cloudflare, Inc.—Edge proxy, WAF, rate-limiting, and edge caching for all API and site traffic (San Francisco, CA, USA).
• Resend, Inc.—Transactional and operational email delivery (contact-form, daily-sweep, marketing notifications) (San Francisco, CA, USA).
• Twilio Inc.—Carrier lookup for phone-based signals when a tenant requests it. Receives the phone number for that lookup only; we do not store it (San Francisco, CA, USA).
• Vonage Holdings Corp.—Number Insight carrier lookup for phone-based signals when a tenant requests it. Receives the phone number for that lookup only; we do not store it (Holmdel, NJ, USA; global endpoints).
• Anthropic, PBC—Asynchronous risk analysis on hashed signal metadata. No plaintext identifier is sent (San Francisco, CA, USA).
• Anthropic, PBC—AI risk analysis for the Intelligence Layer and internal operations/agent tooling (San Francisco, CA, USA). Only hashed, anonymized signal metadata is transmitted; no plaintext PII.

We will notify you of changes to sub-processors with 30 days' notice.

• TLS 1.3 for data in transit.
• AES-256 for data at rest.
• SHA-256 hashed API keys and identifiers.
• HMAC-SHA256 signed callbacks.
• Row-Level Security (RLS) for tenant isolation.
• Column-level access controls on sensitive fields.
• Append-only audit trail (no client UPDATE/DELETE).
• Hybrid Post-Quantum Cryptography (PQC): Enterprise tenants may enable hybrid signatures pairing classical P-256 ECDSA (ES256) with ML-DSA-65 (NIST FIPS 204), ensuring cryptographic resilience against future quantum computing threats. PQC signatures protect cross-references, cached identity proofs, and A2A handshake attestations. Tenant signing keys use per-tenant P-256 ECDSA key pairs with AES-256-GCM encrypted private keys and 24-hour rotation grace periods for in-flight verification continuity.
• Bulk PII Migration: Legacy plaintext columns (email, display name) are encrypted via AES-256-GCM in auditable batches. After verifying 100% encryption coverage, plaintext is permanently shredded (set to NULL) on manual admin confirmation. Every migration run is logged with operator ID, row counts, and error details.
• Purpose-Bound PII Vault (PBPBV): Dual-path cryptographic storage (AES-256-GCM ciphertext + independent SHA-256 hashes) with auditable purpose-coded decryption gates. Every decryption requires a declared purpose code logged in an immutable audit trail. Tenant-isolated Bring-Your-Own-Key model enables cryptographic erasure—destroying a tenant's key renders all their PII permanently unrecoverable. PII is never stored or retained in application memory beyond the encryption/decryption operation.
• BLAST Protocol: End-to-end encrypted signal resolution tunnels using X25519 ECDH key agreement and AES-256-GCM, with QRNG-seeded entropy for session key material.
• Shadow Proxy: Disposable email and phone proxies forwarded through encrypted relays. Real contact information is never exposed to third parties.
• Observability: Structured metrics, anomaly detection, and alerting pipelines process only aggregated, anonymized signal metadata. No PII is included in metric payloads or alert dispatches.
• Okta ISPM: Okta API tokens used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Tokens are never logged, cached beyond the request lifecycle, or transmitted to third parties. ISPM checks query aggregate Okta org statistics (user counts, policy configurations, factor enrollment rates)—individual user identifiers from the Okta API are not persisted.
• Entra ID ISPM: Microsoft Entra ID client secrets used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Authentication uses the OAuth 2.0 client credentials flow against the Microsoft Graph API with read-only permissions. ISPM checks query aggregate Entra ID tenant statistics (user counts, Conditional Access policy configurations, role assignments)—individual user identifiers from the Graph API are not persisted.
• Google Workspace ISPM: Google Workspace service account private keys used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Authentication uses service account JWT with domain-wide delegation against the Google Admin SDK. ISPM checks query aggregate Workspace statistics (user counts, 2SV enrollment rates, admin role assignments, domain verification status)—individual user identifiers from the Admin SDK are not persisted.
• AWS IAM Identity Center ISPM: AWS access keys used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Authentication uses AWS Signature Version 4 against the SSO Admin, Identity Store, and IAM APIs with read-only permissions. ISPM checks query aggregate IAM Identity Center statistics (user counts, permission set configurations, account assignment coverage)—individual user identifiers from the AWS APIs are not persisted.
• PingOne ISPM: PingOne client secrets used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Authentication uses the OAuth 2.0 client credentials flow against the PingOne Management API with region-specific endpoint resolution. ISPM checks query aggregate PingOne environment statistics (user counts, MFA policy configurations, population management)—individual user identifiers from the PingOne API are not persisted.
• CyberArk Identity ISPM: CyberArk Identity client secrets used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Authentication uses the OAuth 2.0 client credentials flow against the CyberArk Identity Platform API. ISPM checks query aggregate tenant statistics (user counts, role configurations, MFA profile settings, PAM policy status)—individual user identifiers from the CyberArk API are not persisted.
• OneLogin ISPM: OneLogin client secrets used for Identity Security Posture Management scans are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Authentication uses the OAuth 2.0 client credentials flow against the OneLogin Admin API v2. ISPM checks query aggregate tenant statistics (user counts, role configurations, MFA enrollment rates, directory sync coverage)—individual user identifiers from the OneLogin API are not persisted.
• SSF/CAEP: Inbound Security Event Tokens (SETs) from external identity providers are validated per RFC 8417 and OpenID CAEP 1.0 (final, August 29, 2025). Subject identifiers (email, phone, DID, iss_sub) are hashed with keyed HMAC-SHA-256 (server-held pepper) before storage. Raw SET payloads are AES-256-GCM encrypted for forensic retention. No plaintext PII from external IdPs is persisted. Stream URLs are implementation-defined and discovered via the Transmitter's /.well-known/ssf-configuration document. Inbound CAEP events are dispatched directly into the in-process revocation cascade on the same request, with a 24-hour jti idempotency cache to deduplicate redelivered events.
• DPoP: OAuth access tokens submitted for DPoP binding (RFC 9449) are SHA-256 hashed before storage—plaintext tokens are never persisted. Client IP addresses are hashed with keyed HMAC-SHA-256 (server-held pepper). JWK Thumbprints (RFC 7638) serve as binding identifiers. DPoP proof JWTs are validated in-memory and discarded after processing; only the binding metadata (algorithm, key type, HTTP method, URI) is retained. A shadow-telemetry mode threaded through the api-key-auth chokepoint captures DPoP coverage metrics without rejecting unbound traffic; only re-attestation timestamps and a shadow_degraded tier flag are persisted.
• Supply Chain Provenance: Build artifact digests (SHA-256), source commit digests, builder identities, and Sigstore transparency log entries are stored for provenance verification. No source code, binaries, or proprietary build artifacts are persisted—only cryptographic digests and attestation metadata.
• SDK Integrity Attestation: Client-side attestation payloads contain structural hashes of SDK function signatures, DOM structure checks, and timing measurements. Session fingerprints are SHA-256 hashes of non-PII browser characteristics (user agent, screen dimensions, timezone). No personally identifiable information is collected or transmitted.
• Breakglass Emergency Access: Breakglass session records (requester ID, approver IDs, severity, access scopes, justification text, timestamps) are stored immutably—no records are ever deleted. Actor IP addresses and user agents are captured in audit log entries and anonymized after 90 days per standard retention policy.
• Cross-Tenant Threat Sharing: Shared threat indicators contain only SHA-256 hashed values (indicator_hash), severity classifications, and contributor counts. No tenant is identifiable from the shared feed—the k-anonymity threshold (k ≥ 3) ensures indicators surface only when multiple independent tenants observe the same hash. Contribution records are cascade-deleted when a tenant is removed (GDPR Art. 17 compliance). Participation is opt-in only.
• Insider Threat Analytics: Anomaly detection operates exclusively on audit log metadata (actor IDs, action types, timestamps, IP hashes, user-agent strings) and agent activity records (delegate IDs, action types, scopes used). No plaintext PII is analyzed. Behavioral baselines store rolling averages, known IP hashes, and known user-agent strings—all pre-hashed or non-PII metadata. Investigation notes entered by administrators are stored as-is and are subject to the tenant's data retention policy.
• Webhook Delivery: Outbound webhook payloads are delivered via an asynchronous queue with SSRF validation (allowlisted domains only), exponential backoff retries for transient failures, and full delivery logging (status codes, latency, attempt counts). Callback URLs are validated against an internal allowlist before any outbound request is made. Webhook signing secrets remain HMAC-SHA-256 scoped per tenant.
• Health Monitoring: The global health check endpoint validates database connectivity, encryption key availability, and billing integration status. No tenant data, PII, or configuration details are exposed in health check responses. Sampled snapshots persist nine component-level health states (carrier APIs, DPoP, SSF/CAEP relay, NTP, ingest, cascade, VC engine, A2A, observability) to a public-read shield_health_snapshots table on a 30-day retention window for the public /status page; snapshot rows contain only aggregate health flags and latency, never tenant identifiers or signal content.
• Per-Tenant Quotas and Egress Allowlist: Per-tenant request quotas are enforced at the edge to prevent noisy-neighbor effects across plans. Outbound HTTP from edge functions flows through a safeFetch helper that enforces an egress allowlist, blocking SSRF and data-exfiltration vectors at the network boundary. Quota counters and egress-deny events are stored as aggregate counts only, with no PII.
• Anomaly Scanner and Canary Mesh: A platform-wide anomaly scanner monitors traffic surges, error-rate spikes, latency regressions, egress volume, cascade depth, and tenant-concentration anomalies; only aggregate metric deltas and threshold breaches are persisted. Honeypot canary endpoints record probe attempts (hashed source IP, timestamp, endpoint) to shield_canary_hits, and dispatch SSRF-guarded Slack alerts. No tenant payload data is ever captured.
• SOC 2 Evidence Intake: Contact details submitted through the public SOC 2 evidence-request form (requester name and work email) are encrypted at rest using AES-256-GCM with a per-platform key held in the managed secrets vault. Decryption is gated through dedicated SECURITY DEFINER RPCs that are restricted to platform administrators and the notification edge function (REVOKE EXECUTE FROM PUBLIC). Submissions are used solely to fulfill the evidence request and the associated NDA workflow.

Depending on your jurisdiction, you have the right to:

• Access your personal data (GDPR Art. 15, PIPEDA Principle 9, CCPA §1798.100).
• Rectify inaccurate data (GDPR Art. 16).
• Erase your data ("right to be forgotten") (GDPR Art. 17, CCPA §1798.105).
• Port your data in a machine-readable format (GDPR Art. 20).
• Restrict or object to processing (GDPR Art. 18, 21).
• Withdraw consent at any time (GDPR Art. 7(3), PIPEDA Principle 3).
• Non-discrimination for exercising rights (CCPA §1798.125).

Contact dpo@passkeybridge.io—we respond within 30 days (or 45 days for CCPA requests). Canadian users may also file a complaint with the Office of the Privacy Commissioner of Canada.

For GDPR inquiries, our Data Protection Officer can be reached at:

PasskeyBridge LLC
5830 E 2nd St., Ste 7000 #33652, Casper, WY 82609
dpo@passkeybridge.io

We will notify you of material changes via email or dashboard notification at least 30 days before they take effect. Continued use after the effective date constitutes acceptance.

PasskeyBridge LLC
5830 E 2nd St., Ste 7000 #33652, Casper, WY 82609

support@passkeybridge.io (General)
dpo@passkeybridge.io (Data Protection)
passkeybridge.io