Account takeover prevention without adding another OTP step.
ATO loss keeps climbing even after OTP is tightened and device fingerprinting is layered on, because the credential and the device both check out—they have just changed hands. PasskeyBridge binds every session to live carrier state and a hardware passkey, so credential replay on a clean device still fails.
- Kill credential-replay ATO where OTP and device fingerprint both pass.
- Catch overnight SIM-swap and silent number recycling inside the auth path.
- Recovery flows get the same carrier-state check as login, not a weaker one.
- Deploy without disrupting your existing fraud stack or user experience.
Why current ATO controls miss
In 2026 the dominant ATO pattern is credential purchase or phishing kit output being replayed against accounts where the victim still holds the phone, rather than credential stuffing against unpatched accounts. 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 does not add another challenge. It replaces the assumption at the base of the risk model with a signed proof: at this exact request, a specific hardware-bound passkey is being asserted, and the carrier line tied to this account is in a state consistent with the account holder still holding it. If either 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: hardware-passkey assertion plus fresh carrier tenure check.
- 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, because it is the fraud mode current controls miss most cleanly, then recovery-flow fraud once the same signal is applied there. Because the signal is a cryptographic proof rather than a probabilistic score, false-positive tuning is bounded by well-defined signal states rather than a moving ML threshold.
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
Hardware-bound passkeys plus DPoP request signing means a captured credential cannot be replayed from a different device, full stop.
Playground: hit the endpoint →Carrier state at request time
SIM tenure, port-out, and silent number recycling checked on the live carrier line inside the auth call, not a nightly batch job.
Carrier signal thesis →Recovery is a first-class gate
The recovery flow gets the same verification as login. Attackers cannot escape into the softer channel because the softer channel is no longer softer.
Recovery architecture →We are not a rules-engine replacement
PasskeyBridge does not manage your fraud rules, run velocity checks, or model behavioural risk. It emits one specific class of signal—cryptographic proof-of-possession plus live carrier-state binding—that your existing rules engine consumes as a hard input. If your rules engine is the problem, we are not the fix. If your rules engine is doing the right thing but running on inputs that current attacker workflows quietly satisfy, this closes that specific gap.
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 hardware-bound passkey is phishing-resistant by construction, and the carrier-state check is bound to the request rather than the challenge. There is nothing for a relay-based attacker to intercept.
- 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 genuinely on a new device (a normal enrolment event, not a fraud event), carrier-state fails when the SIM or line has actually moved (SIM swap or port-out). Both scenarios have well-defined recovery paths—biometric re-enrollment, guardian-based recovery—so the signal does not translate to user friction outside the specific windows where it matters.
- 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 honestly?
- 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. No demo booking required.