Strong authentication regulations are shifting digital banking and workforce IAM

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: Strong authentication requirements are converging across digital banking and workforce access, with multiple authorities moving away from SMS OTP and other weak methods.

Why it matters: IAM teams now need to treat authentication policy as a multi-regime governance issue spanning customer banking journeys, workforce MFA, device posture, and fraud resistance.

Context

Strong authentication is no longer being framed as a single banking control. In this article, the core issue is how regulators are redefining acceptable authentication across consumer banking and workforce access, with implications for IAM programmes that still depend on SMS OTP, static passwords, or weak second factors.

The governance gap is straightforward: different regulators are converging on stronger, more phishing-resistant methods, but they are doing so through different rules, deadlines and use cases. That means security and identity teams have to align policy, factor selection and device trust decisions across both customer and employee populations.

Key questions

Q: What should security teams do first when weak authentication is still allowed for high-risk access?

A: Start by inventorying every customer and workforce flow that still relies on SMS OTP, email OTP or static passwords alone. Then rank those flows by fraud exposure, privileged access and remote use, because those are the cases most likely to fail under phishing, interception or device compromise.

Q: Why do weak authentication methods create fraud risk in digital banking?

A: Weak methods create fraud risk because they authenticate a session without proving that the person, device, and transaction are still trustworthy. SMS OTP and static passwords can be stolen, forwarded, or abused in social-engineering attacks. Once attackers reach the session, they can alter beneficiaries, payment details, or account settings before the user realises it.

Q: What are the signs that an MFA programme is not strong enough for regulatory expectations?

A: Look for SMS OTP as the default second factor, shared methods across low- and high-risk flows, no device trust checks, and no separate policy for privileged access. If the same factor mix covers banking login, transaction approval and workforce VPN access, assurance is probably too flat.

Q: How should teams compare phishing-resistant MFA with OTP-based MFA?

A: Phishing-resistant MFA binds the credential to the legitimate site or device, while OTP-based MFA still allows code theft, relay and interception. The difference matters most where attackers can control the login surface, because a captured OTP can still authenticate a session that should have been blocked.

Technical breakdown

Why weak factors are being phased out

SMS OTP, email OTP and static passwords remain attractive because they are familiar and easy to deploy, but they are also easy to intercept, replay or socially engineer. The article shows regulators treating these factors as insufficient when used alone for sensitive banking operations and remote workforce access. The technical issue is not just factor count, but factor resilience under phishing, SIM swap, malware and device compromise. When the second factor can be redirected or stolen outside the user session, it stops providing meaningful assurance.

Practical implication: retire weak factors from sensitive flows and map each authentication use case to a resistance level, not just an MFA label.

How device trust changes authentication design

The Philippines guidance and the UAE notice both move authentication beyond shared secrets into device-aware controls. Device fingerprinting, app shielding and checks for rooted, jailbroken or emulated devices add a trust signal before authentication is accepted. This matters because authentication strength is now being judged in context: who is authenticating, from what device, for what action, and through which channel. In practice, identity assurance becomes a combination of factor quality and endpoint trust rather than a single login event.

Practical implication: treat device posture as part of authentication policy wherever mobile banking or privileged access is in scope.

Why phishing-resistant MFA is becoming the preferred baseline

ENISA's guidance under NIS2 places phishing-resistant MFA in the strongest category, reflecting a wider regulatory view that one-time codes and push approvals are not enough for high-value access. FIDO-based authentication changes the threat model because the credential is bound to the domain and not easily reused on a fake site. That does not remove the need for identity governance, but it does reduce the likelihood that a successful phishing page or intercepted OTP becomes an account takeover.

Practical implication: use phishing-resistant MFA for remote workforce access and privileged accounts where the access path itself is a primary attack surface.

Threat narrative

Attacker objective: The objective is to obtain authenticated access that weak factors cannot reliably distinguish from a legitimate user, then use that access for fraud or privileged activity.

1. Entry starts with phishing, OTP interception, device compromise or abuse of a weak factor such as SMS or email codes.
2. Credential access occurs when the attacker captures a reusable second factor, exploits intercepted authentication, or bypasses weak verification on an untrusted device.
3. Escalation follows when the attacker uses the authenticated session to approve transactions, access privileged accounts, or operate inside mobile banking flows.
4. Impact is fraud, unauthorized account access, or compromise of sensitive workforce and banking operations that should have been gated by stronger assurance.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

