Security · 2026-11-02

Carrier Signal Landscape 2027

By J. W. Bouckaert

Scope of this edition

This is the 2027 edition of a survey we will reissue each November. The previous edition, The Carrier Signal Landscape in 2026, was published on 20 February 2026. It covers the carrier identity APIs a fraud or identity team can call today to ask a mobile network about a phone number: whether its SIM changed, whether the device in front of you holds that number, and whether the operator's subscriber record matches what the user typed. It covers the standards that define those calls, the commercial layer that sells them, the US rules that oblige carriers to protect the underlying events, and how PasskeyBridge consumes the answer.

Every factual row maps to a primary source read on 10 October 2026: a CAMARA release, a GSMA, operator or vendor publication, or an FCC document. Where a number could not be sourced, the row is absent and the gap is stated in its section.

The standards layer: CAMARA and GSMA Open Gateway

The GSMA announced Open Gateway on 27 February 2023 in Barcelona, "launched with the support of 21 mobile network operators", with eight initial APIs including SIM Swap, Device Status, Number Verify and Device Location. The same release states where the definitions live: Open Gateway APIs "are defined, developed and published in CAMARA, the open source project ... driven by the Linux Foundation in collaboration with the GSMA".

That split matters to an integrator. CAMARA publishes OpenAPI files under version tags in public repositories, so the contract can be read before any commercial agreement exists. Open Gateway is the operator commitment to expose those contracts. Three CAMARA definitions carry identity weight.

SIM Swap: two questions, one window

The SIM Swap definition answers two questions through two operations. retrieve-date returns latestSimChange, an RFC 3339 timestamp of the most recent swap. check takes maxAge in hours and returns a boolean swapped. The schema bounds maxAge at 1 to 2400 hours, with a default of 240.

Two parts of the contract decide how much a "no" is worth.

• Local rules can cap the window below what the schema allows. An operator whose privacy threshold is shorter than the requested window answers 400 OUT_OF_RANGE, and the specification's own example message cites a 30-day limit.
• latestSimChange is nullable. When the operator cannot disclose the date, it returns null, optionally with monitoredPeriod in days, and the response is to be read as "no swap during that period". The r4.1 pre-release caps monitoredPeriod at 999.

The definition also counts more than fraud as a swap. It names a lost or damaged SIM, a new handset, a change of provider that keeps the number, a multi-SIM activation and a new subscription. A swap flag is evidence that the number moved to a new SIM, and the decision about intent stays with the relying party.

Release r3.3 also ships a subscriptions API that pushes the event type org.camaraproject.sim-swap-subscriptions.v0.swapped, so a relying party can be told about a swap instead of polling for it.

Number Verification: possession without a code

Number Verification confirms that the device making the request holds the number the user claims. /verify answers true or false for a number sent in plain form or hashed, and /device-phone-number returns the number itself. The r3.2 text states that "the API provider guarantees that there is no user interaction". Without a TS.43 temporary token, the device must be on the mobile network for the check to run; with one, it works "over all connections e.g. WiFi".

The r4.1 pre-release adds three token rules: an access token for these scopes is single-use, carries no refresh token, and expires within 300 seconds.

One detail needs care on the relying-party side. The hashed form is "SHA-256 (in hexadecimal representation) of the mobile phone number in E.164 format". An unkeyed digest of a phone number protects the number in transit to the operator. It does not make the number unrecoverable, because the E.164 space is small enough to enumerate. Keep that digest out of your own storage; at rest, key it.

KYC Match: attribute checks against operator records

KYC Match compares attributes a service provider holds, such as name, address, birthdate and an identity document number, against the operator's verified subscriber record. Each attribute comes back as a match result, with a score from 0 to 100 for partial text matches, or as not_available. An operator may require idDocument to match before it compares anything else. The release is still at 0.3.0, so expect field changes before a 1.0.

The commercial layer: aggregators and operator programmes

A CAMARA contract does not come with operator reach. Reach is sold through aggregators and operator programmes, Aduna among them. Ericsson announced on 29 July 2025 that Aduna is "now a 50:50 joint venture", operational since 11 September 2024, owned by Ericsson together with AT&T, Bharti Airtel, Deutsche Telekom, KDDI, Orange, Reliance Jio, Singtel, Telefonica, Telstra, T-Mobile, Verizon and Vodafone, on a platform "based on the CAMARA open-source project".

Communications platforms resell the same capabilities under their own request shapes. Two that PasskeyBridge integrates document their coverage in detail:

Vonage also lists device_swap and subscriber_match insights, and marks roaming, reachability and location_verification as Developer Preview.

Regulation behind the signal

The FCC adopted its SIM swap and port-out fraud order, FCC 23-95, on 15 November 2023. It requires wireless providers to use secure authentication before a SIM change or number port, to notify customers of SIM change and port-out requests, and to "offer customers the option to lock their accounts". On 5 July 2024 the Wireline Competition Bureau (DA 24-649) denied a waiver to 10 March 2025 and set a single compliance date for every rule in the order, which arrives once OMB completes its review and the Commission announces the date in the Federal Register. The current eCFR text of 47 CFR 64.2010(h)(9), read on 10 October 2026, still says compliance "will not be required until this paragraph is removed or contains a compliance date". For a relying party, the carrier-side controls the order describes are not yet a compliance baseline you can assume.

Pricing and availability are out of scope

This edition does not cover pricing or availability. It publishes the coverage that vendors and CAMARA document, and nothing on what carrier APIs cost or how often they answer. None of the primary sources read for this edition carries a per-call price list for these APIs, or availability and error-rate figures. A table built from sales quotes or third-party estimates would not meet the sourcing rule this survey runs on. If operators publish either, the 2028 edition will carry it with the citation.

The PasskeyBridge carrier path

PasskeyBridge consumes carrier answers. It does not run a network. The carrier lookup function accepts four providers, and the code fixes what each can report:

Three rules in that code follow from the contracts above.

• An unanswered insight is a failure. A SIM swap insight whose status is not OK fails the lookup. It is never recorded as "no swap", for the reason the CAMARA null case shows: absence of an answer is not evidence.
• A window is scored at its upper bound. Sinch reports a swap as a window, and the age recorded is that window's upper bound, so a swap is never scored as more recent than the provider said.
• Unrequested fields stay neutral. Identity Insights is asked only for sim_swap, so porting and reachability are not inferred from it.

The risk score is additive and capped at 1.0: a detected swap adds 0.60, a swap under 24 hours old adds a further 0.20 and one under 72 hours a further 0.10, a ported number adds 0.15, and an unreachable one 0.10. The forwarded signal carries nine fields, among them phone_hash, sim_swap_detected and sim_swap_age_hours, and never the number.

The number itself is handled under one rule. In a hosted lookup it is in memory for the single vendor call, and only a keyed digest is stored, audited or forwarded: HMAC-SHA-256 under a server-held pepper. A tenant that runs its own lookup can use the record action instead and post the normalized answer with a digest it computed; a record body that carries a phone number is refused. The full request and scoring rules are in the carrier provider setup guide, and the product view is on the SIM swap detection page. For how answers differ across carriers for the same event, see our earlier post on carrier signal variance.

Open items for the 2028 edition

• The FCC compliance date for 47 CFR 64.2010(h) and 52.37, once published in the Federal Register.
• Stable releases of SIM Swap 2.2.0 and Number Verification 2.1.1, and whether KYC Match reaches 1.0.
• Published pricing or availability figures from any operator or aggregator.

Start free · Test the API