Frequently Asked Questions

PasskeyBridge is an Identity Threat Response as a Service (ITRaaS) platform. It receives carrier and identity signals (SIM-swap, number porting, fraud alerts) and executes your configured response playbook in real-time with zero PII storage. It is built on a filed three-pillar architecture: Pillar I (Network Attestation), Pillar II (Legal Identity Verification via a self-hosted W3C VC engine), and Pillar III (Biometric Binding via WebAuthn/FIDO2).

Any platform that authenticates users with phone numbers or needs identity verification. Fintech companies, neobanks, crypto exchanges, healthcare platforms, defense contractors, critical infrastructure operators, and any team that wants automated threat response without building it from scratch. Our target verticals include financial services (terminal binding, SEC Reg S-ID compliance), military and defense (device attestation), and critical infrastructure (SCADA authentication).

No. PasskeyBridge sits alongside your existing auth stack (Okta, Auth0, Clerk, Firebase, etc.). We handle the threat-response layer: what happens after a threat signal is detected. That layer sits after authentication and bridges the gap between detection and containment. We integrate with Okta through SCIM v2 and Okta Event Hooks.

20 US patent applications filed (7 non-provisional, 13 provisional). None has been granted. Application numbers are not published on this site.

PasskeyBridge is designed as an identity trust layer that sits between your platform and the user. We do not store your end users' personal data or passwords. We orchestrate trust signals from carriers, issue and verify W3C Verifiable Credentials via our self-hosted engine, bind biometrics via WebAuthn, run AI threat analysis asynchronously, and sign the credentials and attestations we issue with a classical and a post-quantum signature. Identifiers are kept only as keyed digests, so the architecture holds zero PII at rest.

Pillar I is the signal-based threat response layer. It takes in carrier signals (SIM-swap alerts, number porting notifications, fraud indicators), either from a carrier lookup that runs under your organization's own Vonage application or Sinch project, or posted as JSON by any system you run. Lookups on PasskeyBridge's own Vonage Number Insight and Twilio Lookup accounts need an add-on that is not on sale yet. When a threat signal is detected, your configured playbook executes automatically: a signed webhook to your backend, email and Slack alerts, and revocation of the agent delegations and sessions PasskeyBridge holds for you. Pillar I is included in all plans.

Pillar II provides W3C Verifiable Credential issuance and verification via PasskeyBridge's self-hosted VC engine. The engine supports JWT-VC format, OpenID4VP presentation exchange with batch VP Token verification (up to 20 tokens per request), W3C StatusList2021 credential status management with ETag-based auto-refresh, DID resolution (did:web:passkeybridge.io), and per-tenant P-256 ECDSA (ES256) signing keys, with a 24-hour grace period for the previous key in PasskeyBridge's own verifier after a rotation. Every credential carries a detached post-quantum signature beside its classical one, on every plan: ML-DSA-65 with ES256 by default (ML-DSA-87 with ES384 on the Enterprise add-on). A tenant can instead opt into the older envelope, which pairs ML-DSA with an HMAC tag. The verified identity is bound to the user's account via a keyed HMAC-SHA-256 digest under a server-held pepper: no PII is stored.

Pillar III is passkey authentication on the WebAuthn/FIDO2 standard. Your users register a passkey with their device's own unlock (Face ID, Touch ID, Windows Hello or a PIN), and PasskeyBridge's hosted relying party runs the registration and sign-in ceremonies for your domain, storing a keyed digest of your user handle and the credential's public key. The private key stays with the user's authenticator and the biometric never leaves the device. The hosted relying party is on the Enterprise plan; passkey sign-in to the PasskeyBridge dashboard itself is available on every plan.

No. Pillar I (Network Attestation) is included in every plan, including the free Starter plan, and works standalone. Pro adds Pillar II, verifiable credentials, and Enterprise adds Pillar III, passkeys for your own users through the hosted relying party. There are no seat licenses, so you can start with threat response and add credentials and passkeys when your requirements call for them.

Your backend or signal source posts JSON to your PasskeyBridge ingest URL: POST /v1/shield-ingest. When the request carries an x-pb-signature header we verify the HMAC-SHA-256 signature, and you can require one on every request. The phone number is keyed with HMAC-SHA-256 under a server-held pepper before anything is stored. The signal is matched to one active playbook, the oldest whose trigger equals its event type, that playbook's actions run in parallel, and the result is returned inside the request. The event and an audit record are written for every signal.

Two ways in. PasskeyBridge can query a carrier for you through its carrier lookup: a SIM swap check through Vonage Identity Insights under your own Vonage application, or, with the hosted carrier lookups add-on, Vonage Number Insight Advanced or Twilio Lookup v2 on PasskeyBridge's accounts. Or any system that can send JSON over HTTPS can post signals to the ingest endpoint; the one required field is event_type. Inbound signatures are verified against your organization's signing secret, or against a registered signal source's own secret. There is no native parser for a provider's own webhook format, so map it to the ingest schema first.

Common signal types include: sim_swap (SIM card changes), port_out (number porting to another carrier), credential_leak (compromised credentials detected), device_change (device fingerprint mismatch), velocity_anomaly (abnormal usage patterns), and account_takeover (suspicious login behavior). Hard signals such as sim_swap, port_out, ss7_intercept and account_takeover trigger immediate revocation; soft signals such as velocity_anomaly and device_change trigger a trust re-evaluation. Both need the subject's phone number or digest on the signal. You can also define custom signal types: PasskeyBridge matches them against your playbooks by the event_type field in the payload.

Production requests use API key authentication via the x-pb-api-key header. API keys are SHA-256 hashed before storage and the raw key is shown only once at generation time. Keys are scoped to specific capabilities (ingest, events, metrics, vc_issue, vc_verify, vc_revoke, spatial, scim, okta_hooks, dpop, supply_chain, passkey_rp, passkey_rp_import, receipts) so you can follow least-privilege principles. For testing from the dashboard, JWT authentication with the x-pb-test-mode: true header is supported.

A playbook is a set of response actions bound to a signal type (for example 'sim_swap'). When a signal arrives, one playbook runs: the oldest active playbook whose trigger matches the signal's event type. Its actions run in parallel, and each is bounded by an 8-second timeout, so a slow Slack post or webhook cannot hold up the others. Each action's status, latency and any error are recorded on the event. On a hard signal, PasskeyBridge's own revocation runs before the playbook and does not wait for it.

Thirteen. Four notify: webhook_callback posts a signed event to your callback URL (up to 4 delivery attempts), email_alert emails your organization's admins or members, slack_webhook posts to a Slack channel you registered, and log_event records the signal at a chosen severity. Seven revoke state PasskeyBridge holds for your organization, across the whole organization rather than one user: suspend_account and suspend_agents deactivate your agent delegates (suspend_agents also clears their scopes), revoke_sessions revokes live agent-to-agent negotiations, revoke_tokens tears down BLAST tunnels, freeze_credentials invalidates cached passkey proofs, step_up_auth deactivates shadow identities, and quarantine does the last three kinds at once. Two manage support tickets: create_support_ticket opens one and resolve_support_ticket closes the open tickets a signal type opened. None of them touches your own user accounts or sessions; webhook_callback is how your backend acts on those.

When your organization has a callback signing secret, PasskeyBridge signs the exact bytes of each webhook_callback body with HMAC-SHA-256 under it and sends the lowercase hex digest in the x-pb-signature header. Your server should verify this signature before processing the payload to ensure it came from PasskeyBridge and hasn't been tampered with. Retried deliveries also carry a detached ML-DSA signature in x-pb-pqc-* headers. You can rotate your signing secret at any time from the dashboard.

The first attempt is made inside the ingest request with a 5-second deadline. HTTP 2xx is success. A network error, a timeout, HTTP 429 or a 5xx hands the delivery to a retry queue that a worker drains every five minutes, for up to 4 attempts in total. Redirects are never followed, and a redirect or any other 4xx is final and not retried. Every attempt, failures included, is logged with its status code, response body (identifiers masked), latency and error message. You can inspect these in the dashboard's Webhooks tab.

