Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

TS.43 device-bound authentication: what changes for IAM teams?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 10745
Topic starter  

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.

NHIMG editorial — based on content published by Prove Identity: The Last Gap in Silent Network Authentication. Closed

By the numbers:

Questions worth separating out

Q: How should security teams replace SMS OTP in high-risk authentication flows?

A: Replace SMS OTP gradually, starting with the highest-risk journeys such as account recovery and transaction approval.

Q: Why does device-bound authentication still require IAM governance?

A: Because a stronger signal does not remove lifecycle risk.

Q: What do organisations get wrong about SIM-based authentication?

A: They often assume SIM control is equivalent to user identity.

Practitioner guidance

  • Reclassify SMS OTP as fallback authentication only Limit SMS to low-risk or recovery scenarios where stronger factors are unavailable, and define clear policy thresholds for when it is no longer acceptable as a primary assurance method.
  • Map device-bound authentication to specific risk events Use TS.43 only for the transactions and sessions where carrier-backed device assertions materially reduce fraud, such as account access, payment approval, or step-up checks.
  • Separate SIM assurance from person assurance Update identity architecture so SIM control, device binding, and proofing are tracked as distinct trust layers with different failure modes and recovery paths.

What's in the full article

Prove Identity's full blog covers the operational detail this post intentionally leaves for the source:

  • How Prove integrates TS.43 into existing authentication workflows without requiring a new carrier implementation project
  • The way Prove handles carrier-specific consent variation across markets and regulatory requirements
  • The platform's device-binding model and why Prove says it reduces repeat carrier transactions
  • The commercial and rollout implications for clients already using Prove Mobile Auth or Prove Unified Authentication

👉 Read Prove Identity's blog on TS.43 and device-bound authentication →

TS.43 device-bound authentication: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 10300
 

SMS OTP is now a governance liability, not just a weak factor. The problem is not only that OTP can be phished or intercepted. It is that the control assumes the delivery channel is trustworthy enough to stand in for identity, which no longer holds in high-risk consumer flows. Regulated teams should treat SMS as a fallback of last resort, not an authentication anchor.

A few things that frame the scale:

  • 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
  • A separate finding shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why lifecycle discipline remains a control gap in identity programmes.

A question worth separating out:

Q: Who should own mobile authentication decisions in the enterprise?

A: Ownership should sit across IAM, fraud, and product security because the control affects both user trust and transaction risk. If one team owns the channel without visibility into recovery policy, step-up logic, and exception rates, the organisation will end up with fragmented assurance and uneven user treatment.

👉 Read our full editorial: TS.43 and device-bound authentication reshape SMS OTP risk



   
ReplyQuote
Share: