Security · 2026-05-12

Carrier Signal Freshness: TTL and Signal Strength

By J. W. Bouckaert

A carrier check records the line when it ran

Carrier attestations are often listed by type: SIM-swap checks, device-binding lookups, Number Verify, Know Your Customer Match, location confidence and roaming flags. The security value of each signal depends on when it was observed.

A SIM-swap check that returned "no swap in last 24 hours" describes the line at the moment the check ran. If that check ran twelve hours ago and the response was cached, then in the hours since, the SIM could have been swapped, a fraudulent OTP intercepted, the password reset and the funds moved, and the session being authenticated now could be the attacker's.

A cached answer is a historical record of the line. When a stack treats that record as the current state, an attacker can act in the gap between the check and the decision. The longer that gap, the more time the attacker has to swap the SIM, take over the number and finish the account change before anyone checks again.

Rank signal attributes with freshness first

Carrier signals lose value with age. So do device-attestation chains, behavioral-drift scores and the other checks that identity layers describe as real-time. The loss is nonlinear, and it continues regardless of the cache TTL a platform team sets.

Ranked by how much they matter to a security decision, the attributes of an identity signal are:

1. Freshness. When was this observed? This is the only attribute that can collapse the security value of every other attribute to zero.
2. Provenance. Who observed it? A carrier-direct lookup carries different weight than a copy cached by one or more aggregators.
3. Binding. What does it bind to? A SIM-swap check tied to an MSISDN that is not the MSISDN being authenticated has no control value.
4. Strength. How confident is the underlying observation? It ranks fourth.

Many identity stacks optimize for strength and treat freshness as an implementation detail. A security decision should check freshness first.

The freshness decay curve

From the moment a carrier signal is observed, the probability that the underlying state has changed—and that the cached signal is now actively misleading—rises monotonically. The curve is not a smooth exponential, because the underlying events (SIM swap, device handoff, eSIM profile switch, number recycling) are themselves discrete. But across a population, the aggregate decay is well-approximated by a step-rising hazard function.

The rows below illustrate that shape. They are illustrative figures that PasskeyBridge has neither measured nor calibrated against a published benchmark:

The figures vary by carrier, country and population segment. In this shape, the security value of a carrier attestation falls sharply inside the first sixty seconds and is mostly gone by the end of the first hour.

ASCII rendering of the decay, normalized so that "fresh observation" = 1.0:

1.0  ▌
     ▌▌
0.9  ▌▌▌
     ▌▌▌▌
0.8  ▌▌▌▌▌▌
                ▌▌▌▌▌▌▌▌
0.7                     ▌▌▌▌▌▌▌▌
                                ▌▌▌▌▌▌▌▌▌▌
0.6                                       ▌▌▌▌▌▌▌▌▌▌▌▌
0.5  └──┬──────┬──────┬──────┬──────┬──────┬──────┬──→
       0.5s    5s     60s    5m     1h     12h    24h
                              signal age

A claim to check SIM-swap status therefore needs a stated maximum response age, in single-digit seconds by the figures above. An older response serves as a compliance record.

The economics of caching

Vendors cache because fresh carrier lookups cost money. Each fresh lookup is a paid, rate-limited call to a carrier or an aggregator, and a cached answer avoids that call.

A typical Tier-1 carrier API charges per query and rate-limits aggressively. Operator-side aggregators (Twilio Verify, Vonage Number Insight, Sinch, Telesign) absorb that cost and resell at a markup. At enterprise scale—millions of authentications per day—the per-call price difference between a fresh lookup and a cached response can decide whether an identity layer built on fresh lookups is affordable at all.

So vendors cache. The ranges below are a picture of published vendor defaults. PasskeyBridge has not benchmarked them:

An aggregator can market a "real-time SIM-swap API" while caching responses for thirty days. The query runs in real time, and the response it returns can be a month old. Unless the contract sets a maximum response age, both statements hold at once.

Cached responses are one reason the silent number recycling and invisible SIM-swap attack classes get past carrier-attestation checks.

Sub-second TTL in practice

A lower TTL leaves an attacker less time between the check and the decision. The same MSISDN, queried at the moment of authentication, can show a change that an hour-old cached lookup cannot see.

The difference is largest for these attack classes:

A lookup made during the authentication sees a change that an hour-old cached answer has already missed.

Carrier lookup on this platform

shield-carrier-lookup asks one provider when you call it. It does not keep a carrier-signal cache, it does not apply a 1500 ms ceiling, and it does not weight two providers by age. The answer is as fresh as that provider's answer on that call.

Hosted lookups (Vonage Number Insight, Twilio Lookup) spend the hosted-lookups add-on. A lookup that names no provider uses the Vonage application registered under Settings, or the tenant's Sinch Number Lookup project when that is the registration on file.

An ingested signal records decision_ms for PasskeyBridge's own work on the request. That figure is separate from the carrier round trip, and it is not a published latency target.

Questions for your identity vendor

These questions are for a vendor that sells multi-provider freshness. shield-carrier-lookup asks one provider and stores no signal age.

Five questions that show whether a vendor ranks freshness above strength:

1. What is the maximum age of a carrier signal that can contribute positively to an allow decision? If the answer is in minutes or hours, the vendor's allow decisions can rest on signals that are minutes or hours old.
2. What is the median observed age of the signals you used in my last 1,000 authentications? If the vendor cannot answer, the data is not in the audit log, which means the audit log cannot answer "was this defensible at the time."
3. When two providers return conflicting signals at different ages, how do you reconcile? A freshness-first vendor answers that the freshest signal wins, weighted by a decay constant, ahead of the highest-confidence signal.
4. Is your cache TTL configurable per tenant? If not, every tenant gets the single cache TTL the vendor chose for its own costs.
5. What is your carrier-direct integration ratio versus aggregator passthrough? Aggregators add a second layer of caching that the vendor can neither see nor control.

The answers show whether the verification you are buying uses current carrier data or stored answers from minutes, hours or days earlier.

Direction of the standards

Freshness as a first-class property is the direction the standards bodies are already moving: OpenID SSE/CAEP, SCIM 2.0 event signaling, GSMA Open Gateway's CAMARA APIs, and the eIDAS 2.0 EUDI Wallet all assume push-based, freshness-stamped signaling rather than pull-based polling against stale caches.

Pipelines built around long caches will need changes to fit these standards. Pipelines built around fresh lookups already fit their push-based, freshness-stamped model.

---

Carrier lookup setup is in the identity signals guide. Single-provider lookups describes the one provider a PasskeyBridge call asks.

Start free · Test the API