By NHI Mgmt Group Editorial TeamBased on Prove Identity: “The Last Gap in Silent Network Authentication. Closed.” (April 16, 2026)

TL;DR: GSMA TS.43 Release 11 extends silent network authentication across browser and app sessions, reducing reliance on SMS OTP while adding consent-based, hardware-backed verification, according to Prove Identity. The real governance question is not whether the channel is stronger, but how identity teams manage SIM swap risk, consent handling, and device binding without mistaking transport for identity assurance.


At a glance

What this is: This article explains how GSMA TS.43 extends silent network authentication to browser and app sessions and why that matters for reducing SMS OTP dependence.

Why it matters: IAM and identity verification teams need to understand that stronger device-bound signals can improve authentication flows, but they do not eliminate consent, SIM swap, or identity binding governance.


Context

SMS OTP remains common because it is familiar, but it is no longer a reliable default for higher-risk identity verification. The core governance gap is that the channel used to deliver an authentication code is not the same thing as proof of the person behind the session.

GSMA TS.43 Release 11 extends silent network authentication so it can work across browser and app sessions, including browser on Wi-Fi where earlier implementations fell short. That makes the topic relevant to identity verification, authentication design, and consumer journey governance rather than to transport security alone.

The article’s key point is that device-bound authentication can close an operational gap in session coverage, but teams still have to decide what identity assurance they are actually accepting. The standard changes how the signal is delivered, not the underlying requirement to manage fraud, consent, and binding quality.


Key questions

Q: What breaks when banks rely on SMS OTP as the only transaction authentication method?

A: Banks expose themselves to account takeover and transaction fraud because a stolen or relayed OTP proves only that a code was received, not that the session, device, or transaction is trustworthy. Once the attacker controls the channel or the user is socially engineered, the code becomes a weak hurdle rather than a real assurance step.

Q: Why do device-bound authentication signals still need consent governance?

A: Because the signal is only useful if the user authorises the carrier or platform action that makes it possible. Consent becomes part of the control, not just a legal wrapper. If the consent journey is confusing, inconsistent, or poorly logged, the authentication step loses trust and operational reliability.

Q: How should teams decide where to replace SMS OTP with silent network authentication?

A: Start with journeys that are both frequent and fraud-sensitive, then test whether the device-bound signal covers the actual session context, including browser on Wi-Fi. Do not replace OTP everywhere by default. The right use cases are the ones where better channel assurance meaningfully reduces risk without creating brittle fallbacks.

Q: What is the difference between device binding and identity proofing?

A: Device binding ties a verification outcome to a trusted device, while identity proofing establishes that the person is who they claim to be. They solve different problems. A strong device signal can reduce fraud in a session, but it should not replace proofing for onboarding, recovery, or regulated high-assurance events.


Technical breakdown

How TS.43 extends silent network authentication

Silent network authentication uses the mobile network and SIM or eSIM context to verify a session without sending the user a code. TS.43 Release 11 extends that model so authentication can work across browser and app sessions, including cases where the device is on Wi-Fi. The important technical change is coverage, not a new trust model: the standard broadens where the network-backed signal can be used. Practical implication: architecture teams should treat TS.43 as an authentication channel extension, not as a replacement for identity proofing.

Practical implication: treat TS.43 as a channel extension, not as a replacement for identity proofing.

Why device binding is different from SMS OTP

SMS OTP proves that a phone number can receive a message at a moment in time. Device-bound authentication ties the verification outcome to the device and its hardware-backed properties instead. That reduces exposure to phishing and message interception, but it also changes the control question from code delivery to device trust and binding quality. Practical implication: identity teams should map which journeys can move from shared-secret delivery to device-bound verification without weakening fraud controls.

Practical implication: map which journeys can move from shared-secret delivery to device-bound verification without weakening fraud controls.

Where consent and SIM swap still matter

TS.43 is not person authentication by itself. The article makes clear that the standard still relies on carrier-by-carrier user consent and that SIM swap remains a live abuse path because the SIM, not the person, is still part of the trust chain. That means the assurance gain depends on how consent is presented, recorded, and governed, and on whether the binding survives account takeover paths. Practical implication: governance must cover consent handling and fallback controls wherever SIM-based trust is used.

Practical implication: govern consent handling and fallback controls wherever SIM-based trust is used.


Threat narrative

