Security · 2026-03-28

Carrier Signal Fusion: Single-Provider Lookups as a Single Point of Failure

By J. W. Bouckaert

The mono-signal problem

Most identity platforms that integrate carrier intelligence do it the same way: pick a provider—Twilio Lookup v2 or Vonage Number Insight Advanced—wire up a single API call, and ship it. One provider, one signal, one verdict.

This is a single point of failure. And in identity security, a single point of failure is a single point of compromise.

The problem is not that Twilio or Vonage are unreliable. Both are mature, well-operated platforms with high availability SLAs. The problem is that each provider sees a different slice of the carrier network, processes signals through different aggregator relationships, and reports results with different latency profiles. When you depend on one slice, you inherit its blind spots as your own.

This article makes the case for carrier signal fusion—querying multiple providers for the same phone number event, correlating the results, and deriving a composite risk score that no single provider can produce alone.

Single-provider lookups

Before discussing why one provider is insufficient, it helps to understand what each provider actually reports.

Twilio Lookup v2

Twilio's Lookup v2 API returns structured fields across several packages:

Twilio derives its data from a combination of direct carrier relationships and third-party aggregators. Coverage varies by country and carrier. In the United States, Twilio's SIM swap data covers the major carriers (T-Mobile, AT&T, Verizon) but may have gaps with MVNOs and regional operators.

Vonage Number Insight Advanced

Vonage's Number Insight Advanced API returns a richer signal set through its relationship with carrier SS7 and Diameter signaling networks:

Vonage's reachability and roaming fields are derived from HLR (Home Location Register) queries—a fundamentally different data source than Twilio's aggregator-based approach. This means Vonage can detect scenarios that Twilio cannot, and vice versa.

The differences

The divergence between providers is a structural consequence of how the global telephony network operates.

1. Aggregator coverage gaps

No single carrier intelligence provider has direct relationships with every mobile operator globally. The GSMA lists over 750 mobile operators across 220 countries. Each provider fills coverage gaps through aggregators, and each aggregator introduces its own latency, caching behavior, and data staleness profile.

A SIM swap that Twilio detects through its direct T-Mobile integration in 200ms might take Vonage 800ms to surface through an aggregator path—or vice versa. During that delta, an attacker has a window.

2. Signal semantics differ

Twilio's sim_swap.swapped_in_period is a boolean. Vonage's real_time_data.sim_swap.swap_age is a numeric value in hours. These are not the same signal. A boolean tells you that a swap occurred. An age value tells you when—and recency is the variable that determines risk.

A SIM swap that occurred 720 hours ago (30 days) is categorically different from one that occurred 2 hours ago. A single boolean cannot express this distinction. A platform that relies exclusively on the boolean provider will treat both as identical risk events.

3. Porting detection asymmetry

Twilio infers porting by comparing mobile_network_code to original_network_code. If they differ, the number has been ported. This is a network-code comparison.

Vonage reports porting as an explicit status field: assumed_ported, ported, or not_ported. The assumed_ported status indicates that Vonage's data suggests porting occurred but could not be definitively confirmed—a nuance that Twilio's binary comparison cannot express.

Neither approach is wrong. Both are incomplete on their own.

4. Reachability is provider-exclusive

Vonage provides a reachable field (reachable, undeliverable, absent, bad_number) derived from HLR lookups. Twilio Lookup v2 does not expose a reachability signal at all.

A phone number that is absent (device powered off or out of coverage) during a high-value authentication attempt is a risk signal. If your stack only calls Twilio, you never see it.

The attacker's perspective

Sophisticated attackers already know which carrier API their target's identity provider uses. The information is often discoverable through timing analysis of authentication flows, error message fingerprinting, or simple reconnaissance of the target's technology stack (job postings, conference talks, GitHub repositories).

Once the attacker knows the provider, they can optimize their attack to exploit that provider's specific blind spots:

• Twilio-only target: Execute the SIM swap through a carrier path that Twilio's aggregator network processes with higher latency. The attack completes before the signal propagates.
• Vonage-only target: Exploit the gap between a port-out event and Vonage's HLR query refresh cycle. Porting status may remain not_ported for several minutes after the port completes.

