Security · 2026-03-01

SIM-Swap Detection on Its Own

By J. W. Bouckaert

The detection gap

Most identity platforms today can surface a SIM-swap event within seconds of it occurring. The signal arrives via a carrier API: Vonage Number Insight, Twilio Lookup, Sinch Number Lookup, or a signed webhook. The event is logged. An alert fires. A row appears in a SIEM dashboard.

Then nothing happens, fast enough.

The damaging gap sits between the alert and the orchestrated response that actually protects the account: revoked sessions, frozen credentials, suspended agent delegates, and a notified user. We went through the mechanics of that interval in After SIM-Swap Detection: The Response Window. The shorter that window, the lower the loss.

The FBI IC3 public service announcement on SIM swapping (February 2022) sets out the mechanics. Once the number moves to the attacker's SIM, calls and texts go to the attacker, who sends password-reset and account-recovery requests and receives the SMS one-time codes. IC3 received 1,611 SIM-swap complaints in 2021, with adjusted losses of more than $68 million. Every step after the swap is an account action the attacker can take before anyone responds.

Response is harder than detection

Detection is a read operation. You receive a webhook, parse the payload, and compare it against a known pattern. It is stateless and deterministic.

Response is an orchestration problem. You need to:

1. Authenticate the signal—verify HMAC signatures, validate payload structure against the carrier's schema, reject replays.
2. Resolve the affected user—map the carrier identifier (which is a phone number) to your internal user model without persisting the raw identifier in plaintext.
3. Run the response. In PasskeyBridge the playbook actions run in parallel. Internal actions update rows this platform holds. A webhook callback is how your backend acts on users in your own identity provider.
4. Record failures. A failed action is stored with its status. It is not retried inside the request.
5. Audit everything—append-only, tamper-evident, exportable for SOC 2 Type II evidence.

Every team that has ever built this rebuilds the same five layers. Every implementation hits the same race conditions, the same idempotency bugs, the same audit gaps. See Building an Identity Threat Playbook in Under 10 Minutes for the alternative.

The three-pillar solution

PasskeyBridge composes orchestration and response into one identity threat response stack. The architecture is covered end-to-end in Introducing PasskeyBridge.

• Pillar I (Signal Ingest & Response). A carrier signal or a signed webhook reaches playbook completion inside one request. A lookup asks one provider, and that call fails when the provider fails. One provider per lookup.
• Pillar II (Verifiable Credentials)—Once a threat is contained, re-verification happens through cryptographic proofs rather than passwords or SMS. OpenID4VP and OIDC4VC let users prove identity without exposing PII.
• Pillar III (Biometric Binding)—WebAuthn passkeys bind identity to a hardware authenticator. Porting a SIM does not give an attacker the user's passkey, because its private key stays with the user's authenticator or passkey provider.

Parametric revocation

When a SIM-swap signal matches a playbook, the actions you configured run in parallel, each bounded by an eight-second timeout:

1. Suspend account deactivates this tenant's agent delegates and sets their trust score to zero.
2. Revoke tokens tears down this tenant's open BLAST tunnels.
3. Revoke sessions ends this tenant's active agent-to-agent negotiations.
4. Freeze credentials invalidates cached proofs stored here.
5. A webhook callback, when a URL is set, is the call your backend uses to act on users in your own identity provider.
6. The event and the action results are written to the append-only audit trail.

Passkeys registered with your application, and passkeys on the hosted relying party, stay registered. Social recovery does not start from this signal. A CAEP receiver you have configured is a separate stream. It is not fired as a side effect of the playbook list above.

In identity threat response as a service, detection feeds an automated response.

Further reading

• FBI IC3 Public Service Announcement: SIM Swapping—Plain-language reference on attack mechanics and consumer impact.
• CISA Implementing Phishing-Resistant MFA—Why SMS-tied MFA is no longer treated as a baseline control.
• SIM Swap Detection Latency: Carrier and Platform Gaps—Which part of the gap between a swap and its detection carriers control, and which part platforms control.
• Account Takeover Prevention—How the same signal chain closes the credential-replay and SIM-swap-recovery gaps in one deployment.
• Insurance Underwriting Meets Identity Assurance—How carriers are now pricing the same controls discussed here.

Start free · Test the API