An MFA alternative that replaces the second factor with passkey and carrier-state checks.
SMS OTP is phishable, TOTP apps are lost on device swaps, and push fatigue is a documented MFA bypass. PasskeyBridge binds a FIDO2 passkey to live carrier state and verifies both in one request.
- Replace SMS OTP without adding a new authenticator app.
- Eliminate push-fatigue prompts by removing the extra confirmation step entirely.
- Bind auth to the SIM state at request time.
- Sit in front of Okta, Entra, Ping, or OneLogin—no IdP migration.
Why classic MFA is losing ground
Each of the three common MFA modes has a known weakness. SMS OTP can be redirected by a SIM swap or port-out. TOTP codes can still be phished, and losing the device sends the user to a recovery flow. Push-based MFA can be defeated by push bombing: an attacker sends repeated prompts until the user approves one.
What replaces the second factor
A FIDO2 passkey is phishing-resistant by construction, and origin binding kills the reverse-proxy phishing kit. A relying party can require the passkey to be hardware-bound, which refuses a credential that can sync. That is the credential half of the problem solved.
The device-holding-the-credential half is where PasskeyBridge adds a carrier-state layer. We verify, in the same request, that the SIM tenure on the account's line has not just changed, that the device attestation is fresh, and that the passkey assertion is signed with a hybrid classical plus ML-DSA-65 scheme so the attestation stays valid past the post-quantum transition.
- WebAuthn + DPoP (RFC 9449) binding: the passkey is proven to be in-hand at request time.
- Carrier tenure and port-out checked live at request time.
- Hybrid signature on every assertion so audit evidence stays valid past 2030.
Where it plugs in
PasskeyBridge sits in front of Okta, Entra, Ping, or OneLogin as an assertion source and a verification gate, and your identity provider stays in place. Existing MFA can be phased out one user cohort at a time—high-value accounts first, then everyone else once the operational data proves out.
For teams running a homegrown auth stack, the integration is a REST call. Passkey enrollment uses WebAuthn in the browser. There is no separate browser helper package.
The PasskeyBridge approach
One request, both checks
Passkey assertion and carrier-state verification return in a single response, with no serial round-trip. Our part of that response is the decision path we measure; where a live carrier lookup is involved, the carrier network adds its own time.
Run a live probe →Zero PII stored
Phone numbers and other low-entropy identifiers are hashed with keyed HMAC-SHA-256 under a server-held pepper before they touch storage. Matching stays possible because the digest is deterministic; reading does not, because the pepper never leaves our servers.
Privacy architecture →Post-quantum by default
Every verifiable credential and passkey session attestation is dual-signed: classical ES256 or ES384 plus detached ML-DSA-65 (NIST FIPS 204). The detached ML-DSA signature covers the JWS signing input followed by `:qnonce:` and a quantum-seeded nonce that travels with the signature.
Whitepaper →How PasskeyBridge fits with your MFA
PasskeyBridge is a verification layer that reads the signals your existing IdP and platform already emit, checks them against live carrier state, and returns a signed decision. Authenticator apps, push services and user enrollment stay with your existing vendors.
Frequently asked
- Is a passkey plus carrier check really equivalent to two factors?
- Under NIST SP 800-63-4 the passkey is a possession factor (something you have) plus a verifier presence check. Carrier state is a separate, independently verifiable signal about the device's telecom binding. The combination provides multi-factor assurance in one interaction rather than two sequential prompts, and it is auditable because both signals are signed into the same attestation.
- What happens when a user changes their SIM legitimately?
- Carrier tenure is a scored signal. A fresh SIM raises the risk score for a defined recovery window and can trigger step-up.
- Can we phase out SMS OTP gradually?
- Yes. You can enable passkey plus carrier-state as an additional method for high-value accounts, watch the operational metrics, then make it the default and keep SMS OTP as a recovery-only path, one cohort at a time.
- Does this work in call-center or IVR flows?
- Yes. A voice channel cannot carry a passkey, so the check uses carrier state and account-line binding. The same verification API is used; the response is consumed by the IVR router or agent desktop instead of a browser.
- How do we measure latency ourselves?
- The /developers/playground page sends GET /health requests to production from your browser. Send a single request or a burst of ten and read the minimum, p50, p95, p99 and maximum round trip.
Guides for this
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production.