TL;DR: The CBUAE will end SMS and OTP for UAE financial institutions by March 2026, pushing banks toward phishing-resistant passkeys that reduce fraud, user friction, and operational cost, according to HYPR. The real issue is not the authentication factor itself but the governance shift from legacy, interceptable credentials to device-bound assurance that changes how IAM, CIAM, and step-up controls are designed.
At a glance
What this is: This is a HYPR analysis of the CBUAE’s SMS and OTP ban, arguing that passkeys should be treated as a governance response to fraud, friction, and legacy authentication risk.
Why it matters: It matters because banking IAM teams must now redesign customer authentication, step-up flows, and lifecycle controls around phishing-resistant credentials rather than interceptable one-time codes.
Context
The article is about a governance change in customer authentication for UAE financial institutions: by March 2026, SMS and OTP are being phased out under the CBUAE mandate. That matters because one-time codes have long been treated as a default control even though they remain exposed to phishing, SIM swapping, and social engineering.
Passkeys shift the security model from shared or intercepted secrets to device-bound authentication that is harder to replay and easier for customers to use. For identity teams, the question is no longer whether to preserve OTP as a fallback, but how to rework onboarding, login, and transaction approval around a stronger assurance pattern.
Key questions
Q: How should banks replace SMS OTP for high-risk transactions?
A: Banks should move high-risk actions to step-up authentication that is bound to the transaction, not the login. That usually means in-app approval, software tokens, device biometrics, or other stronger second factors, plus beneficiary confirmation for payment events. The goal is to make the approval decision harder to intercept, replay, or socially engineer.
Q: Why do SMS OTP codes remain risky even when they are paired with other controls?
A: SMS OTP remains risky because the code is still delivered through an interceptable channel and can be phished, redirected, or abused during SIM swap attacks. Extra controls help, but they do not change the basic problem that the factor is not cryptographically bound to the intended device or relying party.
Q: What should IAM teams review before rolling out passkeys at scale?
A: Review federation configuration, enrolment verification, recovery procedures, and the impact on support and help desk workflows. Teams should also check whether existing users, new users, and lost-device scenarios all have clear, governed paths to sign in or regain access.
Q: When is it safe to keep OTP as a fallback for banking customers?
A: It is only defensible as a tightly governed exception for limited recovery or transition use cases, not as the default login factor for sensitive accounts. If OTP remains easy to invoke, it becomes the weakest path in the authentication stack and weakens the overall passkey programme.
Technical breakdown
Why SMS OTP fails as an assurance factor
SMS OTP depends on a code delivered over a channel the attacker can intercept, redirect, or socially engineer. That makes it weaker than a possession factor tied to a cryptographic private key on the user’s device. In banking, the control failure is not only theft of the code but the fact that the factor can be replayed outside the intended session context. Passkeys remove the shared secret from the flow and bind authentication to the bank’s app or website, which materially changes the attack surface for customer identity assurance.
Practical implication: treat SMS OTP as an exposure-prone fallback, not a primary banking authentication design.
How passkeys change login and step-up authentication
Passkeys use public-key cryptography and device-native verification such as biometrics or PIN, so the authenticating secret never leaves the device. Because the credential is bound to the relying party, phishing pages cannot reuse it against another domain. That changes step-up design as well: instead of sending a code for every sensitive action, the bank can challenge the same cryptographic proof within a higher-risk transaction flow. The result is stronger assurance with less friction, especially where repeated OTP prompts create abandonment or support burden.
Practical implication: redesign step-up flows around passkey-based transaction confirmation instead of code delivery.
Why CIAM must extend beyond first login
A customer identity programme does not end at sign-in. The article’s CIAM framing matters because onboarding, everyday authentication, and high-risk actions are different control moments with different assurance needs. Passkeys can support all three, but only if registration, device binding, recovery, and transaction authorisation are governed as one lifecycle. If those stages are treated separately, teams create weak fallback paths, inconsistent recovery, and new fraud openings around account takeover or device replacement.
Practical implication: govern passkey enrolment, recovery, and transaction step-up as one CIAM lifecycle.
NHI Mgmt Group analysis
SMS OTP bans expose a governance debt, not a feature gap: The CBUAE mandate shows that organisations have tolerated an authentication pattern whose threat model no longer matches the fraud environment. SMS OTP persists because it is familiar and easy to deploy, not because it offers durable assurance. Practitioners should read this as a signal that policy pressure is forcing long-delayed identity design decisions into the open.
Passkeys shift assurance from shared delivery channels to device-bound trust: The practical value is not that passkeys are modern, but that they collapse the attack paths that make OTP brittle, including interception and reuse. That creates a different governance burden for CIAM and banking IAM teams, because enrolment, device binding, and recovery become the controls that matter most. The implication is that authentication strategy now lives inside lifecycle design.
Customer identity assurance is becoming a transaction control, not just a login control: The article correctly extends passkeys beyond sign-in into onboarding and sensitive actions. That matters because fraud prevention depends on when assurance is applied, not just which factor is used. A banking programme that treats authentication as a login checkbox will miss the real decision point, which is whether high-risk transactions are still protected by legacy, replayable factors.
Device-bound authentication is the right named concept for this shift: The central governance change is that proof of identity is moving from a deliverable code to a credential anchored in the customer’s device and the intended relying party. That changes fraud economics, help-desk pressure, and customer experience at the same time. IAM leaders should treat this as a redesign of trust boundaries, not a single-factor replacement project.
The March 2026 deadline accelerates architectural decisions that should already have been made: The mandate does not create the underlying risk, but it removes the option to defer it. Organisations that wait until compliance deadlines compress migration into a hurried rollback-prone programme, while early movers can align authentication, recovery, and step-up controls around one assurance model. The implication is clear: banking identity architecture now has a regulatory forcing function.
From our research library:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
What this signals
Device-bound authentication is becoming the governance baseline: Banking teams should expect regulators and risk owners to treat cryptographic, device-bound assurance as the default standard for customer identity. Once that happens, the control question shifts from whether OTP is convenient to whether any remaining fallback preserves replayable trust.
Passkey migration should be planned as a CIAM lifecycle change: The hard work is in enrolment, device binding, recovery, and transaction approval, not the login screen alone. Teams that separate those controls will end up with inconsistent assurance levels and exception paths that reintroduce the same fraud exposure under a different name.
For practitioners
- Replace SMS OTP with phishing-resistant passkeys Prioritise customer journeys where code interception and SIM swap risk create the largest fraud exposure, then phase out OTP as the primary factor in those paths.
- Redesign transaction step-up around cryptographic assurance Use passkey-based confirmation for sensitive actions so step-up occurs inside the authenticated session instead of relying on a separate delivered code.
- Unify onboarding, login, and recovery into one CIAM control set Treat passkey enrolment, device binding, account recovery, and transaction approval as linked lifecycle stages rather than separate authentication projects.
- Remove fallback paths that preserve replayable factors Review recovery and exception handling so temporary OTP exceptions do not become the default route for high-risk banking actions.
Key takeaways
- The article frames the CBUAE ban as a governance reset for banking authentication, not just a compliance task.
- Passkeys matter here because they replace interceptable codes with device-bound assurance that is harder to phish or replay.
- IAM and CIAM teams need to redesign recovery, onboarding, and step-up controls together or the weakest fallback will define the programme.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on replacing weak customer authentication with phishing-resistant passkeys. |
| NHI-10 — Human Use of NHI | Customer passkeys are non-human credentials used through human-operated devices and flows. | |
| Recommendation — Replace replayable authentication factors with phishing-resistant passkeys for customer journeys. Govern passkey enrolment and recovery as non-human credentials tied to customer device use. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about strengthening authorization and assurance for customer access paths. |
| Recommendation — Align customer authentication assurance with access decisions and step-up controls. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | Passkeys and OTP replacement are directly within digital authentication guidance. |
| Recommendation — Apply digital authentication guidance to phase out weak OTP paths and adopt phishing-resistant methods. | ||
| CIS Controls v8 | CIS-5 — Account Management | The story involves managing customer access lifecycle and risky fallback paths. |
| Recommendation — Review account and recovery processes to remove weak fallback access for sensitive customers. | ||
Key terms
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
- CIAM: Customer identity and access management is the identity layer that supports customer-facing applications. It covers onboarding, authentication, consent, and account recovery, and it is tightly coupled to user experience and commercial outcomes because failures in CIAM directly affect trust, conversion, and retention.
- Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
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.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org