Security · 2026-04-01

Carrier Signal Chaining: Correlating Multi-IMSI Events Across Roaming Boundaries

By J. W. Bouckaert

Roaming and the IMSI

When a subscriber crosses a national border, the device registers on a visited Mobile Network Operator (MNO). The International Mobile Subscriber Identity (IMSI) stored on the SIM, up to 15 digits starting with the home network's country and network codes, identifies the subscriber to the visited network. The visited network registers the subscriber and the home network's subscriber register records where the subscriber is, under the location management procedures in 3GPP TS 23.012 and their LTE and 5G equivalents. A roaming agreement between the two operators governs the commercial and technical terms.

Roaming on its own does not change the IMSI. The subscriber keeps the home IMSI and the home operator keeps the subscriber record.

Most carrier-signal checks, including Twilio Lookup and Vonage Number Insight, are point-in-time queries made at authentication. They return a snapshot: SIM change data, carrier name, line type and, from some providers, roaming status. None of these APIs returns the IMSI.

Carrier signal chaining is the idea of keeping those snapshots over time so that a sequence of events can be judged along with the latest one.

Events that change the IMSI

The IMSI presented to the network changes in a few legitimate cases:

SIM replacement: the subscriber gets a new SIM from their carrier, which usually carries a new IMSI for the same number
eSIM profile switch: the subscriber activates a different operator profile on an eSIM-capable device, which changes the active IMSI
Number port: the number moves to another operator, which serves it with one of its own IMSIs
Multi-IMSI SIMs: some SIMs, common in enterprise and IoT connectivity, carry several IMSIs and switch between them to use different partner networks

In 5G, the SIM's permanent identifier is the SUPI, usually an IMSI. The device sends it over the air only in concealed form, as a SUCI, under 3GPP TS 33.501, and the network assigns temporary identifiers. Concealment protects the IMSI from eavesdroppers; it does not give the subscriber a new IMSI.

Attacks show up differently:

SIM swap fraud: an attacker gets the carrier to move the number to a SIM they hold, so the number stays the same and the SIM changes
Fraudulent port-out: an attacker moves the number to another operator
SIM cloning: a duplicate SIM presents the same IMSI from a different device; modern SIM authentication makes this hard, and only the operator can see two registrations for one IMSI
IMSI catching: a rogue base station (IMSI catcher) collects the IMSIs of nearby phones for tracking and, on older networks, can intercept traffic

A verifier outside the operator sees these events through what carrier APIs expose: a SIM change date or flag, porting status, carrier name and network codes, and in some APIs roaming status. Separating a legitimate SIM replacement from SIM swap fraud takes context the verifier holds, such as whether the user requested the change.

A temporal chain model

A chain records each carrier signal for a subscriber with its time and source, keyed so that no raw identifier is stored:

Signal 1 (lookup, provider A) -> HMAC(pepper, phone) + time 1 + carrier, SIM change data
Signal 2 (lookup, provider A) -> HMAC(pepper, phone) + time 2 + carrier, SIM change data
Signal 3 (tenant event)       -> HMAC(pepper, phone) + time 3 + event type
                                         |
                                         v
                              Sequence evaluation
                              - time between events
                              - carrier and network code changes
                              - SIM change dates against earlier answers
                              - roaming status, where reported

The key is the phone number's keyed digest, because the phone number is what carrier APIs are queried with. A chain can then answer questions a single snapshot cannot:

Question	One snapshot	A chain
Did the SIM change since the last check?	Only within the provider's swap period	Compare the SIM change date with the previous answer
Did the carrier change?	Shows the current carrier	Shows the change and when it was first seen
Is a recent SIM change expected?	No context	Can be matched against the user's own request or travel
Is a roaming change plausible?	Shows current roaming status, where reported	Shows the sequence of countries reported over time

The thresholds for these questions depend on the tenant's users. A travel-heavy user base sees more roaming changes. A user base that changes phones often sees more SIM changes.

The eSIM case

An eSIM profile switch and a physical SIM replacement look the same in carrier SIM change data. Both report a new SIM for the number. What separates a user's own eSIM change from an attacker's swap is context outside the network: the user's device and credentials.

A WebAuthn passkey gives a relying party that context. A passkey created on the user's device before the SIM change, and still used with user verification after it, is evidence that the same person holds the device. A SIM change followed by a login from a new device with no existing passkey is the pattern a SIM swap leaves. PasskeyBridge's three-pillar architecture combines carrier signals with passkeys and Verifiable Credentials for this reason.

PasskeyBridge today

PasskeyBridge does not build signal chains or compute a chain score. What it does with carrier signals today:

Lookups: a carrier lookup asks one provider per request and returns that provider's answer.
Ingest: a tenant posts signals from its own sources. The ingest payload has no IMSI field; a phone number in the payload is keyed with HMAC-SHA-256 under a server-held pepper before storage, and the raw number is not stored. Each event is matched to the tenant's identity threat playbooks by its event type.
Hard signals: an ingested sim_swap, port_out or similar hard signal deactivates the tenant's agent delegates, revokes its agent-to-agent negotiations and freezes the subject's shadow identities.

A tenant that wants chain-style checks today can keep its own history of lookup answers and post events such as a carrier change or an unexpected SIM change to ingest, where its playbooks respond.

Zero-PII storage

A chain built this way holds no raw identifiers:

Keyed HMAC-SHA-256 digests of the phone number under a server-held pepper
Timestamps of each signal
Carrier and network codes reported by the provider
SIM change dates and flags as the provider returned them

Without the pepper, which is held outside the database, the digests cannot be enumerated back to phone numbers. That supports GDPR Article 32 (security of processing) and the approach in Reg S-ID compliance without storing phone numbers. The IMSI never enters the chain, because no carrier API in the path returns it.

Explore the platform · Get started free

Start free · Test the API