Security · 2026-03-24

The 200-Millisecond Blind Spot Between SIM Swap and Detection

By J. W. Bouckaert

The window no one measures

Every SIM swap attack exploits the same structural flaw, and the flaw is in time. Cryptography and authentication logic hold up.

Between the instant a carrier executes a port-out and the instant an identity platform receives the corresponding API signal, there is a gap. In the industry, this gap is rarely discussed, almost never measured, and universally underestimated. Publicly documented carrier webhook SLAs, GSMA fraud intelligence reports, and the published latency envelopes of the major carrier signal APIs converge on a similar pattern: median end-to-end propagation from port-out execution to webhook receipt is measured in hundreds of milliseconds, and tail latencies on legacy signaling paths can stretch into seconds.

Two hundred milliseconds is a long time in this flow. In 200 milliseconds, an adversary who has successfully executed a SIM swap can initiate a password reset, intercept an SMS OTP, and authorize a fraudulent wire transfer. The attack completes before the identity platform knows it has begun.

This article examines the technical anatomy of that gap—where the latency originates, why existing detection architectures cannot close it, and how PasskeyBridge's event-driven ingest pipeline collapses the platform's own share of it into the request that carried the signal.

Anatomy of carrier signal propagation

To understand the blind spot, you must understand the path a port-out signal travels before it reaches your identity stack.

The carrier-side pipeline

When a subscriber initiates a number port, the losing carrier's provisioning system executes a sequence of operations that are invisible to downstream consumers:

1. NPAC Update—The Number Portability Administration Center receives the port request. The Local Routing Number (LRN) is reassigned in the central database. This operation is governed by FCC Local Number Portability rules and typically completes within minutes, though the regulatory window permits up to four business days for wireline ports.
2. Internal Provisioning—The losing carrier updates its HLR/HSS (Home Location Register / Home Subscriber Server). The subscriber's IMSI is disassociated from the MSISDN. Network-level routing tables are updated. This is where the phone number functionally "changes hands."
3. Event Bus Publication—The carrier publishes a port-out event to its internal event bus. For carriers with modern architectures (T-Mobile, some MVNOs), this is a Kafka topic. For legacy carriers, it is a batch file or a database trigger.
4. API Gateway Propagation—The carrier's API gateway picks up the event and dispatches it to registered webhook endpoints. This is the step where external platforms—including PasskeyBridge—first learn about the swap.

The latency accumulates at every step. Step 1 is regulatory overhead. Step 2 is network infrastructure. Step 3 depends on internal event bus architecture. Step 4 depends on webhook dispatch queuing, retry logic, and TLS handshake overhead.

Representative propagation delays

PasskeyBridge ingests carrier signals from multiple providers. The table below summarizes the representative latency envelopes for each integration class, derived from the published documentation and SLA references of the underlying carrier APIs rather than from any single proprietary benchmark. Actual numbers vary by region, carrier, time of day, and webhook destination.

The variance is instructive. Modern REST-based carrier APIs introduce hundreds of milliseconds at the median because they buffer events for batching, apply rate limiting, and route through multi-region API gateways. Legacy APIs are worse: SOAP envelope parsing, XML schema validation, and synchronous database queries add hundreds more. Direct SS7 signaling is faster because it bypasses the application layer entirely, but SS7 access is restricted to licensed carriers and raises its own security concerns.

The critical insight is that the delay lives in the carrier's stack, upstream of yours. You cannot optimize it. You can only minimize the time you add on top of it.

Failures of existing architectures

Most identity platforms compound the carrier delay with their own processing overhead. The typical SIM-swap detection pipeline looks like this:

Carrier webhook → API gateway → Message queue → Worker process
→ Database write → Rules engine → Action dispatch → Response

Each hop adds latency. The API gateway terminates TLS and validates headers (5–15ms). The message queue serializes and persists the event (10–30ms). The worker process deserializes, enriches, and normalizes the payload (15–40ms). The database write is a synchronous INSERT with WAL fsync (5–20ms). The rules engine evaluates conditions against historical data (10–50ms). The action dispatch fires webhooks, revokes sessions, and sends notifications—sequentially (50–200ms each).

Total platform-side overhead: 95–355ms. Added to the carrier's 120–380ms, the end-to-end delay from port-out execution to identity response is 215–735ms.

Seven hundred milliseconds. In that time, the adversary has already won.

Sequential processing

The fundamental mistake is sequential processing. Each step in the traditional pipeline waits for the previous step to complete before beginning. This is a design choice inherited from request-response web architectures—adequate for rendering a page, inadequate for stopping a fraud.

Consider what happens at the 200ms mark after a SIM swap:

• 0ms: Carrier executes port-out
• 120ms: Carrier API dispatches webhook
• 135ms: Identity platform receives webhook, begins processing
• 200ms: Identity platform is still parsing and enriching the signal
• 200ms: Adversary initiates password reset on target account using intercepted SMS OTP

The identity platform is still in its enrichment phase when the adversary completes the attack. Detection without timely response is logging. As we have written before: detection without response is just logging.

Collapsing the window: PasskeyBridge's architecture

PasskeyBridge's ingest architecture is designed around a single constraint: add as little platform-side latency as possible to a carrier signal, and measure what it does add on every request. That constraint is a security requirement. If the platform cannot respond before the adversary acts, the platform has failed.

