Carrier signal

A carrier signal is a fact about a phone line sourced from mobile network infrastructure: whether the SIM changed recently, whether the number was ported to another carrier, whether the line is currently reachable. Carrier signals are hard for attackers to forge because they originate in systems the attacker does not control, which makes them high-weight inputs for authentication and fraud decisions.

The practical limits are coverage and freshness. Coverage varies by operator and country, and a resold line may return nothing at all, so a signal system has to distinguish a negative answer from no answer. Freshness matters because the value of a swap report decays: a swap reported thirty seconds ago and one reported three weeks ago are different facts, and a rule that treats them alike is measuring the wrong thing.

Reading a carrier response correctly means separating three answers that arrive in the same field. A clean check, a check that found a recent change, and a line the provider cannot see are distinct facts, and only the first two are observations. Where a reseller's subscriber records sit outside the host network's view, MVNO opacity produces the third, and a client that maps it onto the first has converted a coverage gap into an assurance.

The second thing to pin down is what the provider is actually reporting. Some answer with a boolean, some with a timestamp of the last change, some with a bucketed window. A timestamp supports a rule that asks whether the change falls inside the window that matters for this action; a boolean does not, and no amount of downstream logic recovers the resolution the API did not return.

Because these signals are produced by infrastructure the attacker does not operate, they carry more weight than client-supplied evidence, which is the argument for treating them as high-weight trust signals. The weight is only earned while the answer is current, so a carrier check belongs inside the request rather than in a nightly job.