Account takeover prevention without adding another OTP step.
When a credential and a device have changed hands, both still check out, so tighter OTP and device fingerprinting do not flag the login. PasskeyBridge binds the session to live carrier state and a passkey. A relying party can require that passkey to be hardware-bound.
- Kill credential-replay ATO where OTP and device fingerprint both pass.
- Catch overnight SIM-swap and port-out inside the auth path. A recycled number arrives as a number_recycle signal a tenant posts.
- Recovery flows get the same carrier-state check as login.
- Deploy without disrupting your existing fraud stack or user experience.
Why current ATO controls miss
A common ATO pattern replays a purchased or phished credential against an account whose owner still holds the phone. The credential is valid, the OTP delivers to the attacker via a real-time relay, and the device fingerprint on the attacker's browser matches nothing on file—so the risk engine calls it a new-device login and shows the OTP prompt that the attacker then satisfies.
Neither the credential check nor the device check nor the OTP is broken in isolation. What is broken is the assumption that any of them is a proof of possession by the account holder at request time.
What binding to live signal changes
PasskeyBridge replaces the assumption at the base of the risk model with a signed proof: at this exact request, a passkey is being asserted, and the carrier line tied to this account is in a state consistent with the account holder still holding it. A relying party can require that passkey to be hardware-bound, which refuses a credential that can sync. If the check fails, the request fails—before the money movement, credential change, or session mint.
The mechanism catches the two ATO variants that eat the largest chunk of loss on most reports: credential-replay-on-clean-device (attacker has the password, victim still has the phone) and SIM-swap-then-recovery (attacker owns the line for a 24-hour window and drives recovery flows through it).
- Login gate: passkey assertion plus a fresh carrier tenure check. Hardware-bound is an opt-in policy on the relying party.
- Recovery gate: same checks; SIM swap or port-out inside the last N hours hard-fails.
- High-value action gate: DPoP-bound possession proof re-verified per request.
- Signed attestation as an audit artefact for every decision, replay-verifiable.
What operators typically look for
The pattern teams tend to prioritise: credential-replay ATO first, then recovery-flow fraud once the same signal is applied there. The signal is a cryptographic proof with well-defined states, so false-positive tuning works against those states.
Downstream vendor spend on the clean-traffic path also tends to fall, because the pre-decision signal filters the population that hits heavier fraud checks. Actual lift is baseline-dependent and worth measuring against your own numbers before committing to a wider rollout.
The PasskeyBridge approach
Replay-proof by construction
A passkey plus DPoP request signing means a captured credential cannot be replayed from a different origin. A relying party that requires a hardware-bound passkey also refuses a credential that can sync.
Playground: hit the endpoint →Carrier state at request time
SIM-swap and porting status looked up with your carrier data provider inside the auth call. Recycled numbers arrive as a signal a tenant posts.
Carrier signal thesis →Recovery is a first-class gate
The recovery flow runs the same carrier-state and passkey checks as login.
Recovery architecture →How PasskeyBridge works with your rules engine
PasskeyBridge emits one class of signal, cryptographic proof-of-possession plus live carrier-state binding, that your existing rules engine consumes as a hard input. Fraud rules, velocity checks and behavioural risk models stay in your rules engine.
Frequently asked
- How is this different from adaptive MFA?
- Adaptive MFA raises the challenge friction when risk looks high—usually another OTP or push prompt, both of which attackers already satisfy in modern ATO workflows. This changes the primitive: a passkey is phishing-resistant by construction, a relying party can require it to be hardware-bound, and the carrier-state check runs on the request itself, so a relayed OTP or push approval does not satisfy it.
- What is the false-positive impact on legitimate users?
- The two signals fail cleanly on distinct scenarios: hardware-passkey assertion fails when the user is on a new device, which is a normal enrolment event; carrier-state fails when the SIM or line has actually moved (SIM swap or port-out). Recovery for both runs through biometric re-enrollment or guardian-based recovery.
- Does this handle synthetic and mule accounts, or only takeover of real accounts?
- Both. For synthetic and mule onboarding, the human-plus-device-plus-line binding attestation at account creation catches accounts that pass IDV but cannot back the binding with a real, personally-held line. For real-account takeover, the same signals are checked at each subsequent high-value action.
- Can we run this as a hard block or as a score input?
- Either. Teams typically start by feeding the signed attestation into their existing rules engine as one high-weight input, then move to hard-block mode for the specific decisions where the signal has the largest measured impact (recovery, high-value money movement) once the operational data proves out.
- How do we measure lift accurately?
- The cleanest baseline is credential-replay ATO with matching device fingerprint on the attacker session—the specific fraud mode current controls miss. Instrument that population before and after enabling PasskeyBridge on the login gate. We can share the measurement template teams have used to run this properly.
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production.