Parallel fan-out

The PasskeyBridge ingest pipeline replaces sequential processing with parallel fan-out. When a carrier signal arrives:

1. HMAC-SHA-256 authentication verifies the payload signature against the carrier's shared secret. This is a single cryptographic operation—no database query, no token lookup. Cost: < 1ms.
2. Zero-PII normalization keyed-hashes any raw low-entropy identifiers (phone numbers) with HMAC-SHA-256 under a server-held pepper before they touch memory beyond the request handler. The raw value is never logged, cached, or persisted.
3. Signal classification maps the carrier-specific event type to one of PasskeyBridge's canonical signal types using the deterministic cascade classifier. This is a static lookup—no ML model, no probability threshold, no ambiguity.
4. Parallel dispatch fires all downstream actions simultaneously via Promise.all: carrier cross-reference, playbook execution, cascade revocation, webhook delivery, and audit logging. No action waits for another action to complete. Total latency equals the slowest action.

The architectural target: platform-side processing complete inside the request that carried the signal. Combined with the carrier's signal propagation delay, the dominant cost on the wire is the carrier hop itself. The blind spot the platform can control is collapsed; the residual gap is whatever the carrier cannot yet shave off its own pipeline.

The cascade difference

When the signal is classified as a hard threat (SIM swap, port-out, account takeover), PasskeyBridge does not wait for a rules engine to decide what to do. The PBCASCADE protocol fires four subsystem revocations in parallel:

• Agent delegate revocation: All AI agent delegates issued by the affected user are immediately deactivated, their trust scores zeroed, and their scopes emptied.
• A2A negotiation invalidation: All active agent-to-agent trust negotiations involving the user are revoked.
• Shadow identity freeze: All shadow proxy identities are frozen.
• BLAST tunnel teardown: All active encrypted tunnels are torn down.

Four subsystems. One parallel dispatch. The cost on the critical path is the slowest of the four.

Physical limits

The 200ms blind spot is a consequence of physical infrastructure, and no software patch removes it. Carrier signals traverse fiber optic cables, cross network boundaries, pass through load balancers, and queue behind other events. The speed of light in fiber is approximately 200,000 km/s. A signal traveling from a carrier's data center in Dallas to a cloud region in Virginia covers 1,900 km—a minimum of 9.5ms for the photon alone, before any application-layer processing.

This is why PasskeyBridge treats identity as a physics problem, not a math problem. You cannot make the carrier's signal arrive faster. But you can ensure that when it does arrive, your platform responds before the adversary's next API call completes. The margin is measured in milliseconds, and every millisecond is a design decision.

Post-quantum implications

The latency constraint becomes more critical in a post-quantum context. Hybrid PQC signatures (NIST FIPS 204 ML-DSA-65) add computational overhead to every cryptographic operation. PasskeyBridge pre-computes PQC signatures for cached proofs, ensuring that the latency penalty of quantum resistance does not consume the response budget. The blind spot does not widen because the platform adopted post-quantum cryptography—it stays where the measurements put it.

Detection time versus response time

The SIM-swap detection market is dominated by platforms that measure detection time—the interval between a port-out event and the platform's internal acknowledgment of that event. This metric is misleading. Detection time does not include response time. A platform that detects a SIM swap in 100ms but takes 400ms to revoke sessions and freeze credentials has a 500ms end-to-end latency. The adversary does not care when the platform detected the attack. The adversary cares when the platform acted on it.

PasskeyBridge measures time-to-response as the headline number. This is the interval between signal receipt and the completion of all protective actions—session revocation, credential freezing, agent suspension, webhook delivery, and audit logging. The metric that matters is when you acted.

The compliance dimension

SEC Regulation S-ID requires covered financial institutions to implement "reasonable policies and procedures" for identity theft detection and response. NIST SP 800-63B Section 5.1 specifies that authenticators "shall" be revoked when compromise is detected. Neither regulation specifies a latency requirement—but both imply that response should be timely. A 700ms response window that permits an adversary to complete a fraudulent transaction is unlikely to satisfy a regulator's definition of "reasonable."

PasskeyBridge's architecture provides compliance-ready audit evidence with per-action latency metrics, zero-PII storage, and cryptographic proof of cascade execution—all inside the same response budget. The platform does not just detect and respond. It proves, to SOC 2 standards, that it did so within the required timeframe.

Closing the gap

The 200ms blind spot is a structural feature of carrier infrastructure. It will not be eliminated by better APIs or faster networks. It will be compressed—incrementally—as carriers modernize their event pipelines. But the platform-side overhead is entirely within your control.

SIM swaps will occur; the useful question is whether your identity stack will respond before the adversary's next API call completes. If your platform adds 200ms of processing latency on top of the carrier's signal delay, the answer is no. If your platform adds tens of milliseconds, the answer changes.

The FBI's IC3 annual report continues to document SIM-swap–enabled fraud as a multi-hundred-million-dollar annual loss category in the United States alone. The losses are driven by swaps that were detected too late for the response to matter rather than by undetected swaps. Every millisecond of platform latency you add is a millisecond the adversary keeps.

The blind spot is a measured, quantified, and exploitable vulnerability in every identity stack that processes signals sequentially. PasskeyBridge eliminates it—not by making carriers faster, but by ensuring that the platform's response is already complete before the adversary can act.

Explore the architecture →

Start free · Test the API