Not yet. The playbook builder can load platform templates, but none has been published, so today you build each playbook from its trigger and actions. The playbook recipes guide in the documentation walks through eight common responses, from a SIM swap to a number port-out.

Yes. PasskeyBridge operates a self-hosted W3C Verifiable Credential engine comprising five edge functions: shield-vc-issue (credential issuance), shield-vc-present (OpenID4VP presentation exchange and native verification of the credentials it issues), shield-vc-verify (verification through a configured provider such as walt.id or Trinsic), shield-vc-status (W3C StatusList2021 revocation management), and shield-did-resolve (DID document resolution for did:web:passkeybridge.io). Per-tenant signing keys are held in shield_tenant_keys and rotate on request.

The engine issues JWT-VC format credentials (W3C VC Data Model 2.0), supports OpenID4VP presentation exchange for verifier flows, resolves DID documents for issuer verification, and implements a three-state credential lifecycle (active → suspended → revoked). Every issued credential carries a detached post-quantum signature beside its classical one, on every plan: ML-DSA-65 with ES256 by default (ML-DSA-87 with ES384 on the add-on). A tenant can instead opt into the older envelope, which pairs ML-DSA with an HMAC tag.

Each VC provider configuration includes a list of trusted issuer DIDs (Decentralized Identifiers). When a credential is verified, PasskeyBridge checks that the issuer is in your trusted list. If the issuer isn't trusted, the verification is rejected—even if the credential itself is cryptographically valid. This prevents acceptance of credentials from unknown or untrusted issuers.

You configure the supported_credential_types array per provider. Common types include VerifiableId (government ID), VerifiablePassport, VerifiableEmployeeCredential, VerifiableDiploma, and any W3C Verifiable Credential type. The self-hosted engine can issue credentials with custom claims and verify inbound credentials against your trusted issuer registry.

When a Verifiable Credential is verified, PasskeyBridge extracts the credential subject and replaces all PII fields with '[redacted]' before logging. Only field names, types, and non-PII metadata (DID, credential type) are stored. The subject's DID is hashed with keyed HMAC-SHA-256 under a server-held pepper for correlation. The actual credential content exists only in-memory during the verification request and is never persisted.

Yes. @passkeybridge/vc-wallet-sdk (the PBWallet class, documented at /sdk) is a TypeScript library with encrypted IndexedDB credential storage, a lightweight OpenID4VP Presentation Exchange 2.0 matcher, and lifecycle calls. Initialize it with your tenant id, and an API key for the calls that need one, then use wallet.issue(), wallet.verifyPresentation(), wallet.verifyBatchPresentation(), wallet.revoke(), wallet.suspend() or wallet.reinstate(). The post-quantum signature on an issued credential comes from the server; pass bindToSignalHash to have the server bind a credential to a carrier signal.

W3C StatusList2021 is the standard for verifiable credential revocation using compressed bitstring encoding. PasskeyBridge implements this via shield-vc-status, supporting three states: active, suspended (reversible), and revoked (permanent). Public GET requests return the StatusList2021 bitstring for any issuer DID, enabling external verifiers to check credential status without contacting PasskeyBridge directly. StatusList responses include HTTP ETags derived from the bitstring content, enabling conditional caching: relying parties only download a fresh list when the underlying state has changed.

Batch VP Token verification allows you to submit up to 20 OpenID4VP Verifiable Presentation tokens in a single API call to shield-vc-present. Each token's signature is verified separately, all tokens must come from the same holder, and one presentation definition is matched against the credentials of the whole batch. The response carries one verified flag and a result for each credential. The 20-token limit is enforced at both the client SDK and edge function layers, and the call needs a dashboard session or an API key with the vc_verify scope.

Each StatusList response carries an ETag derived from a SHA-256 hash of the bitstring content (not timestamps). When a relying party polls for status updates and the bitstring has not changed, the server returns 304 Not Modified with zero body. Relying parties cache the StatusList locally and only download a fresh copy when a credential has been revoked or suspended.

No. The PBWallet SDK stores credentials locally in IndexedDB (with an in-memory fallback). Credentials are only transmitted to the server during issuance (to receive the signed JWT-VC) and presentation (to verify against your trusted issuer registry). The subject DID travels to PasskeyBridge over TLS and is keyed with HMAC-SHA-256 under a server-held pepper before anything is stored or logged; it is never stored in the clear.

For your own users, through the hosted relying party (Enterprise): your front end asks PasskeyBridge for registration options for your domain, the browser runs the WebAuthn ceremony and prompts for the device's unlock (Face ID, Touch ID, Windows Hello or a PIN), and PasskeyBridge verifies the response on its server and stores the credential. People on your team register passkeys for the PasskeyBridge dashboard from Settings the same way. In both cases the public key is stored; the private key stays with the user's authenticator (bound to the device's secure hardware, or synced end-to-end encrypted by the platform's passkey provider) and never reaches PasskeyBridge.

Any device with a FIDO2-compatible authenticator: iPhones with Face ID or Touch ID, Macs with Touch ID, Windows PCs with Windows Hello (camera, fingerprint, or PIN), Android devices with fingerprint or face unlock, and hardware security keys (YubiKey, etc.). PasskeyBridge supports both platform authenticators (built into the device) and roaming authenticators (USB/NFC keys).

Yes. Users can register passkeys on multiple devices—for example, a Face ID passkey on their iPhone and a Windows Hello passkey on their laptop. Each credential is independently stored and can be individually revoked. We recommend registering at least two passkeys for redundancy.

It is PasskeyBridge's name for tying an identity to a passkey. The biometric itself never leaves the device: it unlocks the passkey's private key on the authenticator, and the signed WebAuthn response shows the server that the key signed and that the user was verified. Beside Pillar I (network attestation) and Pillar II (legal identity) it adds a third, independent piece of evidence: the carrier attests the phone number, the verifiable credential attests the identity its issuer vouched for, and the passkey attests possession of the device with user verification. On Enterprise, Deterministic Cross-Reference links the three through keyed identifier digests (HMAC-SHA-256 under a server-held pepper) without storing PII.

Agent delegates are authorized digital agents (AI assistants, automation bots, service accounts) that can act on behalf of your organization with scoped, time-bound permissions. A tenant admin creates a delegate with specific scopes (the dashboard offers ingest, events:read, playbooks:execute, credentials:present, spatial:attest and shadow:create) and an optional expiration of up to a year. The agent receives a one-time token (shown once, stored only as a digest) that it uses to authenticate. Delegates can be revoked instantly through the API.

NF-05 is a filed trust engine that scores each agent delegate from 0.000 to 1.000 and narrows its scopes by the score: ≥0.7 retains full access, ≥0.4 drops to read-only, below that restricts to verify-only, and below the delegate's revocation floor (0.2 by default) the delegate is deactivated. Every verify call an active delegate makes is recorded, including calls refused for scope or expiry. A refused call is scored as it is recorded, every five minutes the engine re-scores each delegate with activity it has not yet judged, and the score is also re-evaluated when a soft signal arrives for your organization and when an AI assessment adjusts it. The engine scores recorded activity for action velocity, error bursts, scope violations, IP rotation and bursts after long inactivity.

When the trust engine detects anomalous behavior, it narrows the agent's active scopes while preserving the original scopes for potential restoration. If trust recovers above the full-access threshold (≥0.7), scopes are automatically restored without admin intervention; a delegate that was deactivated stays deactivated. Hard signals (SIM-swap, SS7 intercept, device compromise) bypass the graduated system entirely: they deactivate every active agent delegate of your organization immediately.