Authentication governance is becoming a cross-domain identity control, not a banking-only control. The article ties together customer banking, workforce access and privileged access under one policy shift. That matters because IAM teams can no longer keep consumer authentication and enterprise MFA in separate governance silos. The practical conclusion is that factor policy, device trust and assurance levels need one operating model across user types.

Phishing-resistant MFA is now the most defensible baseline for high-risk access. ENISA’s strongest category, based on FIDO standards, reflects a control reality that security teams have been converging on for years: reusable one-time codes are not resilient enough for high-value sessions. This does not make weaker methods useless everywhere, but it does make them hard to justify for remote access and privileged workflows. The implication is that assurance tiers should be explicit, not implicit.

Strong authentication policy is increasingly a fraud-control decision as much as an access-control decision. The UAE and Philippines guidance links authentication quality to fraud detection, device checks and transaction confirmation, which means identity teams have to coordinate with fraud and risk functions. That widens the governance surface from login to session, transaction and device context. Practitioners should expect authentication strategy to be measured against fraud reduction, not just login success rates.

Device-aware controls are becoming part of the authentication boundary. The article shows regulators moving away from factors alone and toward contextual trust signals such as device fingerprinting and app shielding. That shift changes how identity assurance is established, because the credential is no longer the only control point. For IAM and security architects, the governance implication is that device integrity must be treated as part of the authentication policy stack, not as an optional add-on.

Strong authentication is being pulled into regulatory convergence across regions. PSR, UAE banking guidance, Philippine banking rules and NIS2-related guidance all point in the same direction even if they arrive through different mechanisms. That convergence reduces ambiguity for practitioners: the market is moving toward fewer weak factors, more phishing resistance and more context-aware controls. Teams should assume that today’s acceptable method mix will narrow rather than expand.

What this signals

Authentication assurance is now a governance tiering problem. Teams should stop treating MFA as a single control and instead define assurance tiers for login, transaction approval, privileged access and remote work. That makes it easier to justify when phishing-resistant MFA is mandatory and when lower-assurance methods are still acceptable.

The shift also pulls device posture into IAM decisioning. If a bank or enterprise allows access from rooted, jailbroken or emulated devices without additional checks, the authentication control is already partially broken before the factor is even used.

Phishing-resistant methods are becoming the anchor control for high-risk access. For programmes that still rely on OTPs, the practical question is no longer whether MFA exists, but whether the chosen factor can survive phishing, interception and session replay.

For practitioners

• Define authentication tiers by risk level Map login, transaction approval, privileged access and workforce remote access to separate assurance requirements instead of one MFA policy.
• Remove SMS OTP from high-risk flows Phase out SMS OTP and email OTP for transaction signing, remote access and privileged operations where interception or replay is realistic.
• Adopt phishing-resistant MFA for privileged access Prioritise FIDO-based methods for admin, privileged and remote workforce sessions so the factor resists phishing and site replay.
• Add device trust checks before authentication Use device fingerprinting, app shielding and rooted or jailbroken device detection to reject weak or unmanaged endpoints.
• Coordinate identity and fraud policy Align authentication rules with fraud detection, transaction confirmation and anomaly analysis so access assurance and fraud controls use the same risk signals.

Key takeaways

• Regulators are tightening strong-authentication expectations across banking and workforce access, which makes weak factors increasingly hard to defend for sensitive use cases.
• The key pattern is convergence toward phishing-resistant MFA, device-aware controls and tighter transaction or privilege verification rather than standalone OTP-based assurance.
• IAM teams should align customer, workforce and privileged access policies now, because authentication governance is becoming a cross-regime control problem.

Key terms

• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Device fingerprint: A bundle of client signals used to recognise the same browser, app, or device across sessions. It often includes user agent, platform traits, and other stable characteristics. For impossible travel, fingerprinting helps separate a real attacker on a different device from a user switching networks.
• App Shielding: App shielding is a set of protective controls embedded directly into a mobile application so it can resist tampering, reverse engineering, debugging, and runtime analysis. It shifts part of the security decision-making into the app itself, helping preserve integrity when the device or execution environment cannot be fully trusted.
• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.

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.