Security · 2026-04-01

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

By J. W. Bouckaert

The roaming problem nobody talks about

When a subscriber crosses a national border, their device detaches from the home Mobile Network Operator (MNO) and attaches to a visited network. The International Mobile Subscriber Identity (IMSI)—the 15-digit value burned into the SIM that uniquely identifies the subscriber—is presented to the visited network's Visitor Location Register (VLR) during the attach procedure defined in 3GPP TS 23.012. The home network's Home Subscriber Server (HSS) is notified. A roaming agreement between the two operators governs the commercial and technical terms.

This is a well-understood protocol. What is not well-understood is what happens to identity verification systems that depend on carrier signals when this roaming event occurs.

Most carrier-signal identity platforms—including standalone deployments of Twilio Lookup and Vonage Number Insight—query a single MNO's API at the moment of authentication. They receive a point-in-time snapshot: SIM-swap timestamp, carrier name, line type. If the subscriber has roamed, that snapshot reflects the home MNO's view of the subscriber—which may be minutes or hours stale, depending on the signaling delay between the visited network and the home HSS.

The gap between the home MNO's view and the visited MNO's view is where SIM-cloning attacks hide.

IMSI-switch events

An IMSI-switch event occurs when the IMSI presented to the network changes. In legitimate scenarios, this happens during:

• International roaming: The device attaches to a visited network, and depending on the SIM provisioning model, a new temporary IMSI (via the SUPI/SUCI mechanism in 5G networks per 3GPP TS 33.501) may be allocated
• SIM replacement: The subscriber obtains a new SIM from their carrier, which carries a new IMSI
• eSIM profile switch: The subscriber activates a different operator profile on an eSIM-capable device, changing the active IMSI entirely
• Multi-IMSI SIM: Enterprise SIMs from providers like BICS or 1GLOBAL (which acquired Truphone in 2024) that carry multiple IMSI values and switch between them based on network availability

In attack scenarios, IMSI-switch events look different:

• SIM cloning: A duplicated SIM presents the same IMSI from a different device, often in a different geographic location
• SIM swap fraud: A fraudulently ported SIM carries a new IMSI but retains the MSISDN, creating a detectable discontinuity
• IMSI catching: A rogue base station (IMSI catcher) intercepts the IMSI during the attach procedure and uses it to impersonate the subscriber

The challenge is distinguishing legitimate IMSI-switch events from malicious ones—especially across roaming boundaries where the identity platform has no direct relationship with the visited MNO.

The temporal chain model

PasskeyBridge addresses this challenge through carrier signal chaining—a method that correlates discrete carrier signals from multiple MNOs into a temporal chain of events, without storing the IMSI itself.

The architecture works as follows:

Signal₁ (Home MNO) ──→ SHA-256(IMSI₁ ∥ salt) ──→ Hash₁ + timestamp₁ + carrier₁
                                                         │
Signal₂ (Visited MNO) ──→ SHA-256(IMSI₂ ∥ salt) ──→ Hash₂ + timestamp₂ + carrier₂
                                                         │
Signal₃ (Home MNO) ──→ SHA-256(IMSI₁ ∥ salt) ──→ Hash₃ + timestamp₃ + carrier₃
                                                         │
                           ┌─────────────────────────────┘
                           ▼
                  Temporal Chain Analysis
                  ├── Δt between events
                  ├── Carrier sequence plausibility
                  ├── Geographic velocity check
                  └── IMSI-hash continuity score

Each carrier signal is ingested through PasskeyBridge's multi-provider normalization layer. The raw IMSI—if present in the carrier's signal payload—is immediately keyed-hashed using HMAC-SHA-256 under a server-held pepper, consistent with our zero-PII architecture. The keyed digest, not the IMSI, is what persists.

The temporal chain is constructed by correlating these hashes across time. When a subscriber roams, the chain records a transition from Hash₁ (home MNO) to Hash₂ (visited MNO) and, upon return, back to Hash₁ or a new Hash₃ if the SIM was replaced.

Distinguishing travel from attack

The temporal chain model applies four scoring dimensions to each IMSI-switch sequence:

Each dimension produces a normalized score between 0.0 and 1.0. The composite signal chain score is computed as a weighted product:

chain_score = (w₁ × temporal_score) × (w₂ × sequence_score) × (w₃ × velocity_score) × (w₄ × continuity_score)

Default weights are calibrated against GSMA fraud data: w₁ = 0.30, w₂ = 0.25, w₃ = 0.25, w₄ = 0.20. Tenants can override these weights via the PasskeyBridge dashboard based on their threat model.

A chain score below 0.4 triggers the configured identity threat playbook—which may include session revocation, credential freezing, and agent delegate suspension.

Obtaining cross-MNO signals

A natural question: if the subscriber is on a visited network, how does PasskeyBridge receive signals from that network?

Three mechanisms:

1. GSMA Open Gateway / CAMARA APIs. The GSMA's CAMARA project—with over 86 operator groups representing 300+ networks—standardizes carrier APIs including SIM swap detection, number verification, and device location. PasskeyBridge consumes these APIs through its multi-provider ingest layer. When a subscriber roams to a network that exposes CAMARA-compliant APIs, PasskeyBridge can query both the home and visited MNO independently.

2. SS7/Diameter signaling correlation. When a home MNO receives a MAP Update Location message from the visited network via SS7 signaling, the home HSS records the visited network's identity (the Global Title of the visited MSC/VLR). This metadata—which network the subscriber attached to, and when—is available through carrier API enrichment without exposing the IMSI itself. PasskeyBridge normalizes this into the temporal chain.