Yes, and only to lower trust. Each AI assessment can lower the trust score of your organization's agent delegates by at most 0.3 on the 0 to 1 scale and never raises one, so an assessment cannot restore scopes that were narrowed. Assessments accumulate and can narrow a delegate, but the AI's share never takes a score below the delegate's revocation floor: only deterministic evidence deactivates a delegate. An assessment the hallucination guard flags adjusts nothing. The AI never takes part in hard-signal revocation, and every adjustment is recorded against the assessment that caused it.

As AI agents become prevalent in enterprise workflows, they need authorized access to your systems. Without proper delegation, agents either have no access (limiting automation) or use shared credentials (creating security risks). PasskeyBridge agent delegates provide scoped, audited, revocable access with continuous trust evaluation—the same security model you'd want for human team members, but designed for AI agents.

The A2A (Agent-to-Agent) Horizontal Trust Protocol (filed application, pending) establishes a trust corridor between two agent delegates of your organization by attesting the humans behind them. Unlike vertical trust models (agent-to-platform), A2A sets up peer-level corridors with transaction limits and an expiration window, and a hard carrier signal revokes every live corridor of the organization. Each step is authorized by a signed-in member of your organization.

Four steps, then revocation. (1) Initiate: a corridor is opened between two of your agent delegates with a lifetime of 10 seconds to an hour. (2) Attest: both delegates must be active, the humans who delegated them must hold registered passkeys, and neither may have had a hard carrier signal in the last five minutes. (3) Negotiate: the server computes a Combined Trust Coefficient (CTC) from the two delegates' trust scores, reported network jitter, SIM age and any NF-08 spatial binding. (4) Renew: a corridor is extended only if the recomputed coefficient is within 0.10 of the negotiated one. A hard carrier signal (SIM-swap, SS7 intercept, port-out) revokes every live negotiation of your organization.

The CTC is a composite score (0.000-1.000): the geometric mean of the two agents' trust scores, less a penalty for network jitter above 150 ms, plus a +0.05 bonus when either side has an NF-08 spatial binding and a small bonus for a fresh SIM. It maps to four trust states: Full (CTC >= 0.7), Read-Only (>= 0.4), Verify-Only (>= 0.2), and Auto-Revoked (< 0.2). The CTC sets the corridor's maximum transaction value and rate, which the negotiation returns for your agents' platform to enforce.

Every step that changes a negotiation (initiate, attest, negotiate and renew) signs a statement of that change with HMAC-SHA-256 (classical) plus ML-DSA-65 (post-quantum) over a payload that carries a quantum-seeded nonce, and the change and its proof are written together. A step that cannot sign does not run. The whole proof is kept, and the proofs action verifies each one again and returns the ML-DSA public key, so the post-quantum layer can be checked without a PasskeyBridge secret. Each request carries a client nonce, which is hashed and accepted only once per organization, and a timestamp, when supplied, must be within 300 seconds of server time. Nonce digests are kept in shield_a2a_nonces.

A hard carrier signal (SIM-swap, port-out, SS7 intercept) revokes every live A2A negotiation of your organization on the same request, before any playbook action runs: each is set to status 'revoked' with trust state 'auto_revoked', its limits are zeroed, and the reason names the signal type. The same step deactivates every active agent delegate of your organization. Both steps run automatically.

Every organization gets structured metrics (Prometheus and JSON export), anomaly flags, configurable alert rules, and alert delivery to Slack, PagerDuty, OpsGenie or a webhook. The shield-metrics edge function computes statistics across your events, AI intelligence assessments, agent delegates and A2A negotiations, and flags anomalies against fixed thresholds, such as an error rate above 20% or p95 latency above 500 ms. All metric payloads contain aggregated counts and scores only, with zero PII.

Alert rules are tenant-scoped triggers that fire when a metric over the past hour crosses a threshold. Each rule specifies: the metric (events_per_hour, p95_latency_ms, high_risk_count, error_rate or mean_risk_score), a comparison operator (>, >=, <, <= or ==), a threshold value, a severity (info, warning, critical), a cooldown between re-fires (1 to 1,440 minutes, 15 by default), and one delivery channel. Every active rule is evaluated every five minutes. Rules are managed via the shield-alerting edge function and the dashboard's Observability tab.

HITL review is the workflow for security analysts to review, correct, and annotate AI intelligence assessments. When the Intelligence Layer flags an event, analysts can approve, reject, or correct the AI's risk score, intelligence type, and threat actor label. Corrections are persisted to the intelligence record with reviewer ID, timestamp, and notes, so the record keeps both the model's answer and the analyst's. Corrections are not fed back to the model today, and a review does not undo an assessment's automatic effects on shadow identities and agent trust scores.

Behavioral clustering groups recent events by signal type, risk score ranges, carrier patterns, and temporal distribution to identify coordinated attack campaigns. The shield-intelligence-worker uses clustering data to enrich AI assessments with contextual threat intelligence. Clusters are computed from the tenant's recent event history and include metrics like dominant signal types, risk score distribution, and event velocity.

Yes. The shield-metrics endpoint exports data in both Prometheus text format and JSON. The Prometheus exposition accepts an API key carrying the metrics or events scope, so a Prometheus scraper or Datadog agent can read it directly; the JSON actions are read from the dashboard session instead. The JSON format is compatible with any monitoring system that accepts structured data via HTTP.

They rotate when you request a rotation. Your credential signing key (P-256, or P-384 with the ML-DSA-87 add-on) is rotated through an administrative call. PasskeyBridge's own verifier keeps accepting the previous key for 24 hours, but your DID document publishes only the new key, so plan external verification around a rotation. The callback signing secret rotates from the dashboard Settings tab, and inbound signatures made with the previous secret are accepted for 24 hours. API keys do not expire: generate a new key, move your integration to it, and revoke the old one on the API keys tab. The ML-DSA key pairs are derived from the platform master key and do not rotate.

NF-08 (filed) binds identity to a specific physical device at a specific moment in time. A capture produces 'Atomic Fingerprints': hashes of network jitter (RTT variance), accelerometer motion, the ambient magnetic field (a proxy for EMI) and a coarse thermal state, taken within a 100 ms window. The shield-spatial-bind edge function (Enterprise) compares each capture with the device's enrollment baseline and raises an anomaly score on a replayed capture or a different device.

The browser capture module (sensor-capture.ts), which is not yet part of the published SDK, reads four channels: (1) Network jitter: RTT variance sampled via the Resource Timing API, navigator.connection, and OS scheduler delta; (2) Accelerometer: 60 Hz motion vectors via the Generic Sensor API, with graceful degradation for unsupported browsers; (3) Magnetometer: the ambient magnetic field via the Generic Sensor API, used as an EMI proxy; (4) Thermal state: a coarse bucket derived from browser heuristics. Native EMI-spectral and on-die thermal sensing require a firmware bridge and are on the native-SDK roadmap. On the device, each channel's readings become a SHA-256 digest and a composite digest is taken over them; raw readings are not sent. The server keys each digest, and the composite, with HMAC-SHA-256 under a server-held pepper before storing it. The device model is one of the inputs to the device identifier digest and never travels on its own; the server keys that digest with HMAC-SHA-256 under a server-held pepper before storage, the platform travels as an OS family such as android or windows, and the capture timing in 10 ms and 100 ms buckets; shield-spatial-bind refuses a device model or a platform outside those families. Identical jitter hashes across distinct captures trigger a replay anomaly (+0.4 anomaly score).

Three primary verticals: (1) Military and defense—binding operator identity to ruggedized terminals and tactical radios, preventing credential relay and ghost-operator attacks; (2) Financial services—binding trader identity to Bloomberg terminals and trading workstations, in support of SEC Rule 15c3-5 and MiFID II controls; (3) Critical infrastructure—binding operator identity to SCADA HMI consoles, in support of NERC CIP, NRC 10 CFR 73, and EPA SDWA controls.

The Spatial Binding Controller (shield-spatial-bind edge function) rejects a capture whose reported capture duration exceeds 100 ms with an NF08_TEMPORAL_WINDOW_EXCEEDED error, and one whose capture timestamp is more than 500 ms from server time with NF08_CLOCK_DRIFT. The second check limits how old a replayed capture can be when it arrives.

