SIM swap and port-out detection in the auth path, not a nightly batch.
Most SIM-swap feeds are 24-hour batch data. By the time the record lands, the attacker has already run the recovery flow. PasskeyBridge queries carrier state live inside the auth request and returns a signed answer before money moves.
- Live SIM tenure and port-out state, checked at request time.
- Silent Number Recycling caught, not missed like most vendor feeds.
- Edge latency published live at /developers/playground.
- Multi-carrier via GSMA Open Gateway through carrier-grade providers (Vonage, Twilio).
Why batch SIM-swap feeds miss the window
The SIM-swap fraud window is measured in hours, not days. Attackers execute the swap, run the recovery flow, drain the account, and drop the line—often inside a single overnight window. Batch data feeds that update once a day publish the swap event long after the fraud is complete.
The narrower problem is real-time visibility: at this exact request, what is the carrier state of the line tied to this account? PasskeyBridge answers that question inline with the auth or recovery request, so the decision to allow or challenge happens before the sensitive action, not after.
What live carrier state actually covers
SIM-swap detection alone is now a given. The failure modes a modern signal has to cover are broader: port-out to a different carrier, silent number recycling where a carrier reassigns a released number to a new subscriber without a swap event, dual-SIM and eSIM re-provisioning, and IMSI variance across cell registrations.
PasskeyBridge covers all of the above through GSMA Open Gateway multi-provider ingestion via carrier-grade providers (Vonage as the primary path, with Twilio and other providers supported via bring-your-own-key), with a TTL-aware model so a fresh signal is fresh (not a cached value from last Tuesday).
- SIM tenure: how long the current SIM has held the line.
- Port-out: cross-carrier movement inside a configurable recovery window.
- Silent Number Recycling: numbers reassigned to new subscribers without a swap event.
- Device change: paired via the passkey binding, not carrier data alone.
Where the signal plugs in
The most common deployment is a hardening pass on recovery and high-value action flows: any request that hits password reset, MFA reset, phone-number change, or a money-movement threshold gets a live carrier-state check inside the auth call. A fresh SIM tenure or a recent port-out hard-fails the request or steps up to biometric re-enrollment or M-of-N guardian recovery.
Login flows can consume the same signal as a rules-engine input, but the largest measured lift is inside recovery—where the current control gap is widest and the fraud outcome is highest-severity.
The PasskeyBridge approach
Live, not cached
Every check queries live carrier state on the account's line. No nightly delta feed, no risk of publishing a swap event hours after the money moved.
Latency probe →Silent Number Recycling covered
Most vendors miss the SNR case entirely because it is not a swap event. Our multi-provider ingestion catches it as a tenure discontinuity.
Carrier signal thesis →Zero PII stored
Phone numbers are hashed with keyed HMAC-SHA-256 under a server-held pepper before they touch storage—non-enumerable, unlike a plain SHA-256 of a phone number. You get the signal without inheriting phone-number custody.
Privacy architecture →We are not a KYC provider
PasskeyBridge does not verify identity documents, run sanctions or PEP checks, or issue an IDV pass/fail. It emits one class of signal: live carrier-state binding on a phone line already associated with an account. If you are shopping for an onboarding IDV vendor, this is not that. If you are shopping for the specific signal that catches SIM-swap-driven ATO and recovery fraud in the moment it matters, this is what that looks like.
Frequently asked
- How is this different from a Twilio Lookup or a carrier-data feed?
- Lookup and batch carrier feeds return a snapshot: what the carrier data was at the time it was published. That is fine for signup verification and useless for real-time fraud gates. PasskeyBridge queries live carrier state inside the auth request and returns a signed answer without caching the value between requests. Our decision path is the part we measure and publish; the carrier network's response time is theirs, and we bound it with a timeout rather than promising it.
- Does it work outside the US?
- Yes. Multi-provider coverage via GSMA Open Gateway carrier-grade partners (Vonage, Twilio, and bring-your-own-key providers) spans the major US, EU, UK, and APAC carriers. Coverage details for a specific market are shared under a mutual NDA before deployment.
- How do we handle legitimate SIM changes?
- Carrier tenure is a scored signal, not an automatic block. A legitimate fresh SIM (new device activation, plan migration, lost phone recovery) triggers a step-up to biometric re-enrollment or M-of-N guardian recovery for a defined window, then normalises. Attackers exploiting the same window get a hard fail.
- What is the audit story for a decision that used this signal?
- Every verification returns a signed attestation with the carrier-state values it consumed, the policy it applied, and a hybrid classical plus ML-DSA-65 signature. Store the attestation as evidence and re-verify it independently later.
- Can we ingest this signal into our existing fraud engine?
- Yes. The signed attestation is a single JSON payload with well-defined fields. Sift, Forter, Sardine, Alloy, and in-house rules engines can all consume it as a high-weight rule input without a full SDK integration.
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production. No demo booking required.