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, and contacting professionals about our product (section 6a).
• Consent (Art. 6(1)(a)): Our newsletter and product updates, which you choose to receive.
• Legal obligation (Art. 6(1)(c)): Tax and billing records.

• Email address (for authentication and notifications).
• Display names supplied for account presentation, held in the authentication account separately from signal data. Identity-provider provisioning labels are encrypted per organization membership (section 11).
• Organization name (for tenant identification).
• Payment information (processed by Stripe; we do not store card details).
• IP addresses and user agents in application audit logs (stored as keyed HMAC-SHA-256 digests and cleared after 90 days). Authentication-provider session and security records are separate account data.

• 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). During issuance and verification the credential subject identifier travels to us over TLS; we key it with HMAC-SHA-256 under a server-held pepper before storage and never store or log it in the clear.
• 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 reduced on the device to a SHA-256 digest per channel and a composite digest of those; raw sensor readings are never sent or stored. The server keys the composite and each channel digest with HMAC-SHA-256 under a server-held pepper, with a separate label for each field, before storing it. The device identifier sent with them, a SHA-256 digest computed on the device from the browser's user agent, platform, screen size, color depth, processor core count, language and timezone, is keyed with HMAC-SHA-256 under a server-held pepper before storage; the digest as sent is not stored. The user digest the organization sends with a capture is keyed with HMAC-SHA-256 under the same pepper before storage, and is not stored as sent either. Provenance Guard keys the device digests and user digest it receives the same way before storing them: the enrolled device fingerprint, the fingerprint recorded on a challenge, and the user, device, entropy-chain and kinematic-context digests on a succession record.
• 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 configured carrier-data provider for that lookup (Twilio, Vonage or Sinch, 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.

We contact people whose work involves identity security to tell them about PasskeyBridge. For this we are the controller.

What we hold. Name, work email address, job title, company, city, region and country, seniority, industry, a LinkedIn profile address where the source provides one, and the source's contact identifier; and a record of the emails we send and of their delivery, opens, clicks, replies and unsubscribes.

Where it comes from. Apollo.io, a commercial business-contact database.

Why, and on what basis. To tell you about our product, on the basis of our legitimate interest in reaching professionals in their professional capacity (GDPR Art. 6(1)(f)). We do not email people in the EU, the EEA, the UK or Switzerland unless the law of their country allows it without prior consent and this notice is in place.

Who receives it. Resend (email delivery) and Supabase (hosting), section 10.

How long. Until you object, or 24 months after our last email to you (or after we imported your record, if we never wrote), whichever comes first; a scheduled job deletes the record then. After an objection we keep only your email address, marked so that we never write to you again; the rest of the record is cleared at that moment.

Your choices. You can object at any time with the unsubscribe link in any email, by replying, or by writing to dpo@passkeybridge.io, and we stop immediately. Your other rights are in section 12.

• 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): cleared automatically after 90 days by a scheduled database function: the IP address digest and the user agent are both set to null.
• 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.
• AI connector approvals (section 11): each approval is kept as a record of the approving administrator's account ID, the client's name, the host it returns to and the approval's dates, for the life of the account, so the history of who approved what stays complete. A revoked or expired approval stops working and the record stays; records are deleted with the account, within 30 days of closure. The connector's authorization codes (2 minutes), access tokens (30 minutes) and refresh tokens (30 days, never past the approval) are stored only under a keyed HMAC-SHA-256 digest and are deleted within an hour of expiring.
• Business prospect records (section 6a): until you object, or 24 months after our last email to you, whichever comes first; after an objection, your email address only, marked so that we never write to you again.

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 identifier from the signals we process is stored.

PasskeyBridge™ uses only strictly necessary cookies and browser storage for authentication session management. We do not use analytics cookies or advertising trackers.

