Notifications
Clear all
Topic starter
20/08/2026 5:41 pm
TL;DR: Adaptive authentication reduces MFA fatigue by using real-time risk signals to decide when to step up verification, according to Ory. The control is useful, but it still depends on stable identity assumptions that break under modern credential abuse and unmanaged access patterns.
NHIMG editorial — based on content published by Ory: Security without the hassle: The power of adaptive authentication
Questions worth separating out
Q: How should security teams implement adaptive MFA for customer logins?
A: Start with a risk signal that is meaningful for the customer journey, such as phone reputation, device context, or transaction history.
Q: When does adaptive authentication fail to reduce account takeover risk?
A: It fails when attackers already control trusted devices, hijack legitimate sessions, or exploit weak downstream access after login.
Q: What should IAM teams measure to know if adaptive authentication is working?
A: Measure whether the control changes attacker success rates, not just whether users receive fewer prompts.
Practitioner guidance
- Tighten risk signal quality Review which signals actually predict abusive access in your environment, then remove low-value inputs that create noisy step-up prompts and policy drift.
- Map step-up to downstream privilege Trace what the authenticated session can reach after login, including admin consoles, delegated API actions, and linked service accounts, so the auth decision reflects real blast radius.
- Test for MFA fatigue abuse paths Simulate repeated prompt abuse, phishing-assisted approvals, and unusual-login bypass attempts to see whether the control still distinguishes benign from malicious sessions.
What's in the full article
Ory's full article covers the operational detail this post intentionally leaves for the source:
- Event-by-event examples of the login, registration, recovery, and settings-change hooks used to trigger step-up actions
- Concrete scenarios for when adaptive checks run before or after authentication events in Ory flows
- Implementation details on overriding default behaviour for password and OIDC authentication methods
- Examples of how location, device, and anomaly checks can be wired into event-driven authentication logic
👉 Read Ory's full guide to adaptive authentication and step-up verification →
Adaptive authentication for IAM teams: is step-up enough?
Explore further
20/08/2026 6:25 pm
Adaptive authentication is useful, but it is still a front-door control. The control decides whether a login deserves extra verification based on context, which makes it valuable against credential stuffing, phishing, and anomalous access. But the programme still has to assume that the authenticated session is the right boundary of trust. Practitioners should treat it as one control in the access decision chain, not as proof that the identity is safe for everything that follows.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which shows how quickly policy assumptions break down at the implementation layer.
A question worth separating out:
Q: When does adaptive authentication need to be paired with Zero Trust Architecture?
A: It should be paired with zero trust whenever access decisions need to reflect context continuously rather than once at login. Zero trust supplies the broader assumption that no request is trusted by default, while adaptive authentication provides the mechanism for varying the challenge level based on live signals. Together they are stronger than either control alone.
👉 Read our full editorial: Adaptive authentication exposes the limits of step-up-only IAM
