Treat compliance and experience as linked design goals, not competing outcomes. Use stronger factors for risky actions, not every login, and rely on contextual signals to avoid unnecessary prompts. That approach reduces friction while still improving resilience, auditability, and phishing resistance across regulated access paths.
Why This Matters for Security Teams
DORA pressure often turns authentication into a blunt instrument: more prompts, more step-up checks, and more user friction. That approach usually helps neither resilience nor customer trust. The better pattern is to reserve stronger authentication for higher-risk moments and to make the rest of the journey invisible unless risk changes. This is consistent with DORA — Digital Operational Resilience Act expectations around operational resilience, and with NIST SP 800-63 Digital Identity Guidelines, which support proportionate identity assurance rather than one-size-fits-all friction.
The security challenge is that customer experience degrades quickly when controls ignore context such as device reputation, transaction value, payee history, geo-location, and prior session confidence. The governance challenge is the opposite: if teams remove too much friction, they widen fraud and account takeover exposure. For financial institutions, the practical goal is not fewer controls, but smarter controls that are applied only when they materially reduce risk. That aligns with broader NIST Cybersecurity Framework 2.0 objectives around risk-based governance and continuous improvement. In practice, many security teams encounter avoidable customer abandonment only after a control has already been over-applied at scale, rather than through intentional service design.
How It Works in Practice
The operating model is to separate routine authentication from high-risk authorisation. A low-risk login can remain smooth if the session is backed by strong baseline assurance, while a money movement, beneficiary change, device enrolment, or profile recovery action triggers step-up authentication. That design reduces unnecessary interruptions without weakening the control plane. It also fits what NHIMG highlights in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs: identity assurance is most effective when it is linked to lifecycle context and policy, not treated as a single static event.
- Use risk-based step-up only for sensitive actions, not every session start.
- Combine device signals, behavioural patterns, session age, and transaction context before prompting.
- Prefer phishing-resistant methods for high-value actions, especially where social engineering risk is elevated.
- Keep audit trails that show why a challenge was triggered, so compliance teams can explain the decision later.
- Review false-positive prompts and user drop-off as operational metrics, not just security outcomes.
For institutions with customer-facing mobile apps, the best experience usually comes from invisible background risk scoring plus explicit step-up only when confidence drops. Current guidance suggests that passwordless or phishing-resistant methods can help, but there is no universal standard for exactly how much risk scoring should be delegated to the channel versus the central policy engine. The EU Digital Operational Resilience Act (DORA) and Top 10 NHI Issues both reinforce the point that controls fail when they are rigid, poorly scoped, or hard to monitor. These controls tend to break down when high-risk journeys reuse low-risk session trust because the policy engine cannot distinguish normal customer behaviour from account takeover patterns.
Common Variations and Edge Cases
Tighter authentication often increases customer friction and help-desk overhead, requiring organisations to balance fraud reduction against abandonment, support cost, and regulatory defensibility. That tradeoff is real, especially in retail banking, wealth platforms, and markets businesses where legitimate users may operate across multiple devices and locations.
One common edge case is when institutions overfit controls to one channel, such as mobile, and then create inconsistent journeys across web, contact centre, and branch-assisted recovery. Another is step-up overload during travel, VPN use, or high-frequency trading workflows, where legitimate behaviour looks unusual but is not malicious. Best practice is evolving here: some banks use adaptive policies with low-friction defaults, while others still rely on fixed rules because their fraud telemetry is too immature for confident runtime decisions.
NHIMG research shows why this matters operationally: if access control is too coarse, the organisation ends up protecting the wrong step while missing the actual risk path. Teams that want a deeper control perspective should also review the Zacks Investment Research breach alongside the NIST Cybersecurity Framework 2.0. The practical lesson is that the customer experience gets worse fastest when organisations use authentication as a blanket policy instead of a contextual control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | DORA drives resilience, auditability, and proportionate access control decisions. | |
| NIST SP 800-63 | Digital identity guidance supports proportionate assurance and phishing-resistant methods. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access fits context-aware authentication and authorisation. |
Align assurance levels to risk and use stronger authenticators only for sensitive actions.