Attacker objective: The attacker wants to impersonate the victim long enough to complete account access or a fraudulent transaction.

  1. Entry occurs when an attacker leverages SMS OTP weaknesses such as phishing or SIM swap rather than a strong device-bound signal.
  2. Credential access follows when the attacker intercepts or redirects the verification factor and uses it to satisfy an authentication step.
  3. Escalation happens when the attacker uses the verified session to access the target account or transaction flow.
  4. Impact is account takeover or fraudulent transaction execution under the appearance of legitimate authentication.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

TS.43 does not eliminate authentication risk, it relocates it. The control plane moves from message delivery to device trust, consent governance, and binding quality. That is a better failure mode than SMS OTP, but it is still a governance model, not proof of personhood. Practitioners should stop treating stronger transport signals as equivalent to stronger identity assurance.

Device-bound authentication narrows the attack surface, but only if the binding is governed as an identity lifecycle event. A session signal that is easy to start but hard to bind, rebind, or revoke creates a different class of operational debt. The identity programme now has to manage how trust is established, reused, and withdrawn across devices, not just how a code is delivered.

Consent has become part of the authentication control, not a legal footnote. If carrier consent flows are confusing or inconsistent, they become a security and conversion problem at the same time. That means authentication design, consent UX, and fraud policy now intersect in the same control decision.

The named concept here is browser-session coverage gap. Legacy silent network authentication failed exactly where modern identity journeys spend time, in browser sessions on Wi-Fi. TS.43 closes that gap, but the implication for teams is broader: control design must follow the actual session context, not the assumptions built into older channel-specific authentication models.

What this signals

Browser-session coverage gap: The real governance issue is not whether a stronger factor exists, but whether it covers the sessions where customers actually authenticate. When older silent network approaches stop at the browser boundary, teams inherit an artificial exception that fraudsters can target.

Device-bound authentication is only useful when the trust chain is explicit. That means separating device trust, consent capture, recovery rules, and step-up policy instead of collapsing them into one binary authentication decision.


For practitioners

  • Map browser-session authentication coverage Identify which customer journeys still depend on SMS OTP only because older silent authentication could not reach browser sessions on Wi-Fi. Reclassify those journeys by fraud severity and decide where device-bound verification can safely replace code delivery.
  • Govern consent as a security control Document how consent is shown, captured, and logged for carrier-based authentication flows. Require a fallback path when consent prompts create ambiguity, because unclear consent handling weakens both trust and conversion.
  • Reassess SIM swap exposure Review high-risk journeys where SIM-based trust is still part of step-up authentication. Add compensating checks for number change events, device binding changes, and recent authentication anomalies.
  • Differentiate device trust from identity proofing Separate the decision to trust a device from the decision to verify a person. Keep proofing, recovery, and step-up rules independent so a stronger channel signal does not become a substitute for identity assurance.

Key takeaways

  • TS.43 changes the authentication question from code delivery to device-bound trust, which is an improvement but not a full answer to identity assurance.
  • The remaining risks are governance risks as much as technical risks, especially where consent handling and SIM swap exposure still shape the control.
  • Practitioners should evaluate where browser-session coverage, recovery policy, and proofing requirements must stay independent even if silent network authentication is adopted.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63B — AuthenticationTS.43 changes how authentication assurance is delivered across browser and app sessions.
Recommendation — Apply SP 800-63B to separate authenticator strength from proofing and recovery decisions.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about how authentication signals support authorised access decisions.
Recommendation — Use PR.AA-05 to align access decisions with the assurance level of the device-bound factor.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article describes a stronger non-human trust signal used in authentication flows.
Recommendation — Review NHI authentication flows for assumptions that still depend on SMS OTP and shared-secret delivery.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementThe article centres on replacing one authenticator path with another and governing its use.
Recommendation — Apply IA-5 to govern lifecycle, binding, and revocation of authentication factors and related credentials.
OWASP API Security Top 10API2 — Broken AuthenticationThe risk discussed is authentication weakness rather than an application flaw, but API-style auth patterns are analogous.
Recommendation — Harden authentication paths so transport or factor delivery cannot substitute for identity assurance.

Key terms

  • Silent Network Authentication: A phone-number verification method that confirms device and SIM association through the carrier network instead of sending a one-time code. It reduces exposure to phishing and SMS pumping because the user does not need to read or return a secret.
  • Device-bound authentication: Authentication that only works on a specific device or trusted local context. It reduces replay risk because the secret is not useful from elsewhere, which is materially different from centrally stored credentials that can be stolen and reused remotely.
  • SIM swap: A takeover technique in which an attacker convinces a mobile carrier to move a victim’s phone number to a SIM card the attacker controls. Once successful, the attacker can receive SMS messages and intercept one-time codes, turning the phone number into a compromise path rather than a factor.
  • Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org