Two launches in 26 days put SIM-based possession authentication across AT&T, T-Mobile, and Verizon through two different architectures.

Aduna deployed Number Verification across all three major US carriers on July 8 through a single API that asks the carrier to confirm that a claimed mobile number matches the SIM and device in the active session. The design works whether the user is connected through cellular or Wi-Fi, removing the data-path dependency that limited earlier network verification approaches. Glide.id launched MagicalAuth into public beta across the same three carriers on August 3 using a different mechanism: a carrier-issued cryptographic credential associated with the SIM answers the authentication challenge without exposing the underlying key. From the relying party's perspective, both approaches produce a possession-based authentication signal without transmitting a code for the user to type or an attacker to intercept from a message stream.

Both designs strengthen the possession signal. That puts the legitimate processes capable of changing the underlying binding inside the enterprise control surface.

A device refresh, warranty repair, eSIM migration, number port, employee departure, device reassignment, or help desk assisted re-enrollment can change the relationship between a subscription credential and its authorized holder. These are business processes involving the enterprise, the carrier account, or both. Neither Aduna's nor Glide.id's published materials describes an enterprise-facing evidence interface showing who authorized those changes and what enterprise approval record sits behind them. CAMARA's SIM Swap API can report whether a SIM associated with a number changed and when the latest change occurred. The published interface does not supply the enterprise authorization record behind that event.

For a mobile authentication program adding carrier-based possession controls this quarter, what control records who authorized the last binding change, and what evidence can the security team produce?

Signals & Moves You Shouldn't Ignore

Aduna Number Verification launched across AT&T, T-Mobile, and Verizon on July 8.

The possession check routes through the carrier backend independently of the user's data path. A single Aduna integration provides Number Verification across the three major US networks through standardized network APIs.

Aduna is a 50:50 joint venture. Ericsson holds 50 percent and twelve communications service providers collectively hold the other 50 percent. The transaction establishing that structure closed July 29, 2025. The CSP shareholders are AT&T, Bharti Airtel, Deutsche Telekom, KDDI, Orange, Reliance Jio, Singtel, Telefónica, Telstra, T-Mobile, Verizon, and Vodafone.

Both the Aduna and Glide.id launch materials point to the scale of the fraud problem. FTC reporting for 2025 recorded $15.9 billion in consumer-reported fraud losses, compared with more than $12 billion the previous year.

Source note: Aduna press release, July 8, 2026; Ericsson press release, July 29, 2025; CAMARA; FTC testimony before the Joint Economic Committee, March 2026. Vendor claims are identified as such.

SOURCE: Aduna | Ericsson | CAMARA / Linux Foundation / GSMA | FTC

Glide.id MagicalAuth entered public beta with full US carrier coverage on August 3.

Glide uses a different authentication mechanism. Its documentation describes three strategies: TS43 through the Digital Credentials API, a carrier App Clip or App Link flow, and a cross-device QR flow for desktop. The SDK selects the strategy based on carrier, device, and platform. For its TS43 path, Glide documents carrier-signed SIM credentials accessed through the Digital Credentials API rather than an SMS code.

Glide.id describes MagicalAuth as carrier-native cryptographic authentication. That characterization is the vendor's. Its technical documentation supports the narrower architectural claim: the authentication flow uses carrier-issued cryptographic credentials associated with the SIM and can operate across internet connection types without requiring an OTP.

Source note: Glide Identity technical documentation and vendor launch materials. Vendor characterization is identified explicitly.

SOURCE: Glide Identity technical documentation | GSMA TS.43

IDEMIA and SLC Digital were already positioning SIM/eSIM hardware as a root of trust in late 2025.

IDEMIA Public Security and SLC Digital announced a partnership on October 27, 2025 combining IDEMIA's identity proofing and credentialing infrastructure with SLC's SIM/eSIM-based Hardware Root of Trust technology. Their stated use cases include high-value financial transactions, KYC and AML compliance, remittance integrity, and enterprise communications. The companies describe the objective as deterministic, hardware-bound identity validation for regulated digital environments.

The announcement predates the Aduna and Glide.id US launches and shows that SIM/eSIM-rooted identity was already being productized for regulated industries and high-value transaction environments.

Source note: IDEMIA Public Security press release, October 27, 2025. Vendor-issued.

SOURCE: IDEMIA Public Security | SLC Digital

Network verification creates data relationships whose governance depends on the deployment model.

CAMARA, a Linux Foundation project aligned with GSMA Open Gateway, defines standardized network APIs used by services such as Number Verification. Glide documents TS43 separately as an authentication strategy using the Digital Credentials API to access carrier-issued SIM credentials. Those mechanisms operate at different points in the identity transaction and should not be treated as the same architectural layer.

Within CAMARA, the Identity and Consent Management Working Group addresses privacy-by-default and consent requirements for network APIs. CAMARA states that many of its APIs require explicit user consent before access.

CAMARA also supports aggregator distribution models. An aggregator can sit between the end customer and telecom operators, handling authentication, authorization, and routing toward the appropriate operator. That means the transaction does not have to be a direct relying-party-to-carrier API call. Which participant retains request metadata, which downstream identities are exposed across the chain, what consent framework applies, and how long those records are retained depend on the implementation and commercial agreement.

For an enterprise deploying network-based verification at scale, the operating questions are concrete: what each participant retains about a verification request, what consent framework applies to employee numbers, how a disputed verification event would be investigated, and which party can produce the records required for that investigation. The launch materials do not answer those enterprise-specific questions.

Source note: CAMARA Identity and Consent Management Working Group; CAMARA Consent Info; CAMARA distribution model documentation; Glide Identity technical documentation.

SOURCE: CAMARA | Linux Foundation | GSMA | Glide Identity

The Authorization Evidence Gap

Detection tells you what changed. The authorization record tells you who approved it.

CAMARA's Authentication and Fraud Prevention portfolio includes stable SIM Swap and Device Swap APIs. SIM Swap can report whether the SIM associated with a mobile number changed within a defined period and can return the timestamp of the latest change. Device Swap can report whether the subscription associated with a SIM moved to another physical device and when that event occurred. These signals give fraud and identity systems network evidence they can use when evaluating authentication risk.

The published interfaces report the network event. They do not supply the enterprise approval record associated with it. A scheduled eSIM migration, hardware replacement, or other legitimate change still has to be interpreted against the organization's own records showing who requested it, who approved it, and what evidence supported the approval.

An enterprise program that combines carrier-based possession authentication with SIM or Device Swap signals has more network evidence available for fraud decisions. The remaining governance requirement sits with the enterprise: producing evidence of who approved a legitimate binding change, through which process, and against what documentation. That record comes from the business process surrounding the network event.

Corporate-liable and BYOD subscriptions produce different evidence problems. The enterprise controls the carrier account for corporate-liable subscriptions and can define the approval workflow around binding changes. With BYOD, the carrier relationship belongs to the individual subscriber. The enterprise may be able to consume network risk signals while still lacking direct access to the carrier-account authorization history behind a specific change.

SOURCE: CAMARA SIM Swap API, v2.1.0, stable | CAMARA Device Swap API, stable

My Take

Carrier-based possession authentication is the right direction. Moving authentication away from user-entered SMS codes and toward carrier-backed possession signals removes a familiar interception and social-engineering path. The new implementations also work across connection types that created friction for earlier network-verification approaches.

The control I would test after deployment is whether the enterprise can produce an authorization record for the last binding change. That record should identify the device or subscription change, when it happened, who approved it, what evidence supported the approval, and where that evidence can be retrieved.

For corporate-liable subscriptions, the enterprise owns the carrier relationship and should be able to define that workflow. BYOD is structurally different. The enterprise did not establish the subscriber's carrier account, does not own it, and may have limited access to the account-level history behind a binding change. Strong possession authentication across a BYOD fleet can therefore coexist with weak enterprise evidence about who authorized a specific carrier-account change.

An attacker who succeeds in routing a convincing device replacement, SIM change, port, or account request through an authorized operational channel may gain control of the binding that the authentication system subsequently trusts. The authentication can perform exactly as designed against a binding changed through a process the enterprise failed to govern.

That moves the post-deployment conversation to the carrier account team, identity team, security team, and IT operations owner. They need to establish which binding changes require enterprise authorization, what evidence is retained for each approval, who owns that evidence, and how quickly it can be produced during an investigation.

For enterprise security teams, the next deliverable is the authorization record behind those binding changes.

— William

One Thing Worth Doing This Week

Build a binding change authorization record for your mobile fleet.

Document every path by which a subscription credential can legitimately move to another device or person. Record the authorized approver, evidence required, evidence retained, record location, and security team's access to it. Separate corporate-liable and BYOD subscriptions because the enterprise's relationship to the carrier account is different.

Corporate-liable subscriptions:

BYOD subscriptions:

The corporate-liable table tests whether the enterprise can enforce and prove its own authorization process. The BYOD table tests something different: how much evidence the enterprise can obtain when the underlying carrier account belongs to the employee. Record the gaps instead of hiding them. An unavailable record is itself useful information when the security team knows that before an incident.

Use the completed review to structure the conversation with the carrier account team and IT operations owner. Corporate-liable programs have a more direct path to improving authorization controls because the enterprise holds the carrier relationship. BYOD requires an explicit decision about which binding-change risks the enterprise can investigate, which evidence it can obtain, and where compensating controls are required.