This is not theoretical. The FBI's public service announcement on SIM-swap fraud and successive IC3 Internet Crime Reports document SIM-swap-enabled losses in the hundreds of millions cumulatively, with attack sophistication increasing year over year. Attackers who invest in provider-specific evasion techniques are the ones extracting the largest amounts.

Multi-provider correlation eliminates the provider-specific evasion playbook. The attacker must now evade all providers simultaneously—a categorically harder problem.

Signal fusion architecture

PasskeyBridge's shield-carrier-lookup edge function implements multi-provider carrier signal fusion. The architecture follows a query-normalize-correlate pattern:

1. Parallel provider query

When a carrier lookup is requested, PasskeyBridge queries all configured providers simultaneously, as parallel execution with independent timeout handling rather than sequential fallback.

┌──────────────┐
│  Lookup Req  │
└──────┬───────┘
       │
  ┌────┴────┐
  ▼         ▼
┌─────┐  ┌──────┐
│Twilio│  │Vonage│
└──┬──┘  └──┬───┘
   │        │
   ▼        ▼
┌──────────────┐
│  Normalizer  │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  Correlator  │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Fused Signal │
└──────────────┘

If one provider times out or errors, the system proceeds with available signals rather than failing the entire lookup. The audit log records which providers responded and their individual latencies.

2. Signal normalization

Each provider's response is normalized into a canonical signal schema:

Normalization eliminates semantic differences. Downstream systems—playbooks, intelligence workers, A2A invalidation—consume the same schema regardless of which providers contributed.

3. Risk score correlation

The normalized signals from each provider are combined into a composite risk score using a weighted stacking model:

Risk Score Composition (max 1.0)
════════════════════════════════════════════
SIM swap detected (any provider)    +0.60
  └─ Swap age < 24h                 +0.20
  └─ Swap age < 72h                 +0.10
Number ported (any provider)        +0.15
Unreachable (Vonage-only signal)    +0.10
Provider disagreement bonus         +0.05
════════════════════════════════════════════

The provider disagreement bonus is critical. If Twilio reports no SIM swap but Vonage reports swapped, the disagreement itself is a signal—it suggests that the swap event is propagating through different aggregator paths at different speeds, which is a hallmark of a targeted attack with carrier-specific timing optimization.

A single-provider stack cannot detect disagreement, because there is nothing to disagree with.

Latency

The obvious objection to multi-provider lookup is latency. If a single Twilio call takes 200ms, two providers might seem to double the response time. They do not: because the queries execute in parallel, the total latency is the maximum of the individual provider latencies, not the sum. In practice:

The marginal latency of the second provider is the difference between its latency and the first provider's, only when it is slower. For the median case, the overhead is approximately 50ms—well within PasskeyBridge's 50ms processing budget for the orchestration layer.

The fused signal is then forwarded to the shield-ingest pipeline as a single normalized event, where playbooks process it identically to any other signal type.

Cases fusion catches

Real-world scenarios where signal fusion provides detection that no single provider can:

Scenario 1: Staggered SIM swap propagation

An attacker social-engineers a SIM swap through a carrier store. Twilio's aggregator processes the event within 200ms. Vonage's HLR refresh cycle has not yet updated—sim_swap.status still reads not_swapped.

• Twilio-only stack: Detects the swap. Triggers playbook. ✓
• Vonage-only stack: Misses the swap for 3–8 minutes. ✗
• Fused stack: Detects via Twilio. Logs Vonage disagreement. Elevates risk score. Triggers playbook with enriched context. ✓✓

Scenario 2: Port-out with reachability drop

An attacker ports a number to a new carrier. During the porting window, the original carrier marks the number as absent (device unreachable). The new carrier's SIM swap status is clean—no swap occurred on their network.

• Twilio-only stack: Detects porting via MNC mismatch. No reachability data. Risk score: 0.15.
• Vonage-only stack: Detects porting. Also detects absent reachability. Risk score: 0.25.
• Fused stack: Detects porting from both providers (cross-confirmed). Detects reachability drop. Risk score: 0.30—above the threshold for automated credential freezing.

