Risk-based strong customer authentication is an authentication method that applies stronger checks when a login or transaction looks risky. It typically combines factors such as a password, possession factor or biometrics with signals like device, location or behaviour to decide when extra verification is needed.
What Risk-Based Strong Customer Authentication Means
Risk-based strong customer authentication is not a single factor or a fixed login flow. It is an adaptive approach that raises the level of proof required only when the transaction, device, location, or behaviour suggests elevated risk.
Its value is that it reduces friction for routine activity while tightening assurance when the context changes. In practice, that usually means combining something the user knows, has, or is, with signals that help judge whether the session or payment request looks normal.
Why It Matters in Customer Authentication
This model matters because customer sign-in and payment approval are not equal-risk events. A low-risk session on a familiar device may only need ordinary checks, while a new device, unusual geography, or suspicious velocity can justify step-up verification.
For organisations, the main benefit is better balance between fraud resistance and user experience. The main challenge is that the risk logic must be reliable enough to avoid creating blind spots or over-challenging legitimate users.
Common Risk Signals and Step-Up Logic
Risk-based decisions usually rely on a blend of signals rather than any single indicator. Device reputation, location anomaly, IP risk, behavioural deviation, transaction amount, payment context, and prior account history can all contribute to the decision to request additional verification.
The stronger the signal combination, the more likely the system should shift from ordinary sign-in to step-up authentication such as a push approval, passkey challenge, biometric prompt, or out-of-band confirmation. Good implementations keep the policy consistent enough to explain, test, and audit.
How It Differs from Static Authentication
Static authentication applies the same rule every time, which is simpler but easier for attackers to predict. Risk-based strong customer authentication adapts to context, so attackers cannot assume that one captured password, one stolen session, or one successful login will always be enough.
That adaptability is why this model is often paired with fraud detection, session monitoring, and transaction controls. The authentication decision becomes part of a broader trust evaluation rather than a one-time gate.
Risk and Threat Considerations
Risk-based strong customer authentication can fail if the risk engine is too permissive, too noisy, or too easy to game. Attackers often try to imitate normal behaviour, reuse trusted devices, or exploit weak fallback paths so the system stays below the step-up threshold.
Failure mechanism: If the signal set is weak or poorly tuned, an attacker may keep a stolen credential, session, or payment flow within the “normal” band and bypass stronger checks. False negatives are especially dangerous when the organisation assumes adaptive authentication will compensate for weaker baseline controls.
Impact: The result can be account takeover, fraudulent payments, session abuse, or repeated challenge fatigue for legitimate users. When risk decisions are wrong at scale, the organisation can also lose trust in the control and overcorrect by making every transaction harder than necessary.
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, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authenticator Assurance Levels | Defines assurance levels that step-up authentication can target based on risk. |
| Recommendation — Map higher-risk transactions to the required assurance level and verify the authenticator meets it. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers strong authentication requirements for users accessing protected services. |
| Recommendation — Require stronger user authentication when contextual risk indicates a higher assurance need. | ||
| OWASP ASVS | V6 — Authentication | Specifies authentication requirements, including adaptive and stronger verification patterns. |
| Recommendation — Validate that authentication logic enforces step-up checks when risk signals exceed policy thresholds. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports access decisions that vary by risk and business need. |
| Recommendation — Define access rules that escalate verification when the context indicates elevated risk. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Addresses practical control of access paths and authentication strength. |
| Recommendation — Restrict access paths so higher-risk events require stronger authentication before completion. | ||
Practitioner Guidance
Why practitioners should care: The control only works when policy, telemetry, and fallback paths are designed together. If step-up is easy to bypass, easy to trigger unnecessarily, or inconsistent across channels, the user experience and the security outcome both suffer.
What to watch for: Pay close attention to backup authentication routes, recovery flows, and exceptions for high-friction users or devices. Those paths often become the easiest place for attackers to bypass the intended risk decision.
Practitioner takeaway: Treat risk-based strong customer authentication as a decision system, not just an MFA feature, and test both the risk scoring and the exceptions as part of the control.
Related resources from NHI Mgmt Group
- Guide: Customer IAM (CIAM) Guide
- Why do customer identity platforms need risk-based authentication in multi-cloud environments?
- Why does weak identity verification increase risk for FIDO, certificate-based authentication, and other strong credentials?
- When does Strong Customer Authentication create more revenue risk than fraud protection value?
- What happens when customer identity is not integrated with risk-based authentication and privacy controls?