TPM and Secure Enclave bind cryptographic keys to a chip and attest the device that holds them. A stolen device with valid keys passes attestation. Atomic Fingerprints add the device's state at capture time (motion, magnetic field, network jitter, thermal state) and compare it with the enrollment baseline, so a replayed capture or a different device raises the anomaly score. It is also distinct from behavioral biometrics, which model how a person types or moves.

PasskeyBridge signs with real ML-DSA lattice-based signatures (NIST FIPS 204) through mldsa-wasm, a WebAssembly build of mldsa-native. By default every credential it issues pairs a detached ML-DSA-65 signature of about 3,309 bytes with an ES256 signature (ML-DSA-87 with ES384 on the Enterprise add-on; a tenant can opt into an older envelope that pairs ML-DSA with an HMAC tag), and its internal proofs pair ML-DSA with HMAC-SHA-256. The post-quantum layer is about forgery: a signature made today stays trustworthy after a cryptographically relevant quantum computer exists, which a classical signature alone cannot promise. ML-DSA-65 is included on every plan.

NIST FIPS 204 (ML-DSA): ML-DSA-65 by default and ML-DSA-87 with the add-on, through mldsa-wasm, a WebAssembly build of mldsa-native. Key pairs are derived deterministically from the platform master key using domain-separated HMAC-SHA-256 seed derivation, one pair per tenant. Every draw of quantum entropy passes the NIST SP 800-90B continuous health tests before it seeds the nonce generator. The library is not a FIPS 140-validated module, and no key-encapsulation mechanism is implemented yet: key agreement is X25519.

PasskeyBridge uses a Quantum-Seeded Entropy Generation system (NF-07, filed). A 256-bit seed from a quantum random number generator is mixed with local CSPRNG output and stretched by an AES-256 counter-mode generator into the nonces bound into signed payloads, BLAST key-derivation salts and session identifiers. Providers are tried in order: Outshift QRNG (Cisco), QCi uQRNG (photonic), ANU QRNG, then the OS CSPRNG, and every draw must pass SP 800-90B health tests. A background reseed starts when a seed is 60 seconds old or has served 1,000 requests, and that seed keeps serving while the refresh runs. When the seed is 5 minutes old or has served 5,000 requests, whichever comes first, the next call waits for a new seed and returns no bytes until that reseed succeeds. Each seed is logged by its SHA-384 hash with its health-test report. Signing keys and ML-DSA's own signing randomness do not come from this generator.

No. Credentials carry the ML-DSA signature by default, and verifiers that check only the ES256 signature keep working. On Enterprise, turning on post-quantum signing in Settings also signs cross-references, cached proofs and credential verification results with a hybrid HMAC-SHA-256 and ML-DSA signature, stored in their pqc_signature field. Your existing API calls, webhooks, and playbooks work exactly the same.

Every plan that issues credentials: each credential carries an ML-DSA-65 signature by default. Post-quantum signing of cross-references and cached proofs comes with those Enterprise features, and ML-DSA-87 is an Enterprise add-on.

ML-DSA-65 (NIST Security Level 3) is the default on every plan. ML-DSA-87 (NIST Security Level 5, the category defined against AES-256) is the parameter set CNSA 2.0 specifies, available as an Enterprise add-on at $149/mo arranged through sales. It produces about 4,627-byte signatures (against about 3,309 for ML-DSA-65) and pairs with an ES384 (P-384) classical key, which a tenant receives when its signing key is next created or rotated. Cross-references, credential verification results, A2A step proofs and chain checkpoints stay on ML-DSA-65.

Yes. Tenant admins can configure SAML 2.0 and OIDC-based SSO providers via the dashboard's SSO configuration panel. Each SSO config includes provider type, entity ID, SSO URL, certificate, and optional domain hint. Multiple SSO providers can be active simultaneously per tenant. SSO is managed via the shield-sso edge function.

PasskeyBridge implements SCIM v2 (RFC 7644) so your identity provider (Okta, Microsoft Entra ID, OneLogin) can manage who has access to your PasskeyBridge organization. The shield-scim edge function handles GET, POST, PUT, PATCH and DELETE on /Users and GET, POST, PATCH and DELETE on /Groups. Provisioning a user adds an existing PasskeyBridge account to your organization rather than creating one, deprovisioning deactivates the membership, and groups map to the three roles: admin, member and viewer.

PasskeyBridge integrates with Okta in two ways: (1) SCIM v2 for user provisioning, added in Okta as a custom SCIM 2.0 app, and (2) Okta Event Hooks. The shield-okta-hooks edge function answers Okta's one-time verification challenge and acts on user suspend, unsuspend and deactivate, session start, password update and MFA factor removal. PasskeyBridge is preparing an Okta Integration Network submission and has no OIN listing today.

Yes. When generating an API key, you can select 'scim' and 'okta_hooks' as specific scopes alongside other capabilities (ingest, events, vc_issue, vc_verify, spatial, and so on). This follows least-privilege principles so your SCIM integration key only has provisioning access, not signal ingestion or playbook management.

Okta ISPM provides automated auditing of your Okta IdP configuration. It executes 25 weighted security checks, covering MFA enforcement (phishing-resistant factor validation), admin sprawl, lifecycle hygiene, password and session policy, and protocol hygiene, to generate a composite 0-100 Posture Score. Each finding includes severity, evidence, and actionable remediation guidance. Scans run on demand from the dashboard Posture tab. Okta API tokens are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

Entra ID ISPM provides automated auditing of your Microsoft Entra ID (formerly Azure AD) tenant configuration. It executes 25 weighted security checks, covering Conditional Access and MFA enforcement, privileged roles, risk detection, lifecycle and credential hygiene, and protocol and session controls, to generate a composite 0-100 Posture Score. The module authenticates via OAuth 2.0 client credentials and queries the Microsoft Graph API. Client secrets are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

