Security · 2026-03-04
After SIM-Swap Detection: The Response Window
By J. W. Bouckaert
The window after the alert
Your carrier API fires. The SIM-swap signal lands. Your monitoring dashboard turns red.
An alert on its own changes nothing on the account. Something still has to revoke access and tell your own systems to act.
The damaging interval is the gap between the alert firing and a response landing on the account. Once a SIM-swap gives the attacker control of the recovery channel, password resets and OTP intercepts can complete in seconds. The FBI IC3 public service announcement on SIM-swapping describes that path: the attacker requests password resets and receives the SMS codes on the swapped number. A response that waits for a person to read the alert leaves the attacker that time.
Detection
The carrier signal landscape in 2026 is mature. Vonage and Twilio both sell SIM-swap lookups, and the CAMARA SIM Swap API defines a common contract that operators expose.
The problem is what happens next. SIM-Swap Detection on Its Own covers why a detected swap needs an automated response. This post walks through that response.
The response, step by step
When a SIM-swap signal arrives at your PasskeyBridge ingest endpoint, the following happens—in order, inside the request:
- API-key authentication—the request is authenticated and held to the tenant's rate limit
- HMAC-SHA256 verification—required for a signal from a registered source or when the tenant requires signed ingest, and checked whenever the signature header is present
- PII scrubbing—phone numbers are keyed-hashed with HMAC-SHA-256 under a server-held pepper (non-enumerable, unlike a plain SHA-256 of a phone number); the raw payload never touches disk (see our zero-PII architecture)
- Playbook matching—the playbook whose signal type equals the event type string you sent is selected
- Hard-signal revocation—for a hard signal such as a SIM swap on a live key, the tenant's agent delegates and agent-to-agent negotiations are deactivated, with the affected subject's shadow identities, before any playbook action runs
- Action execution—the playbook's actions run in parallel, each bounded by an eight-second timeout: tenant-side revocations, a webhook callback to your backend, Slack or email alerts
- Audit logging—the event and the action results are appended to the audit trail
Parametric revocation: The kill chain
Two things change state on a SIM-swap signal. The hard-signal step deactivates every active agent delegate in the tenant, revokes its agent-to-agent negotiations and freezes the shadow identities issued for the affected subject. The playbook then runs the actions you configured: suspending delegates, tearing down BLAST tunnels, invalidating cached proofs, or calling your backend with a webhook so it can act on the user in your own identity provider.
Passkeys stay registered, and social recovery does not start from the signal. The full action list is in SIM-Swap Detection on Its Own.
The business case
For fintech CTOs navigating SEC Reg S-ID compliance, the rule requires a program that responds appropriately to detected Red Flags. An automated response with an audit record is evidence for that element, and it supports SOC 2 readiness on processing integrity.
Try it yourself
Build your first playbook in under 10 minutes and see the response window in action. Or read the full platform overview.