SIM swap and port-out detection in the auth path.
When your service calls PasskeyBridge, it looks up the line with the carrier data provider you configure and returns whether a SIM swap was reported and how many hours ago, and whether the number was ported. Which of these a provider reports depends on the provider.
- Live SIM tenure and port-out state, checked at request time.
- 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 can be a few hours. 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.
What live carrier state actually covers
A carrier lookup reports what that provider returns: SIM swap and its age, porting, and, depending on the provider, line type, reachability, or roaming. It does not report silent number recycling, dual-SIM or eSIM re-provisioning, or IMSI variance.
PasskeyBridge calls the provider you configure (Vonage on the primary path, Twilio Lookup, or Sinch with your own key) when your service makes the request. A recycled number reaches the platform as a number_recycle signal a tenant posts. The lookup is not served from a stored carrier snapshot.
- SIM tenure: how long the current SIM has held the line.
- Port-out: cross-carrier movement inside a configurable recovery window.
- Number recycle: a tenant-posted number_recycle signal, scored as a soft signal. The carrier lookup does not detect recycling on its own.
- Device change: paired via the passkey binding as well as carrier data.
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 at request time
Every check is a new provider lookup on the account's line at the time of the request. Nothing is cached between requests.
Latency probe →Recycled numbers as a tenant signal
A recycled number reaches the platform as a number_recycle signal that a tenant posts, and the cascade classifier scores it as a soft signal.
Carrier signal thesis →Zero PII stored
Phone numbers are hashed with keyed HMAC-SHA-256 under a server-held pepper before they touch storage, so the stored value cannot be reversed by enumerating phone numbers without the pepper. The phone number itself is never stored.
Privacy architecture →How PasskeyBridge fits with KYC
PasskeyBridge emits one class of signal: live carrier-state binding on a phone line already associated with an account. Document verification, sanctions and PEP checks, and IDV pass/fail stay with your KYC vendor.
Frequently asked
- How is this different from a Twilio Lookup or a carrier-data feed?
- PasskeyBridge calls a carrier data provider (Vonage Identity Insights, Vonage Number Insight, Sinch Number Lookup or Twilio Lookup v2) when your service makes the request, and normalizes the answer into one carrier signal. It caches nothing between requests. Each provider call has a 15-second timeout; the provider sets its own response time.
- 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. 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.
- 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.