Persona verifies an identity at onboarding. PasskeyBridge responds to what happens to it afterwards.

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 the moment they happen, not at the next quarterly access review.

Treating these as the same product is a category error that costs enterprises money and exposure. The right architecture is usually both: KYC at the door, ITRaaS in the building.

Data model: PII vault vs zero-PII hashed signals

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.

Where they overlap, and where they don't

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

In production stacks we have observed the same pattern repeatedly: 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 itself. PasskeyBridge fills that third slot, with a clean handoff into Okta hooks, SCIM, CAEP/SSF, and JIT credential issuance.

Replacing Persona with PasskeyBridge is not a supported migration because we don't do KYC—we don't capture documents, we don't run liveness checks, we don't operate selfie pipelines. Replacing or augmenting your continuous identity controls with PasskeyBridge is, by contrast, a near-drop-in: a public OpenAPI, x-pb-api-key auth, edge functions ready to ingest carrier signals, and an organization that exists as soon as your account does.