3. Roaming hub telemetry. Roaming hubs like Syniverse and BICS process inter-operator signaling for roaming subscribers. Aggregated, anonymized roaming telemetry from these hubs provides a third signal source that PasskeyBridge can correlate against the home and visited MNO signals.

The key architectural principle: no single signal source is trusted in isolation. The chain is constructed from the convergence of multiple, independent sources—the same multi-provider correlation philosophy applied at the roaming layer.

The eSIM complication

eSIM technology complicates IMSI-switch correlation because eSIM profile switches are indistinguishable, at the network level, from physical SIM swaps. When a subscriber activates a new eSIM profile—whether through a legitimate carrier app or through a social-engineering attack that convinces the carrier to provision a new profile—the network sees a new IMSI attaching.

PasskeyBridge handles this by incorporating the device's WebAuthn attestation (Pillar III) into the chain analysis. If the IMSI changes but the device's cryptographic identity—the passkey bound to the device's secure enclave—remains the same, the chain score receives a positive adjustment. The SIM changed, but the device didn't. This is the signature of a legitimate eSIM profile switch.

If the IMSI changes and the device identity also changes (or the passkey fails verification), the chain score drops sharply. Different SIM, different device—this is the signature of a SIM-cloning attack or an account takeover.

This is why PasskeyBridge's three-pillar architecture exists: carrier signals alone cannot distinguish eSIM profile switches from attacks. Biometric device binding (Pillar III) provides the disambiguation signal that single-pillar identity platforms lack.

Zero-PII chain storage

A critical design constraint: PasskeyBridge never stores the IMSI. The temporal chain consists entirely of:

• Keyed HMAC-SHA-256 digests of the IMSI under a server-held pepper
• Timestamps of each signal event
• Carrier identifiers (which MNO produced the signal)
• Signal metadata (response latency, API version, confidence score)

The IMSI itself is keyed-hashed (HMAC-SHA-256) at the point of ingestion and immediately discarded. If PasskeyBridge's database were compromised, an attacker would obtain a sequence of cryptographic hashes—non-enumerable without the server-held pepper, which lives outside the database in a secret store rather than in any tenant row.

This design satisfies GDPR Article 32 (security of processing), Reg S-ID (no PII storage), and our own SOC 2 Type II controls—because there is no PII to breach.

Real-world chain analysis: A worked example

Consider a legitimate business traveler flying from London (home MNO: Three UK) to Frankfurt (visited MNO: Deutsche Telekom):

Chain analysis: - Temporal delta: 2h 15m between detach and attach—consistent with a 1h 45m flight plus airport transit. Score: 0.92. - Carrier sequence: Three UK → Deutsche Telekom—known roaming pair under GSMA IR.21 bilateral agreement. Score: 0.95. - Geographic velocity: ~620 km/h—within commercial aviation range. Score: 0.88. - Hash continuity: abc123 → def456—different IMSI hash expected (different MNO). Passkey verification on the device succeeds—same device. Score: 0.90. - Composite chain score: 0.82. Legitimate roaming. No playbook triggered.

Now consider a SIM-cloning attack:

Chain analysis: - Temporal delta: 3 minutes between home attach and foreign attach. Score: 0.05. - Carrier sequence: Three UK → Vodafone DE—valid roaming pair, but concurrent activity on home network. Score: 0.10. - Geographic velocity: ~18,000 km/h—physically impossible. Score: 0.00. - Hash continuity: same IMSI hash active on two networks simultaneously—definitive cloning indicator. Score: 0.00. - Composite chain score: 0.00. Playbook triggered: session revocation, credential freeze, agent delegate suspension, team notification.

Integration with the cascade engine

Signal chains feed directly into PasskeyBridge's cascade classifier. A low chain score becomes a first-class signal in the cascade—weighted alongside SIM-swap detection, device attestation, and verifiable credential status.

The cascade engine applies the chain score as a Bayesian prior: if the signal chain indicates a likely cloning event, subsequent signals from the same IMSI hash are evaluated with elevated suspicion. This prevents attackers from "warming up" a cloned SIM by generating benign activity before attempting the actual fraud.

The chain state also propagates to the A2A trust negotiation layer. If an agent delegate was issued while the delegating user's signal chain was healthy, and the chain subsequently degrades, the delegate's trust score is automatically adjusted downward—a direct application of trust decay functions.

Performance characteristics

Signal chain correlation adds minimal latency to the identity verification path:

This keeps chain analysis inside the same request as the rest of the identity verification response rather than deferring it.

Deployment considerations

Signal chaining is enabled per-tenant via the PasskeyBridge dashboard under Settings → Signal Processing → Chain Analysis. Configuration options include:

• Chain window: How far back to look for prior signals (default: 30 days)
• Minimum chain length: How many signals are required before chain scoring activates (default: 3)
• Weight overrides: Custom weights for each scoring dimension
• Playbook threshold: The chain score below which the identity threat playbook triggers (default: 0.4)

For tenants with high-roaming user populations (airlines, logistics companies, multinational enterprises), we recommend lowering the velocity weight (w₃) and increasing the hash continuity weight (w₄) to reduce false positives from rapid international transit.

Related work

Signal chaining is one layer in PasskeyBridge's multi-signal correlation architecture. Combined with cross-referencing SIM signals against verifiable credentials, post-quantum signature protection, and satellite-terrestrial handoff awareness, it forms a roaming-aware identity layer that treats network boundary crossings as first-class security events rather than noise to be filtered out.

The era of single-snapshot, single-MNO identity verification is ending. The signal chain is the replacement.

Explore the platform → · Get started free →

Start free · Test the API