Persona verifies an identity at onboarding. PasskeyBridge responds to what happens to it afterwards.
Persona is a strong KYC and document-verification platform built around the onboarding moment. PasskeyBridge works in the continuous lane after it: carrier signals, passkeys and dual-signed verifiable credentials that your stack can check at sign-up and at any later point in a session.
Different problems, different lifecycles
Persona was built to answer one question with high confidence: is the human applying right now who they claim to be? It does this with document capture, selfie liveness, database checks, and configurable inquiry flows. That work matters, and for regulated onboarding Persona does it well.
PasskeyBridge is built to answer a different question, every minute after onboarding: is the identity holding this session still trustworthy right now? Identifiers move. SIMs get swapped. Sessions get hijacked. Devices get stolen. Tokens get replayed. ITRaaS—Identity Threat Response as a Service—is the discipline of detecting and responding to those changes as they happen.
They answer different questions. A regulated stack often uses both: document verification at onboarding, and continuous checks after it.
Data model: PII vault vs keyed HMAC-SHA-256 identifier digests
Persona, by the nature of KYC, must store rich PII: passports, driver's licenses, selfies, dates of birth, addresses, and the verification artefacts derived from them. Regulated onboarding requires that data, and holding it creates a high-value breach target and a heavy compliance perimeter (SOC 2, ISO 27001, GDPR, state privacy laws, sectoral regimes).
PasskeyBridge intentionally never retains plaintext PII. Low-entropy identifiers—phone numbers, email and IP addresses, subject identifiers—are hashed with keyed HMAC-SHA-256 under a server-held pepper before they are stored. Keying is what makes that safe: an unkeyed SHA-256 of a phone number is reversible by enumeration, whereas without the pepper the keyed digest discloses only equality. We can match the same identifier across signals (which is what threat detection requires) without keeping it in a readable form. The trust posture, the audit story, and the breach blast-radius are categorically different.
- Tenant rows isolated by Row-Level Security.
- No primary identifiers in plaintext; no document images stored anywhere on platform.
- Hybrid post-quantum signatures (classical + ML-DSA) on every credential and passkey session attestation PasskeyBridge issues, so that evidence does not depend on a classical signature surviving a cryptographically relevant quantum computer.
- Edge-first architecture keeps the trust decision on one pass: authenticate, resolve the tenant, hash the identifier, match a playbook. Decision latency is recorded on every event and shown to you in the dashboard, rather than asserted. A carrier lookup adds the carrier network's own time on top, which is theirs and not ours to promise.
Latency budgets
Persona inquiries are interactive flows; users expect them to take seconds, sometimes minutes for manual review. That's the right budget for onboarding.
PasskeyBridge is built to be called in the request path: when a session is checked, when one agent calls another, before a step-up prompt or a policy decision. A control in that position has to stay fast enough that teams do not disable it or sample it. The architecture (edge routing, hashed lookups, in-process revocation, no third-party call before the decision is made) exists to defend that budget.
Overlap and differences
Both platforms care about identity assurance. Both surface signals you can act on. The overlap stops there. Persona's centre of gravity is the document, the selfie, and the inquiry. PasskeyBridge's centre of gravity is the carrier signal, the passkey, the verifiable credential, and the response playbook that fires when something looks wrong.
If you need to onboard a customer in California with a driver's license, Persona is the right tool. If you need to learn that the same customer's SIM was swapped twelve minutes ago and have your backend revoke their refresh tokens before the attacker drains the account, PasskeyBridge is the right tool. The useful question is which one is missing from your stack today, and what that gap costs.
What enterprises typically buy alongside what
A common stack is a KYC vendor at onboarding (Persona, Onfido, Veriff, or an in-house equivalent), an IdP for primary auth (Okta, Microsoft Entra, Auth0), and a continuous identity threat layer that consumes signals from carriers, devices, and the IdP. PasskeyBridge is built for that third slot, with Okta hooks, SCIM, CAEP/SSF, and JIT credential issuance.
Document capture, liveness checks and selfie pipelines stay with Persona. Adding PasskeyBridge to your continuous identity controls takes a public OpenAPI, x-pb-api-key auth, edge functions that ingest carrier signals, and an organization that exists as soon as your account does.
Capability matrix
Side-by-side: PasskeyBridge vs Persona. Evaluated against publicly documented product capabilities.
Evaluation based on publicly documented Persona product capabilities as of Q2 2026. Persona is a registered trademark of Persona Identities, Inc.; this comparison is independent and not endorsed by Persona.
Frequently asked
- Does PasskeyBridge replace Persona?
- No. Persona handles KYC and document verification at onboarding. PasskeyBridge handles continuous identity threat response after onboarding. They sit in different lanes and most regulated stacks need both.
- Can a KYC platform add continuous monitoring?
- The data model fights you. KYC platforms are built around storing rich PII so they can re-verify a person against the same evidence. PasskeyBridge stores identifiers as HMAC-SHA-256 digests keyed with a server-held pepper, so signals can be matched by equality without storing the raw identifier.
- How fast is PasskeyBridge in practice?
- Our public /developers/playground runs real /health probes against the production edge from your own browser and shows what it measured, so you can time it yourself. On the decision path itself, the platform records decision_ms server-side on every request.
- Do you store any PII at all?
- Not as primary identifiers. Low-entropy identifiers are hashed with keyed HMAC-SHA-256 under a server-held pepper, which makes a leaked digest non-enumerable without a secret that never leaves our servers. The pepper is a single server-held key rather than a per-tenant salt, so the same identifier hashes to the same value across tenants—that is deliberate: it is exactly what our k-anonymous cross-tenant threat sharing relies on to recognize an indicator seen by multiple tenants. SCIM provisioning touches your team's dashboard accounts rather than your end users: it links an existing account by email and stores the display name and your IdP's external id with the membership, which is ordinary account data under the Privacy Policy.
- Can we run PasskeyBridge alongside Persona?
- Yes. Persona handles onboarding KYC, PasskeyBridge checks identity during the session, and Okta or your IdP grants access. PasskeyBridge provides carrier signals, passkey binding and revocation cascades.
See it on your own traffic
Spin up a tenant in under two minutes. Send your first signal, inspect the verifier response, and decide.