Scenario 3: MVNO coverage gap

The target's number is on a Mobile Virtual Network Operator (MVNO) that Twilio's aggregator network does not cover. Twilio returns carrier data but no SIM swap intelligence.

• Twilio-only stack: Carrier data returned. SIM swap field: null. No detection possible. ✗
• Vonage-only stack: MVNO is in Vonage's HLR coverage. SIM swap detected. ✓
• Fused stack: Twilio returns partial data. Vonage returns full signal. Fusion engine uses available signals. ✓

Operational considerations

Provider configuration

PasskeyBridge's carrier lookup supports dynamic provider configuration per tenant. Operators can enable Twilio, Vonage, or both through the dashboard Settings tab—see the identity signals guide—without code changes:

{
  "action": "providers",
  "tenant_id": "your-tenant-id"
}

The response lists all configured providers with their capabilities:

{
  "providers": [
    {
      "id": "vonage",
      "name": "Vonage Number Insight",
      "capabilities": ["sim_swap", "port_check", "reachability", "roaming"],
      "configured": true
    },
    {
      "id": "twilio",
      "name": "Twilio Lookup v2",
      "capabilities": ["sim_swap", "carrier_info", "line_type"],
      "configured": true
    }
  ]
}

Cost management

Multi-provider lookups cost more per query than single-provider. Twilio Lookup v2 with SIM Swap and Line Type packages costs approximately $0.05 per lookup. Vonage Number Insight Advanced costs approximately €0.04 per lookup.

For high-volume deployments, PasskeyBridge supports tiered lookup strategies:

• Low-risk events (routine re-authentication): Single provider, rotating between Twilio and Vonage for coverage diversity.
• High-risk events (password reset, financial transaction, agent delegation): Full multi-provider fusion.
• Critical events (Reg S-ID verification, account recovery): Full fusion with extended signal retention for audit.

This tiered approach keeps the median cost per authentication event under $0.03 while reserving full fusion for the events that warrant it.

Audit and compliance

Every carrier lookup—single or fused—is logged to PasskeyBridge's append-only audit trail with:

• Provider(s) queried and individual response latencies
• Normalized signal values (never raw PII—phone numbers are keyed-hashed with HMAC-SHA-256 under a server-held pepper before storage)
• Composite risk score and the formula that produced it
• Whether the signal was forwarded to the ingest pipeline
• Correlation ID in PasskeyBridge's standard format for end-to-end traceability

This satisfies SOC 2 Type II access control and monitoring requirements without storing a single phone number.

Fusion over fallback

The industry default for multi-provider carrier intelligence is sequential fallback: call Provider A; if it fails, call Provider B. This is a resilience pattern. Fallback handles availability. Fusion handles accuracy.

Fallback says: "If I can't reach Twilio, try Vonage."

Fusion says: "Query both. Compare results. Derive a signal that neither could produce alone."

The distinction matters because the attacks that cause the most damage—targeted SIM swaps, carrier-insider fraud, port-out timing exploits—are precisely the attacks that a single provider is most likely to miss. The attacker selects their evasion vector based on the defender's provider choice.

Fusion eliminates provider-specific evasion as an attack strategy. The attacker must now defeat the aggregated intelligence of every provider simultaneously. That is a categorically different—and categorically harder—problem.

Related work

Carrier signal fusion is the second layer of a broader convergence. PasskeyBridge's three-pillar architecture combines:

• Pillar I: Fused carrier signals (this article) and real-time SIM swap detection
• Pillar II: Verifiable credentials for identity attestation without blockchain dependencies
• Pillar III: Passkey binding with biometric presence and device provenance

When a carrier fusion signal detects a SIM swap, it does not merely log an alert. It triggers a playbook that freezes passkey credentials (Pillar III), suspends agent delegates (NF-05), and initiates verifiable credential re-issuance (Pillar II)—all within a 50ms budget.

Single-provider lookups cannot drive this orchestration reliably, because the signal they produce is too narrow to justify automated response. Fusion produces the confidence threshold that makes automated response defensible.

Explore the full carrier signal architecture → or get started free →.

Start free · Test the API