Google Workspace ISPM provides automated auditing of your Google Workspace configuration. It executes 25 weighted security checks across areas including MFA (2-Step Verification enforcement, security key policy advisory), admin sprawl (super admin identification via role assignment analysis, delegated admin counts, custom role adoption), authentication (domain verification, OAuth app grants, email alias proliferation), lifecycle (suspended user cleanup, stale account detection, recent provisioning), device management (mobile device policies), and observability (admin and login audit log availability), to generate a composite 0-100 Posture Score. The module authenticates via service account JWT with domain-wide delegation (supporting both PKCS#8 and PKCS#1 PEM key formats) against the Google Admin SDK Directory and Reports APIs. User, group, and role assignment data is paginated up to 5,000 items per resource for accurate assessment of large domains. Private keys are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

AWS IAM Identity Center ISPM provides automated auditing of your AWS IAM Identity Center (formerly AWS SSO) configuration. It executes 25 weighted security checks, covering authentication, permission sets and least privilege, authorization, the identity store, governance and session controls, to generate a composite 0-100 Posture Score. The module authenticates via AWS Signature Version 4 against the SSO Admin, Identity Store, and IAM APIs with correct per-service signing (sso, identitystore, iam). The secret access key is AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

PingOne ISPM provides automated auditing of your PingOne (by Ping Identity) environment configuration. It executes 25 weighted security checks, covering authentication, applications, the identity store, credential management, certificates, governance and federation, to generate a composite 0-100 Posture Score. The module authenticates via OAuth 2.0 client credentials against the PingOne Management API with region-specific endpoint resolution (NA, EU, AP, CA). API responses are paginated by following HAL _links.next.href directly (up to 2,000 items per resource), with structured error handling that distinguishes API failures from empty data. Client secrets are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

CyberArk Identity ISPM provides automated auditing of your CyberArk Identity tenant configuration with PAM-adjacent posture checks. It executes 25 weighted security checks, covering authentication and MFA, role-based access, lifecycle, federation and PAM-adjacent posture (session recording, PSM policies, credential rotation), to generate a composite 0-100 Posture Score. The module authenticates via OAuth 2.0 client credentials against the CyberArk Identity Platform API with admin-only access enforcement. Client secrets are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

OneLogin ISPM provides automated auditing of your OneLogin (by One Identity) tenant configuration. It executes 25 weighted security checks, covering applications, the identity store, authentication, authorization, observability and governance, to generate a composite 0-100 Posture Score. The module authenticates via RFC 6749 §2.3.1 HTTP Basic authentication (base64-encoded client credentials) against the OneLogin Admin API v2 with region-aware endpoint resolution (US/EU). API calls support both v2 cursor-based and v1 Link-header pagination (up to 2,000 users, with lower caps for other resources), with structured error results that distinguish API failures from empty data. Client secrets are AES-256-GCM encrypted at rest and decrypted only within the edge function execution scope. Enterprise plan required.

Yes. The dashboard Posture tab includes a provider toggle that lets you switch between Okta, Entra ID, Google Workspace, AWS IAM Identity Center, PingOne, CyberArk Identity, and OneLogin. Every module runs 25 weighted checks, and all seven score them with the same penalty-ratio formula over the checks that ran, so posture scores are comparable across identity providers. Scan results are stored with a provider field for side-by-side analysis. Total coverage: 175 security checks across 7 providers.

The shield-supply-chain edge function (Enterprise) records build provenance for your own software artifacts. You submit an in-toto provenance statement; PasskeyBridge runs seven structural checks on it, records the builder, repository, source and artifact digests, assigns a SLSA (Supply-chain Levels for Software Artifacts) level from 0 to 4 based on what the statement shows, and stores the bundle you submitted. It is separate from Provenance Guard, the device provenance verifier.

The level is computed from the structural checks the statement passes and recorded with the attestation. For a Sigstore bundle, PasskeyBridge checks that it carries an inclusion proof or a signed entry timestamp; it does not verify the bundle's signature or query the Rekor transparency log. Treat the recorded level as the statement's claim, checked for shape.

Yes, in CycloneDX format beside a provenance attestation. PasskeyBridge records the SBOM's SHA-256 digest and up to 500 of its components, and stores a signature and signer identity you supply with it as given, without verifying them. PasskeyBridge does not sign SBOMs itself. This supports the software supply chain transparency expectations of EO 14028; it does not by itself satisfy them.

SDK Integrity Attestation is a RASP-lite (Runtime Application Self-Protection) check for signs of client-side SDK tampering, DOM injection, and AiTM proxy kits such as Evilginx2. A browser client submits an attestation payload and the shield-sdk-attestation edge function runs six checks on it. The reference client module that takes the measurements is not yet part of the published SDK, and the payload is plain JSON rather than a signed attestation, so it raises the cost of tampering without proving its absence. Zero PII is collected.

The six checks are: (1) Code Integrity: a SHA-256 of critical function sources, matched against a pinned manifest when one is set, to detect monkey-patching; (2) DOM Injection: scans for rogue phishing kit elements and hidden iframes; (3) TLS/Origin Verification: the page origin must exactly match an allowed deployment domain; (4) Proxy Detection: looks for proxy headers and globals associated with Evilginx and Muraena, and for Function.prototype.toString tampering; (5) Debugger Detection: a timing measurement that exposes active breakpoints; (6) Timing Integrity: the attestation's duration must fall within bounds, which rejects stubbed payloads.

EvilGinx2 operates by proxying the authentication page through an attacker-controlled domain. SDK Integrity looks for it with three checks: origin verification rejects non-allowlisted domains, proxy detection looks for Evilginx markers and toString() tampering, and DOM injection scans for rogue password fields and hidden iframes injected by the phishing kit. Failed checks are classified with threat types (aitm, evilginx, injection, tampering, debugger) for forensic analysis.

The Breakglass Protocol provides a documented, auditable mechanism for emergency access with multi-party approval: the 'who watches the watchers' control that SOC 2 and ISO 27001 reviews look for. Each request, approval, activation and revocation is written to the audit log.

Breakglass sessions have severity-based approval thresholds: P1 (Critical) requires 3 approvers with max 4-hour TTL, P2 (High) requires 2 approvers with max 2-hour TTL, P3 (Moderate) requires 1 approver with max 1-hour TTL. The requester cannot approve their own session, and each approver can only approve once. A session past its expiry is refused, and marked expired, the next time anyone tries to approve or activate it.

Five scopes: read (read-only data access), write (modify tenant configuration), admin (full administrative access), decrypt (access PII vault entries with purpose code), and rotate_keys (emergency key rotation). Scopes are set at request time and cannot be expanded after creation.

Cross-Tenant Threat Sharing enables privacy-preserving collaborative threat intelligence across the PasskeyBridge tenant network. Tenants contribute Indicators of Compromise (IOCs) as the SHA-256 hex digest of the normalized value; the server refuses anything else, keys each digest with HMAC-SHA-256 under its server-held key straight after validating the request, and stores, compares and returns only the keyed value. The digest a tenant sends is not stored or logged. When ≥ 3 independent tenants observe the same indicator hash, it surfaces in the network feed for all opted-in participants. The k-anonymity threshold lets the network surface convergent attack patterns without revealing which individual tenants observed them.

Indicators are only visible when at least 3 independent tenants have reported the same hash (k = 3). With k = 1, a specific tenant's observations would be leaked. With k = 2, correlation attacks are possible. At k = 3, any observer knows only that 'at least 3 organizations saw this indicator'—no individual tenant is identifiable. The threshold is enforced at both the RLS policy and application layers.

Ten types: ip_hash, email_hash, phone_hash, sim_hash, device_hash, fingerprint_hash, credential_hash, session_hash, agent_hash and domain_hash. Submit each value as the SHA-256 hex digest of its normalized form (E.164 for a phone number, such as +14155550123). The server refuses anything that is not 64 hexadecimal characters, so a raw value is never stored. The server keys every digest with HMAC-SHA-256 under its server-held key before the value is stored or compared; the unkeyed digest is never stored.

No. Threat sharing is strictly opt-in: contributing and reading the feed both require a subscription on the Threat Sharing tab, off by default, and unsubscribing stops both. When a tenant is removed, its contribution and subscription records are deleted with it.

A 27-category anomaly detection engine that scans audit logs and agent activity for anomalous behavior. It covers 18 human insider threat categories (off-hours access, privilege escalation, data exfiltration, credential hoarding, and more) and 9 agent/A2A threat categories (scope creep, lateral movement, trust gaming, delegation chain abuse, exfiltration tunneling). The engine uses behavioral baselines and configurable thresholds.

Nine agent-specific detectors analyze data from shield_agent_activity and shield_agent_delegates. They detect scope creep (scopes exceeding original delegation), velocity spikes (anomalous call volume), lateral movement (using unauthorized scopes), trust gaming (rapid re-attestation to inflate trust scores), credential harvesting, delegation chain abuse (sub-agents accumulating more privilege than parent), A2A exfiltration tunneling, dormant reactivation, and off-schedule execution. All detections use the delegate ID as the actor identifier.

The engine 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 ever analyzed. Behavioral baselines store rolling averages, known IP hashes, and known user-agent strings—all pre-hashed or non-PII metadata.

Yes. Ten configurable parameters control detection sensitivity: velocity_sigma (default 3.0), dormant_days (30), api_key_spree_threshold (5), breakglass_abuse_threshold (2), pii_spike_threshold (50), bulk_export_threshold (3), bulk_read_threshold (500), agent_velocity_threshold (200), agent_dormant_days (14), and agent_credential_threshold (3). Thresholds are tenant-scoped via shield_insider_policies.

SSF (OpenID Shared Signals Framework 1.0) and CAEP (Continuous Access Evaluation Profile 1.0)—both reaching final-form publication on August 29, 2025—are open standards for real-time cross-IdP security event propagation. SSF defines the transport (long-lived streams between Transmitters and Receivers); CAEP defines the event vocabulary. When an IdP detects a credential compromise, session hijack, or device compliance change, it publishes a Security Event Token (SET, RFC 8417) that PasskeyBridge ingests, validates, deduplicates by jti, and processes—all with zero PII storage. Supported event types: session-revoked, token-claims-change, credential-change, assurance-level-change, and device-compliance-change.

PasskeyBridge operates as both an SSF Transmitter (publishing events to downstream receivers) and an SSF Receiver (consuming SETs from external transmitters like Okta, Microsoft Entra ID, Auth0, ForgeRock, or any custom OIDC provider). Stream URLs are implementation-defined and discovered via the Transmitter's /.well-known/ssf-configuration document. An inbound SET must be a JWS signed under the JWKS of a verified receiver stream with a matching audience; it is then validated per RFC 8417 (iss, iat, jti, events), refused if issued more than 24 hours ago, and deduplicated permanently on issuer, jti and event type. A session revocation, a credential revoked, rotated, compromised or deleted, or a device reported not compliant runs the revocation cascade in-process on the same request, with no queue and no batch worker; other events are recorded. Subject identifiers are keyed-hashed with HMAC-SHA-256 under a server-held pepper; raw payloads are AES-256-GCM encrypted for forensic retention. Changing a stream (configure, update, delete, verify per §7.2) requires tenant admin authorization.

DPoP (RFC 9449, Proposed Standard, September 2023) binds OAuth 2.0 access tokens to client-held asymmetric key pairs, preventing token theft, replay, and AiTM (Adversary-in-the-Middle) session hijacking. A stolen bearer token is useless without the client's private key. PasskeyBridge implements DPoP via the shield-dpop edge function with five actions: bind, verify (seven-step validation), nonce (a server nonce per §8), introspect, and cleanup.

Shadow mode records DPoP coverage at the api-key-auth chokepoint without rejecting unbound traffic: whether each request carried a DPoP proof and whether the proof was well formed, without verifying its signature. A separate re-attestation endpoint (shield-reattest) tracks a shadow_degraded tier against a 15-minute interval when your client calls it, so security teams can quantify rollout coverage before flipping enforcement on. The shortest path to enable it is the 5-minute quickstart at docs.passkeybridge.io/guides/dpop-shadow-quickstart.

PasskeyBridge DPoP supports ES256, ES384, ES512 (ECDSA) and PS256, PS384, PS512 (RSA-PSS). EdDSA is not supported, because Web Crypto does not offer it in every runtime the platform runs on. Symmetric algorithms are explicitly rejected per RFC 9449 §4.2. DPoP proofs containing private key material are rejected. JWK Thumbprints are computed per RFC 7638 for binding identification. All access tokens are SHA-256 hashed before storage—zero plaintext token persistence.

Two per-tenant limits, both counted atomically in the database in the request path. Signal ingest allows a per-minute rate by plan (60 on Starter, 300 on Pro, 600 on Enterprise), counted per organization and source address. Most other API functions share one per-organization requests-per-minute quota, also set by plan, which refuses a request it cannot count rather than letting it through. A request over either limit gets a 429 with a Retry-After header. Platform operators see responses by status code on the admin console.

Every outbound call is checked before it is sent. Calls to vendors go through safeFetch, which enforces an explicit egress allowlist and rejects a non-allowlisted destination before any connection is made. Calls to addresses a tenant supplies (webhook callbacks, Security Event Token pushes, did:web resolution and JWKS fetches) must be HTTPS and are refused for private (RFC 1918), loopback, link-local and metadata-service hosts; all of them also check the address the name resolves to. Redirects are never followed, each call carries its own timeout, and a refused egress attempt is recorded.

The Anomaly Scanner is a platform-wide infrastructure monitor that runs every hour and compares the last hour with the 24 before it: event volume (a three-sigma test), error rate, mean latency, refused egress attempts, revocation cascade runs, and any single tenant producing most of the traffic. Each finding is written to the platform audit log for operator review.

The Canary Mesh is a set of three honeypot edge functions that no legitimate caller should ever reach. Any hit is recorded to shield_canary_hits. A real hit is posted to the operator alert webhook. shield-canary-verify probes every honeypot end to end every four hours, and platform admins can run it on demand; it classifies each result (ok, wafBlocked, dbWriteFailed, alertFailed, signatureAccepted), so a detection path that stopped working is found by the next run. The probe is synthetic and does not post.

A playbook's webhook_callback makes one attempt inside the ingest request, after checking the destination against SSRF rules and signing the body with HMAC-SHA-256 when a callback secret is configured. That attempt has its own 5-second deadline, inside the 8-second budget every playbook action gets, so a slow consumer cannot hold up the other actions. A network error, timeout, 429 or 5xx moves the delivery to a durable retry queue, drained every five minutes, for up to 4 attempts in total; a redirect or any other 4xx is final. Every attempt, failures included, is logged with status code, latency, and response body for forensic review.

The public status page at passkeybridge.io/status shows nine component rows checked live from your browser every minute (API Gateway, Signal Ingest, Carrier APIs, Cascade Engine, DPoP Service, SSF/CAEP Relay, NTP / Atomic Clock, Identity Layer, BLAST Tunnel), plus a 30-day uptime rollup and a strip of recent platform snapshots read from shield_health_snapshots, which the shield-health edge function writes every 15 minutes. Anyone can open the page.

Each tenant has its own ECDSA signing key, P-256 (ES256) by default or P-384 (ES384) with the ML-DSA-87 add-on. It signs the tenant's verifiable credentials, the Security Event Tokens it sends to SSF receivers, hosted passkey session attestations and entropy provenance receipts, and its public half is published in the tenant's DID document. Webhook callbacks are signed separately with the callback secret, and DPoP proofs are checked against the client's own key. How the key rotates is answered under Key Rotation.

The client polls /build-id.json at a low cadence and compares it to the bundle's embedded build ID. On mismatch a sticky reload toast is shown so users never get trapped in a half-broken lazy-chunk error state from a long-running tab. Combined with route-level prerendering this keeps marketing and dashboard surfaces resilient through frequent deploys.

The Shadow Identity Proxy issues ephemeral proxy values (virtual card numbers, PNR booking codes and loyalty identifiers) that let downstream systems transact for a user without learning the real value. Proxy values are AES-256-GCM encrypted at rest and expire, after 24 hours by default. They are deactivated when an admin revokes them, when a playbook runs step_up_auth or quarantine, when the revocation cascade runs, and when an AI assessment the hallucination guard did not flag rates the subject's risk above 0.95. If a SIM swap or another hard signal arrives for a user, that user's active shadow identities are frozen on the same request, and no other user's. Enterprise plan required.

The Cached Proof System manages offline trust tokens that allow identity verification to continue when network connectivity is unavailable (airplane mode, rural areas, underground venues). Each proof is encrypted at rest with AES-256-GCM and identified by a SHA-256 proof hash, and carries a hybrid HMAC-SHA-256 and ML-DSA signature when post-quantum signing is on. Its lifetime is set when it is issued (1 to 720 hours, 72 by default), and a trust level (standard, high, critical) is recorded with it. When the device is back online, your application calls revalidate to confirm the proof is still valid. Enterprise plan required.

Deterministic Cross-Reference creates cryptographic bindings between SIM/carrier attestation signals (Pillar I), Verifiable Credential subjects (Pillar II), and optionally WebAuthn passkey credentials (Pillar III). It establishes verified entity profiles with match scoring. Low-entropy identifiers are keyed-hashed with HMAC-SHA-256 under a server-held pepper (non-enumerable); VC subject identifiers are keyed the same way (case preserved), so no plaintext PII is at rest. When post-quantum signing is on, each cross-reference created through the cross-reference API carries a hybrid HMAC-SHA-256 and ML-DSA-65 signature. Enterprise plan required.

BLAST (Biometric-Linked Asymmetric Session Tunnel) is the encrypted transport protocol used for Shadow Proxy delivery. Each session agrees a key over X25519 with a fresh server key pair, derives an AES-256-GCM key with HKDF-SHA-256 and a quantum-seeded salt, and encrypts proxy values under it, so a proxy value intercepted in transit cannot be read without the session's shared secret. Session secrets are stored encrypted. An expired session is refused, and sessions are torn down on request, by the revoke_tokens playbook action, or by the revocation cascade.

No. The hosted passkey relying party, the Shadow Identity Proxy, the Cached Proof System, Deterministic Cross-Reference, the AI Intelligence Layer, Spatial Binding, identity posture management (ISPM), the PII vault and every module in the dashboard's Security section (session tunnels, revocation cascade, device provenance, supply chain, SDK integrity, breakglass, threat sharing and insider threat) are Enterprise features, as are post-quantum signing of cross-references and cached proofs and the ML-DSA-87 add-on. The Enterprise plan is $499/mo.

The Intelligence Layer is an asynchronous AI-powered risk analysis engine that enriches every live signal of an Enterprise organization with contextual threat intelligence. Each assessment carries attribution weights in the style of SHAP values, assigned by the model and checked for consistency, showing which signal attributes contributed most to the risk score. Results are written to a dedicated intelligence table and surfaced in the Enterprise dashboard's Intelligence tab.

No. The Intelligence Layer is dispatched fire-and-forget once the event is stored, and the ingest response never waits for it. Your signal-to-playbook execution time is unaffected. An assessment appears in the dashboard once the model answers, within the 10-second limit on the model call.

Every AI assessment carries an 'is_hallucination_check' flag, set when the model reports low confidence or when a cross-check against your organization's recent history finds a critical inconsistency or three or more warnings. Flagged assessments are stored, marked as unreliable in the dashboard, and have no automatic effect: they freeze no shadow identities and adjust no agent trust score. On a hard-signal event the risk score is raised to at least 0.7 and a 'clean' verdict is overridden, so the model cannot downgrade a confirmed signal. The AI can only escalate: an assessment that is not flagged can freeze the subject's shadow identities above a 0.95 risk score and lower agent trust scores, and none can unblock or approve anything.

Yes, for Enterprise organizations, to xAI, which is listed among the sub-processors in the Privacy Policy. The model receives the event's type, result, risk score, response time and metadata, the first 12 characters of the subject's keyed phone digest, the actions that ran, and the same basic fields for your organization's 25 most recent events with 8 characters of each digest. The keyed digests cannot be reversed without the server-held pepper, and no raw phone number or email address is sent.

No. The AI Intelligence Layer runs for Enterprise organizations only ($499/mo), on live traffic; test-mode and sandbox signals are not analyzed. Enterprise tenants see the Intelligence tab automatically in their dashboard.

Guardian approval for dashboard account recovery, without support calls or SMS resets (which are vulnerable to SIM-swap). A dashboard user designates guardians from their own organization, and a recovery request needs approval from a threshold of them (2 by default, up to 10), so no single guardian can approve it alone. Guardians approve from their own signed-in accounts, and each step is recorded in the audit log. Today the workflow records an approved request: completing it does not yet restore access by itself, and the owner has to be signed in to open one.

From the dashboard, add guardians by email address. The address is keyed-hashed (HMAC-SHA-256 under a server-held pepper) before storage and used only to send the invitation. Each guardian confirms the request from their own account, and you set the threshold: how many guardians must approve, 2 or more.

Not about your end users. Phone numbers are keyed-hashed with HMAC-SHA-256 under a server-held pepper before storage (non-enumerable). Verifiable credential contents are redacted to field names only. Biometric data remains exclusively on the user's device (Secure Enclave / TPM). Guardian emails and agent tokens are hashed. Shadow proxy values are AES-256-GCM encrypted. Atomic Fingerprints store only hashes, never raw sensor data. The personal data PasskeyBridge does hold is ordinary account data about the people who use the dashboard: a sign-in email address, a display name, and a password hash kept by the authentication service, covered by the Privacy Policy.

API keys are SHA-256 hashed before storage. The raw key value is displayed only once at generation time. Keys are scoped to specific capabilities (ingest, events, metrics, vc_issue, vc_verify, vc_revoke, spatial, scim, okta_hooks, dpop, supply_chain, passkey_rp, passkey_rp_import, receipts) so you can follow least-privilege principles. Callback payloads are signed with HMAC-SHA256 so you can verify authenticity on your end.

We are in SOC 2 Type II readiness only: evidence is collected and under review. No audit firm is engaged yet and no audit is scheduled, so we are not certified, attested, or compliant; we are evaluating audit firms. Our append-only event log, zero-PII storage, tenant isolation via Row-Level Security, HMAC-SHA256 payload signing, and scoped API key model map to the Trust Service Criteria for security, availability, and confidentiality. Programme status lives on the Trust Center.

Dashboard queries run under Row-Level Security (RLS) policies enforced by the database, so a signed-in user reads only their own organization's rows. Edge functions run with a service role that bypasses RLS; they authenticate the tenant first and scope every query to it in code. Tenants cannot access each other's data, API keys, playbooks, events, VC providers, or webhook configurations. The deliberate exceptions are the opt-in threat-sharing feed, which shows an indicator only after three organizations report it, and the public platform health snapshots.

Because of our zero-PII architecture, a copy of the identity-signal tables would expose only keyed HMAC-SHA-256 digests of phone numbers and emails (non-enumerable without the server-held pepper, which lives outside the database), SHA-256-hashed API keys and agent tokens, AES-256-GCM encrypted proxy values and provider credentials, and event metadata: no plaintext identifier of your end users, no credential contents, no raw sensor data. Your users' biometric data never touches our servers. Account data about dashboard users (sign-in email addresses, display names, and password hashes kept by the authentication service) would be exposed as in any SaaS account table.

The Bulk PII Migration tooling provides a structured workflow for encrypting legacy plaintext columns (today display_name in profiles) and permanently shredding the plaintext after manual confirmation. It processes up to 500 rows per batch, logs every operation to an auditable migration run table, and enforces a pre-flight coverage check before allowing plaintext deletion. It sits in the dashboard Settings tab under data governance and compliance, and requires both the platform admin and tenant admin roles.

On /auth you can sign in with a passkey (where the browser supports WebAuthn), Continue with Google, Continue with GitHub, Continue with Microsoft (SSO), which initiates a domain-scoped SAML AuthnRequest against your Microsoft Entra ID tenant, or an email address and password. A new account can also be created with an emailed sign-in link, and passkey enrollment is offered after your first email-verified sign-in. Your organization is created together with your account, so every path leads straight into the dashboard.

The Google button signs you in through PasskeyBridge's own Google OAuth client, configured in our authentication service, so there is no Google Cloud project for you to create and no client secret to store. After Google returns, the session is set in the browser and /auth/callback forwards you to the dashboard; a first sign-in creates your account and organization the same way an email signup does.

The Microsoft button reveals a work-email field. We extract the domain, call shield-sso-lookup to check whether that domain has a verified SAML provider on file, and—if it does—invoke supabase.auth.signInWithSSO({ domain }). Supabase emits the SAML AuthnRequest to your Entra ID tenant, the user authenticates, and the IdP returns a SAML Response that lands them on /auth/callback. If the domain is not registered, we surface a friendly "your organization isn't set up for SSO yet" message instead of letting Microsoft show a generic error page.

Onboarding is a one-time configuration per Entra ID tenant: register PasskeyBridge as an Enterprise SAML application in the Azure portal, assign the users or groups that should have access, and send the federation metadata (or Entity ID, SSO URL, and signing certificate) to sales@passkeybridge.io. We register the domain in our managed SAML SSO flow on our side. After that, anyone in your tenant with a matching email domain can sign in via the Continue with Microsoft button.

No—they solve different problems and run on independent code paths. Continue with Microsoft (SSO) is how a member of your team signs into the PasskeyBridge dashboard using their Entra ID credentials via SAML. Entra ID ISPM (covered in the Enterprise SSO & SCIM section) is an Enterprise feature that authenticates outbound to your tenant via OAuth 2.0 client credentials and the Microsoft Graph API to audit your security posture. You can use either independently, or both together. The same distinction applies to the Google sign-in button vs. the Google Workspace ISPM module.

Yes. Google, GitHub and Microsoft sign-in are available to every tenant, including the free Starter plan, at no additional fee. Google and GitHub run through PasskeyBridge's own OAuth clients and Microsoft through our standard SAML SSO path.

Yes. @passkeybridge/vc-wallet-sdk is published on the public npm registry (v0.6.0 at the time of writing; requires Node >= 20.19). It covers W3C Verifiable Credential storage, OpenID4VP presentation flows, and the in-browser wallet primitives. Install with `npm i @passkeybridge/vc-wallet-sdk`. Source-of-truth release notes live on the /sdk page and in the public changelog.

Yes. /developers/playground is a public, no-auth tool that issues real requests against our live /health endpoint. You can run a single ping or a 10-request burst and see p50, p95, and p99 latency from your own browser. The page reports the figures it measured from your own network. There is no free-tier consumption associated with playground pings.

Two paths. The public Trust Center (/trust-center) summarises our control programme and links the publicly downloadable readiness pack. For the full SOC 2 evidence bundle, submit the self-serve request at /security/soc2-request; the form accepts work email addresses only. Requester contact details are encrypted at rest with pgcrypto's OpenPGP symmetric encryption under a key held in the managed secrets vault, and decrypted only through gated admin and notification functions.

The /status page renders a live nine-component breakdown of platform health (API Gateway, Signal Ingest, Carrier APIs, Cascade Engine, DPoP Service, SSF/CAEP Relay, NTP / Atomic Clock, Identity Layer, and BLAST Tunnel). A separate cron writes composite snapshots to the shield_health_snapshots table every 15 minutes as SOC 2 readiness evidence; the /status page renders both the live breakdown and a 30-day daily uptime rollup derived from those snapshots.

Yes. The Starter plan includes 100 signals per month, 1 playbook, and 7 days of guaranteed event history, free forever. It's designed for prototyping and low-volume production use. Starter signup does not ask for a card.

It depends on your plan. Starter stops accepting signals at 100 in a calendar month, answering 429 until the next month or an upgrade. Pro includes 10,000 signals per billing period with no metered overage: past the allotment, signals keep flowing and the dashboard prompts an upgrade to Enterprise. Enterprise includes 1,000,000 signals per billing period; usage beyond that is billed at $0.04 per signal via Stripe metered billing, tracked hourly and reported automatically. If a paid subscription's renewal fails and Stripe's retries run out, the organization is held to the Starter allotment until the open invoice is paid. You can monitor usage in the dashboard's Usage tab.

Every accepted live signal is recorded into your hourly usage ledger (shield_usage) at ingest time. A scheduled reconciliation worker (shield-usage-billing) folds those rows into a per-period ledger each hour. For Enterprise tenants, any usage beyond the included 1,000,000 signals is reported to Stripe as metered usage on the subscription's Signal Usage price ($0.04 per signal); Stripe attaches the overage line to your next invoice, and the base subscription charge is unaffected. Pro has no metered overage: the 10,000 included signals are a soft allotment, and the upgrade path is Enterprise. The dashboard's usage card shows an in-product estimate based on your current daily average; the figure on your Stripe invoice is the source of truth. Neither paid plan drops a signal for going over its allotment.

There is no separate license. Pro ($99/mo) includes Pillar II (Legal Identity) alongside Pillar I, and Enterprise ($499/mo) adds Pillar III (Biometric Binding) through the hosted passkey relying party. Pricing is usage-based with no per-seat fees. The free Starter plan covers Pillar I.

Yes. Moving between paid plans takes effect immediately, and Stripe prorates the difference. Start an upgrade from the pricing page or from the billing portal on the dashboard Billing tab; a move from Enterprise to Pro is made from the pricing page. Canceling in the billing portal takes effect at the end of the billing period, when your organization moves to the free Starter plan. The billing portal also manages payment methods and invoices.

The guided setup wizard gets a first test signal flowing in three steps: (1) generate a scoped API key, (2) set a webhook callback URL, which you can skip, and (3) send a test signal. Your organization already exists when your account does; if it somehow does not, the wizard creates it first. Playbooks have their own builder.

Every guided wizard (Ingest, Alerting, Playbook Builder, Agent Delegation, VC Onboarding) emits start, step, complete, and abandon telemetry to your tenant's onboarding log. The dashboard's Onboarding tab shows which wizards you have started, completed, or left in progress so you always know what to do next. Drafts of in-progress wizards are also persisted locally (excluding any secrets) so you can resume where you left off.

The dashboard has a Workspace section with three tabs: Team, Recovery and Support. Team lets a tenant admin invite an existing PasskeyBridge user by email as a member or viewer, move a non-admin between member and viewer, or remove a non-admin member. Invitations never create anonymous accounts; the invitee must already have a PasskeyBridge account. Only tenant admins see these controls; everyone else sees a read-only roster.

Use the Support tab inside the Workspace section of the dashboard. It lists your organization's 50 most recent tickets, and a tenant admin can open a new one with a title, description, priority and category, scoped to your organization.

Every dashboard page has a notification bell that delivers organization-scoped notifications in realtime, with a severity (info, success, warning or critical), an optional link to the relevant tab, a mark-as-read action and an unread badge. Today the notifications come from team changes such as an invitation; alerts about signals reach you through your playbooks' email, Slack and webhook actions.

Yes. The dashboard's Audit log tab shows tenant admins your organization's 200 most recent audit entries, scoped by row-level security so you never see other tenants' activity, and exports them as CSV without contacting support.

Yes. The API Docs tab in the dashboard documents the core endpoints, and an OpenAPI 3.1 specification is served at api.passkeybridge.io/openapi-spec, covering signal ingestion, VC engine operations, SCIM provisioning, Okta hooks, spatial binding and agent delegation. Some newer endpoints, including DPoP, SSF/CAEP and the hosted passkey relying party, are not in the specification yet; the documentation site covers them.

Yes. The dashboard's Test Simulator sends synthetic signals through your ingest pipeline with your dashboard session (no API key needed), and they are stored flagged as test traffic and never metered. Your playbook matches and runs as it would for a live signal, except that email, Slack and webhook actions are recorded as simulated rather than sent. To exercise real deliveries, send a signal with a live API key.

Signal ingestion accepts any JSON payload via POST. The only required field is event_type (string). Common optional fields include phone (E.164, keyed on arrival) or phone_hash (a 64-hex digest of the phone number that you compute, which the platform keys again with HMAC-SHA-256 under a server-held pepper before storage), risk_score (numeric 0-1), source_id (an identifier for the sending system, stored on the event), and metadata (arbitrary JSON). The payload itself is not stored: the event keeps its type, the keyed digest, the risk score and the results of the playbook's actions.

Not yet: no patent has been granted. 20 US patent applications filed (7 non-provisional, 13 provisional).

PasskeyBridge LLC is a Wyoming limited liability company located at 5830 E 2nd St., Ste 7000 #33652, Casper, WY 82609. General inquiries: support@passkeybridge.io. Data protection: dpo@passkeybridge.io.

Each plan guarantees how long your event history stays available: Starter 7 days, Pro 90 days, Enterprise 2 years, and webhook delivery logs follow the same schedule. Usage data is retained for billing purposes. Events hold keyed digests and operational data (event types, latency metrics, action results), not plaintext personal information. The Privacy Policy states retention for every category of data we hold.