Use adaptive authentication to reserve friction for high-risk moments instead of every login. Combine device intelligence, behavioural signals, and real-time risk scoring so the platform can step up only when the session looks unusual. The goal is selective friction, where assurance rises as risk rises, not a blanket challenge model.
Why This Matters for Security Teams
account takeover is not just a login problem. For CIAM teams, the real issue is how to raise assurance without turning every customer journey into a challenge flow that drives abandonment. Adaptive authentication is meant to separate routine sign-ins from suspicious ones, but it only works when risk signals are calibrated, explainable, and tied to the actual customer context rather than a generic fraud score.
The operational stakes are high because attackers often probe the same controls that frustrate legitimate users: password resets, device changes, session reuse, and recovery paths. When those controls are too loose, takeover succeeds. When they are too aggressive, support queues grow and conversions fall. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which is a reminder that identity compromise often starts before the customer notices anything unusual. Meta AI Instagram Account Takeover shows how support and recovery paths can become the weakest link when challenge logic is inconsistent.
In practice, many security teams discover that they overchallenged good customers for months before they ever saw the fraud they were trying to prevent.
How It Works in Practice
The most effective pattern is selective friction. The platform should allow low-risk sessions to proceed normally, then step up only when behaviour deviates from the customer’s usual patterns. That usually means combining device intelligence, IP reputation, geovelocity, session history, behavioural biometrics, and real-time velocity checks into a single decision at the moment access is requested.
Best practice is evolving, but current guidance suggests that risk scoring should be event-driven rather than login-only. A customer who signs in from a recognised device may still trigger step-up if they suddenly change password reset settings, add a new payout method, or attempt recovery from an unusual geography. This is where real-time policy decisions matter more than static rules. NIST SP 800-53 Rev 5 Security and Privacy Controls supports continuous monitoring and access enforcement patterns that map well to adaptive authentication, while the NHIMG research on The 2024 Non-Human Identity Security Report shows 59.8% of organisations want dynamic ephemeral credentials, reinforcing the broader shift toward context-sensitive control.
- Use a risk engine that can score each transaction, not just the login event.
- Reserve MFA, proofing, or recovery step-up for high-risk actions, not every sign-in.
- Separate authentication risk from account recovery risk, because attackers often target recovery first.
- Continuously tune thresholds against false positives, help-desk volume, and fraud loss.
The control breaks down most often in high-volume retail, travel, and subscription environments where legitimate context changes frequently and weak telemetry makes risk scoring noisy.
Common Variations and Edge Cases
Tighter step-up controls often increase abandonment and support cost, so organisations have to balance fraud reduction against customer effort. That tradeoff becomes sharper in environments with shared devices, mobile networks, family accounts, or customers who routinely switch locations. In those cases, a simple “new device equals challenge” rule creates unnecessary friction and trains users to distrust the security flow.
There is no universal standard for this yet, but current guidance suggests using step-up only when the risk delta is meaningful. For example, a customer on a known device who requests a new payout destination may warrant stronger verification than a first-time user on a new phone completing a routine purchase. The important distinction is between identity proofing, session trust, and transaction trust. Treating them as the same thing leads to both false positives and false negatives.
For teams looking to harden decisioning without overchallenging, the practical lesson is to map friction to business impact. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for risk-based, monitored controls rather than one-size-fits-all enforcement. In mature CIAM programs, the hardest cases are usually not obvious fraud attempts but legitimate sessions that look slightly unusual and therefore get treated like attacks.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Adaptive authentication depends on verifying identity based on context and risk. |
| NIST SP 800-53 Rev 5 | IA-2 | Covers identification and authentication for users and supports step-up controls. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential misuse and weak rotation patterns often underpin account takeover paths. |
| NIST AI RMF | Risk-based decisioning needs measurable governance and monitoring of model-driven scoring. | |
| NIST Zero Trust (SP 800-207) | AC-3 | Selective friction aligns with least-privilege, context-aware access enforcement. |
Apply strong, risk-based authentication only when session risk justifies added friction.
Related resources from NHI Mgmt Group
- How should financial institutions reduce account takeover risk without blocking legitimate customers?
- How should marketplace teams reduce account takeover without overblocking legitimate users?
- How should government teams reduce resident account takeover without adding too much login friction?
- How should IAM teams reduce account takeover risk without relying on passwords?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org