Security · 2026-03-24

SIM Swap Detection Latency: Carrier and Platform Gaps

By J. W. Bouckaert

The window between the swap and the signal

A SIM swap moves a phone number to a SIM the attacker controls. A port-out moves the number to another carrier. Either way, from that moment the attacker receives the victim's calls and text messages, including one-time codes.

Between the moment the carrier makes that change and the moment a relying party learns about it, there is a gap. During the gap, an SMS code sent to the number goes to the attacker. How long the gap lasts depends far more on how the relying party gets carrier signals than on any processing speed.

This article looks at where that gap comes from, which parts of it a platform controls, and how PasskeyBridge's event-driven ingest pipeline handles a signal once it arrives.

Sources of the gap

On the carrier side

When a number moves, the carrier updates its subscriber records so the number is tied to the new SIM. For a port-out, the Number Portability Administration Center records the new routing, under FCC local number portability rules that require simple ports to complete within one business day. None of this is visible to a bank or an identity platform when it happens.

In November 2023 the FCC adopted rules requiring wireless carriers to use secure methods to authenticate a customer before a SIM change or port-out, and to notify the customer when one is requested. Those rules make swaps harder to carry out. They do not tell a relying party that a swap has happened.

Carrier signal APIs

A relying party learns about a swap through a carrier signal API, offered directly by carriers or through providers such as Vonage, Sinch and Twilio. The industry's CAMARA project defines two forms:

• A SIM Swap API that answers, when asked, whether the SIM for a number changed within a given period, or when it last changed.
• A SIM Swap Subscriptions API that notifies a subscriber when a swap happens.

With the query form, the gap lasts until the relying party next asks. A bank that checks only at login learns about a swap at the next login, which may come after the attacker has already used an SMS code. With notifications, the gap is the carrier's own delivery time, which the relying party does not control and which varies by carrier and provider.

On the platform side

What the platform controls is everything after the signal arrives. A pipeline that puts each signal on a queue, waits for a worker, writes to a database, evaluates rules and then dispatches actions one after another adds its own delay to the carrier's. Every step a protective action waits for is time in which the attacker's session stays open.

PasskeyBridge's signal handling

PasskeyBridge's carrier lookup endpoint queries a configured provider and forwards what it finds to the ingest endpoint, and carriers or providers that push events can send them to the ingest endpoint directly. From there, the ingest request runs these steps in order:

1. Validate. The body is checked against a Zod schema before any database call.
2. Load context. One database round trip returns the organization, the API key, the matching active playbook and the rate-limit counter.
3. Authenticate. The API key must carry the ingest scope. An x-pb-signature HMAC-SHA-256 header is verified when present, and required when the organization has turned on signed ingest.
4. Decide. A raw phone number is keyed with HMAC-SHA-256 under a server-held pepper (zero-PII normalization), the decision is made, and the time taken so far is recorded as decision_ms.
5. Hard-signal response. For a hard signal such as a SIM swap, the tenant's agent delegates are deactivated, open A2A negotiations revoked and the subject's shadow identities frozen, all inline.
6. Playbook actions. Every action in the matched playbook runs in parallel, each raced against an 8-second timeout.
7. Persist and respond. The event is written to shield_events, then the audit row, and the response returns with latency_ms for the whole request.

Because the playbook's actions run in parallel, a slow webhook does not hold up the revocations running beside it, and the caller's wait is set by the slowest action.

The hard-signal response

A hard signal does not wait for a rules engine. Inside the ingest request, PasskeyBridge deactivates the tenant's AI agent delegates, setting their trust scores to zero, and revokes the tenant's open agent-to-agent trust negotiations. The shadow identities tied to the affected phone hash are frozen. Tearing down encrypted tunnels or ending other sessions is left to the actions the tenant puts in its playbook.

Detection time and response time

A platform that reports only when it registered a swap leaves out what matters to the victim: when protective actions finished. PasskeyBridge records decision_ms on every event for its own work up to the decision, and returns latency_ms for the whole request, playbook actions included, so a tenant can see both.

The compliance side

SEC Regulation S-ID requires covered financial institutions and creditors to have a written identity theft prevention program with reasonable policies and procedures to identify, detect and respond to red flags. NIST SP 800-63B, a federal guideline rather than a regulation, says verifiers should consider risk indicators such as device swap, SIM change and number porting before using the phone network to deliver an out-of-band authentication secret. Neither sets a time limit. A SIM-swap check before an SMS code is sent, and an automatic response when a swap is reported, are the practices both point toward.

PasskeyBridge keeps audit records of each response with the actions taken and their timing, without storing plaintext phone numbers (zero-PII storage). That record supports SOC 2 readiness evidence.

Closing the gap

The carrier's share of the gap shrinks as carriers offer swap notifications and relying parties subscribe to them instead of checking only at login. The platform's share is the time from signal arrival to completed response, and that part is an engineering choice.

The FBI's IC3 2025 report counts 971 SIM-swap complaints with reported losses of $17,366,758, down from 982 complaints and $25,983,946 in 2024. Those figures cover only crimes reported to IC3.

Start free · Test the API