Our website and dashboard count page views with two cookieless analytics services, Vercel Web Analytics and Ahrefs Web Analytics. Neither sets a cookie or stores an identifier on your device; they report aggregate traffic (pages viewed, referrer, country, browser and device type). Because we set no non-essential cookies, we do not show a cookie consent banner.

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) and business outreach email (section 6a) (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.—Carrier lookup for phone-based signals when a tenant requests it: Number Insight on our account, or Identity Insights under the tenant's own Vonage application. Receives the phone number for that lookup only; we do not store it (Holmdel, NJ, USA; global endpoints).
• Sinch—Carrier lookup for phone-based signals when selected by the tenant, using the tenant's own Sinch project. Receives the phone number transiently for Number Lookup, and for SIM-swap checks where that capability is available and enabled. We retain the normalized result under the number's keyed digest, not the phone number (global service endpoints).
• SpaceXAI LLC (xAI)—AI model inference through the xAI API, for Intelligence Layer risk analysis, triage of ambiguous signals, and internal operations tooling (USA). Risk analysis and triage receive signal metadata only (for example event types, results, risk scores, timings and the actions a playbook took), with identifiers present only as truncated keyed HMAC-SHA-256 digests under a server-held pepper. No plaintext identifier or other plaintext PII is sent. Operations tooling receives platform-wide aggregate counts and engineering data (check results, logs, source code), not individual signals; log excerpts are scrubbed of email addresses, phone numbers, IP addresses, tokens, key-like strings and long encoded values before they are sent.
• Anthropic, PBC—Previous provider of the same AI processing through the Anthropic API, replaced by xAI on September 26, 2026. No requests are sent to it: the Service no longer calls it, and its endpoint was removed from our outbound allowlist on October 3, 2026 (San Francisco, CA, USA).
• Slack Technologies, LLC—A tenant can register its own Slack webhook for playbook, posture or monitoring alerts. Those messages go to the tenant's own Slack workspace at the tenant's direction and carry alert details such as the signal type, risk score, and truncated tenant ID and keyed phone digest. PasskeyBridge does not post operator alerts, digests or approval requests to a Slack workspace (San Francisco, CA, USA).
• GitHub, Inc.—Source code hosting, continuous integration (GitHub Actions) and operations automation. Receives our source code, build and test logs, and draft pull requests opened by our operations tooling, which carry sweep findings and proposed code changes. Scheduled monitoring checks run on GitHub Actions with service credentials for our production systems; their output is check results, kept as workflow logs and report artifacts (San Francisco, CA, USA).
• Functional Software, Inc. (Sentry): application error monitoring for our website and dashboard. When a page hits a front-end error or crash, receives an error report: the error message and stack trace, browser and operating system, and the page URL without its query string. Configured not to collect names, email addresses, IP addresses, request bodies, cookies or authorization headers, WebAuthn/passkey data, or session recordings. Data is processed in Sentry's US region (San Francisco, CA, USA).

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

• TLS for data in transit (TLS 1.3 where the client supports it).
• AES-256 for data at rest.
• SHA-256 hashed API keys; low-entropy identifiers hashed with keyed HMAC-SHA-256 under a server-held pepper.
• 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): Since August 8, 2026, credentials and attestations the platform signs carry, by default, two signatures over the same input: a classical ES256 (P-256 ECDSA) signature and a detached ML-DSA-65 (NIST FIPS 204) signature. This default is not limited to a plan. Tenants on the Enterprise ML-DSA-87 add-on sign with ES384 (P-384 ECDSA) plus ML-DSA-87, and a tenant may opt into an older envelope that pairs a server-verified HMAC-SHA-256 layer with ML-DSA. Post-quantum protection covers signatures only; encryption and key agreement remain classical. When an Enterprise tenant turns post-quantum signing on, cross-references and cached identity proofs also carry a hybrid HMAC-SHA-256 and ML-DSA signature, and A2A handshake attestations are signed the same way. Tenant signing keys use per-tenant ECDSA key pairs (P-256, or P-384 on the ML-DSA-87 add-on) with AES-256-GCM encrypted private keys; after a rotation, PasskeyBridge's own verifier accepts the previous key for 24 hours.
• Account names: New signups do not copy a display name into application profiles; the dashboard shows the name held in the signed-in account's authentication record. Names an identity provider supplies during provisioning are AES-256-GCM encrypted for each organization membership. A profile name stored before this change stays in the profile until an operator runs a guarded backfill, which moves the name into the account's authentication record, keeps newer provisioning labels, and stops at any record that conflicts or has changed. The encrypted copy of a profile name made by our earlier encryption tooling is kept after the backfill.
• Purpose-Bound PII Vault: Dual-path cryptographic storage (AES-256-GCM ciphertext + keyed HMAC-SHA-256 lookup digests under a server-held pepper) with auditable purpose-coded decryption gates. Every decryption requires a declared purpose code logged in an immutable audit trail. Vault ciphertext is encrypted under a single platform key, not per-tenant keys, so erasure is not performed by deleting a key; bring-your-own-key applies to tenant signing keys only. Erasure is performed through a data subject request (section 12): the subject's identifier columns are nulled and their encrypted columns are overwritten. PII is never stored or retained in application memory beyond the encryption/decryption operation.
• BLAST Protocol: Encrypted tunnels that deliver shadow proxy values, using X25519 ECDH key agreement and AES-256-GCM, with a quantum-seeded salt in the key derivation.
• Shadow Proxy: Ephemeral proxy values (virtual card numbers, booking codes and loyalty identifiers), stored AES-256-GCM encrypted, let downstream systems transact without the real value.
• Observability: Structured metrics, anomaly detection, and alerting pipelines process only aggregated 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. An inbound event reporting a revoked session, a credential revoked, rotated, compromised or deleted, or a non-compliant device 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.
• 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 the Sigstore bundles tenants submit are stored as attestation records; the bundles are checked for shape, not verified against the transparency log. 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. The request's User-Agent header and client IP address are each keyed with HMAC-SHA-256 under a server-held pepper before storage, and neither is stored in the clear. The page origin, which names the website and not a person, is stored as a SHA-256 digest. The payload carries no name, email address or phone number.
• Breakglass Emergency Access: Breakglass session records (requester ID, approver IDs, severity, access scopes, justification text, timestamps) are kept for the life of the organization; nothing deletes them before the organization itself is removed. Actor IP addresses (as keyed HMAC-SHA-256 digests) and user agents are captured in audit log entries and cleared after 90 days (section 7).
• Cross-Tenant Threat Sharing: Shared threat indicators contain a keyed digest of the tenant-supplied indicator_hash, its indicator type, severity classification, and contributor count. The server accepts an indicator_hash only as a SHA-256 hex digest, so a raw identifier is refused, and stores it only after keying it with HMAC-SHA-256 under a server-held pepper. 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. 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: A webhook payload gets one delivery attempt inside the ingest request, then retries from a durable queue drained every five minutes, up to four attempts in all, and every attempt is logged (status code, latency, attempt count, and the response body with identifiers masked). Callback URLs must be HTTPS and are refused for private, loopback, link-local and metadata-service addresses before any request is made. Webhook signing secrets are HMAC-SHA-256 keys 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. Snapshots of that check (its overall status and each component's status and latency) are written every 15 minutes, and for a sample of other calls, to a public-read shield_health_snapshots table on a 13-month 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, 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. 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, revocation cascade runs, 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. A real hit is posted to the operator alert webhook. No tenant payload data is ever captured.
• AI Connector (MCP): An administrator can let an AI client that supports the Model Context Protocol, such as Claude or Grok, read the organization's security data. The client asks; the administrator approves on our consent page, which shows the client's name, the host it returns to and what it may read, and requires a fresh passkey check, so only an administrator with a registered passkey can approve. The client can then read signal counts, audit events (action, time, actor type, resource type and result), fired alerts, posture findings, passkey coverage counts and pending recovery requests, and cannot change anything. It never receives 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. What the client reads goes to that client and its provider, which your administrator chose, under your organization's terms with that provider. 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; it also stops working if the approving administrator is no longer an administrator. Every approval, request and revocation is written to the organization's audit log.
• SOC 2 Evidence Intake: Contact details submitted through the public SOC 2 evidence-request form (requester name and work email) are encrypted at rest with pgcrypto's OpenPGP symmetric encryption under a 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