Engineering · 2026-03-11

The Invisible SIM-Swap: Carrier-Signal Variance as a Detector

By J. W. Bouckaert

The alert that never fires

Most SIM-swap detection depends on the carrier. Vonage's SIM Swap API and Twilio Lookup's SIM swap data both answer a query: has the SIM behind this number changed, and when? The detection model is reactive: ask the carrier, or wait for a carrier event, then respond.

This model works when the carrier knows a swap happened and the relying party asks at the right moment. It fails when the carrier does not support the check, the number is not covered, the check is not run before the action, or the swap is not yet in the record.

Some swaps produce no carrier signal anyone acts on. The swap goes through social engineering of a carrier retail employee or through misuse of internal provisioning tools, and to the carrier it looks like a routine subscriber update. The attacker now controls the phone number, and a system that relies only on the carrier has no indication that anything changed.

This article calls that the invisible SIM-swap.

Carrier alerts and their ceiling

Carrier alerts are a critical first line of defense. PasskeyBridge's Pillar I ingests these signals and runs playbook responses when they arrive.

But relying only on carrier alerts creates a single point of failure. If the alert does not fire, the response pipeline does nothing.

Carrier alert systems report the events they record. An insider at a carrier retail location who processes a SIM swap through a legitimate provisioning interface creates an authorized transaction, and the carrier's fraud engine sees a routine subscriber update. The gap is in what can be observed.

Signals from the radio link

When a SIM moves to another device, the radio link between the subscriber and the network changes. Cellular connections have measurable characteristics:

• Round-trip time (RTT) jitter: the distribution of packet round-trip times, which depends on distance, conditions, antennas and the radio hardware in the device.
• Handover frequency: how often the device moves between cells. A device that has been stationary for months and suddenly hands over often has changed its relationship to the network.
• Signal strength variance: the spread of RSSI (Received Signal Strength Indicator) readings over a sampling window, which varies with antenna design, case geometry and radio firmware.
• Timing advance: the value the base station assigns to compensate for propagation delay, which shifts when the device is at a different distance from the cell.

These are continuous measurements. Most of them are visible only to the carrier and the device's baseband, and a web page cannot read any of them. They can also be manipulated: rogue base stations and modified firmware can change what is reported.

The NF-08 device check

PasskeyBridge's Spatially-Bound Identity Attestation (NF-08) works from the device's side. Its browser capture module reads what a browser exposes, hashes each channel with SHA-256 on the device within a capture window of at most 100 ms (80 ms by default), and sends only the digests.

The network jitter channel uses high-resolution timer deltas, the connection estimate from navigator.connection, and timing deltas from the last ten Resource Timing entries. These describe how the page's requests behave at the moment of capture. They do not read the cellular radio link, so they do not show directly that a SIM moved to another device.

What NF-08 compares is the device. At enrollment it stores a baseline of channel digests for the user. On each later verification, shield-spatial-bind compares the new capture with the latest active baseline:

device identifier digest differs from baseline        +0.8
EMI and thermal digests both identical to baseline    +0.5
network jitter digest identical to baseline           +0.4

score ≥ 0.45  → 403 anomaly_detected, failed audit entry
score < 0.45  → verified

A capture from a different device is flagged on the device digest alone. That is the case NF-08 covers for a SIM swap: the attacker uses the number from a device that never enrolled.

Jitter replay detection

An attacker might replay an earlier capture to look like the enrolled device. Sensor readings change between captures, so a channel digest that matches the baseline exactly suggests a replay.

Enrollment:  network_jitter_hash = "a3f7...c912"
Capture T2:  network_jitter_hash = "8b21...d4e7"  ← expected: different
Capture T3:  network_jitter_hash = "a3f7...c912"  ← matches the baseline: +0.4

A repeated jitter digest on its own adds 0.4, below the 0.45 threshold, so it passes. It is flagged when another reason is also present, such as repeated EMI and thermal digests or a different device digest. Each verification is scored on its own: scores do not accumulate across captures, and NF-08 results do not feed the agent trust engine. The comparison is with the latest baseline only, so a replay of some other earlier capture is not detected.

The capture channels

The Atomic Fingerprint is a SHA-256 digest over one digest per channel:

The composite is computed as:

fingerprint = SHA-256(
  network_jitter_hash : accelerometer_hash (or "no_accel") :
  emi_spectral_hash : thermal_variance_hash : device_identifier_hash
)

The server receives digests plus coarse metadata: the OS family, the capture duration in 10 ms steps, and a timestamp rounded to 100 ms. No raw sensor readings leave the device. This is the zero-PII architecture applied to device attestation.

Consequences for your threat model

If your identity security model depends only on carrier alerts, a swap that produces no carrier event goes unnoticed.

A device check gives a second, independent signal:

1. Defense in depth: carrier alerts (Pillar I) report swaps the carrier records. NF-08 flags a request from a device that did not enroll, whether or not the carrier reported anything.

1. Placement: a relying party can request a capture before a critical action, such as a high-value transaction or a credential change. NF-08 does not run continuously; it runs when the relying party asks.

1. Limits: NF-08 shows that the capture did not come from the enrolled device. It does not show that a SIM swap took place, and an attacker with the enrolled device passes it.

1. Signatures: a capture can carry the client's own ML-DSA signature, which the server stores with the binding. The server does not sign or verify it.

Designing for the invisible swap

Carrier alerts will miss some swaps. Carriers are large organizations with human employees and legacy systems, and attackers target the weakest step.

The question worth asking is what happens when your carrier check misses a swap.

PasskeyBridge's answer is to check the device as well as the number. If the request comes from a device that never enrolled, NF-08 flags it whether or not the carrier reported anything.

Read about NF-08 → | SIM Swap Detection Overview → | Read the Hardware Brief → | Start building →

Start free · Test the API