Persona verifies an identity once. PasskeyBridge verifies every signal, continuously.

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. That data unlocks regulated onboarding but also 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 touch our infrastructure. 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 ever being able to read it. The trust posture, the audit story, and the breach blast-radius are categorically different.

• Per-tenant key isolation; one tenant's hashes are not comparable to another's.
• No primary identifiers in plaintext; no document images stored anywhere on platform.
• Hybrid post-quantum signatures (classical + ML-DSA-65) on every attestation, so historical evidence remains verifiable past CRQC.
• Edge-first architecture keeps the trust decision on one pass: authenticate, resolve the tenant, hash the identifier, match a playbook. Decision latency is recorded per request and published, 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 runs in the request path of authenticated sessions, agent-to-agent calls, step-up prompts, and policy decisions. A control in that position has to stay fast enough that teams do not disable it or sample it. Our entire architecture—edge routing, hashed lookups, in-process cascade dispatch, no synchronous third-party calls in the hot path—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 hardware-bound 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 detect that the same customer's SIM was swapped twelve minutes ago and revoke their refresh tokens before the attacker drains the account, PasskeyBridge is the right tool. Which one wins is the wrong comparison. The honest one asks which 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 a tenant you can stand up in under two minutes.