Adaptive authentication exposes the limits of step-up-only IAM

At a glance

What this is: This is a primer on adaptive authentication and how risk-based step-up checks can reduce friction while tightening login security.

Why it matters: It matters because IAM teams need controls that balance user experience with assurance, especially where human access, federated login, and downstream NHI sessions all depend on the same trust decision.

👉 Read Ory's full guide to adaptive authentication and step-up verification

Context

Adaptive authentication is a risk-based login control that asks for stronger verification only when context looks unusual. The governance gap is that many identity programmes still treat every login as if the same assurance level is always enough, even when device, location, behaviour, or network signals point to elevated risk. In IAM terms, this is about deciding when to trust the session, not just whether the password was correct.

For security and identity teams, the issue is broader than user convenience. Step-up flows can reduce MFA fatigue, but they also show how much modern access control depends on telemetry quality, policy tuning, and clear session boundaries across human IAM and connected non-human workflows.

Key questions

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. Then define explicit branches for allow, step-up, and block. The key is to tune the policy to reduce unnecessary friction while still interrupting suspicious sessions before account takeover or abuse can progress.

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. In those cases, the front-door decision is not enough. Teams need session controls, credential hygiene, and privilege governance to stop a successful authentication from becoming a wider compromise.

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. Useful indicators include step-up challenge outcomes, unusual-login block rates, fraud investigation rates, and the proportion of risky sign-ins that are stopped before session establishment.

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.

Technical breakdown

How adaptive authentication uses contextual risk signals

Adaptive authentication evaluates login context before deciding whether a session should proceed, step up, or be blocked. Typical signals include device reputation, geolocation, network trust, and behavioural patterns. The key technical point is that the control is policy-driven and event-based, not autonomous. It reacts to observed risk at authentication time, then triggers a stronger factor or denies access if the context crosses threshold.

Practical implication: tune risk thresholds from real login telemetry, not assumptions about what normal access looks like.

Why step-up authentication reduces MFA fatigue but does not remove trust assumptions

Step-up authentication improves usability by avoiding repeated prompts for low-risk logins. That benefit can also hide a structural weakness. If the underlying identity, device, or session model is weak, adaptive checks only reduce the chance of misuse at the front door. They do not fix reused credentials, stale sessions, or access paths that continue after authentication has already succeeded.

Practical implication: pair adaptive authentication with session controls, credential hygiene, and access governance instead of treating it as a standalone defence.

How zero trust architecture changes the role of adaptive authentication

Zero Trust Architecture treats authentication as one signal in an ongoing verification model, not a one-time event. Adaptive authentication fits this approach because it can increase friction when risk changes, but it still operates at the login layer. In practice, that means the control works best when connected to continuous authorisation, device posture, and downstream privilege management, especially where human access feeds automated service workflows.

Practical implication: anchor adaptive authentication inside a broader ZTA design rather than using it as a substitute for continuous verification.

NHI Mgmt Group analysis

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.

Step-up verification does not solve the lifecycle problem behind access risk. If credentials, devices, or sessions outlive the governance rules that created them, adaptive checks only slow down misuse at entry. The underlying issue is entitlement freshness, not prompt frequency. That means identity governance, session management, and privilege review still need to do the heavy lifting after authentication succeeds.

Contextual auth creates a sharper distinction between good user experience and good assurance. Reducing friction is not the same thing as reducing risk. Teams that optimise only for fewer MFA prompts can quietly weaken their own confidence in the signal, especially if risk models are tuned to avoid user complaints. The right benchmark is whether the control materially changes attacker success rates, not whether users notice it less.

Adaptive authentication becomes more important when human IAM feeds non-human access paths. A successful human login often becomes the launch point for API use, admin actions, or delegated service activity. That means the authentication decision has downstream identity consequences beyond the user session itself. Security teams should assess where a human session can unlock machine or administrative access, because that is where the blast radius expands.

From our research:

• 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.
• That is why identity teams should also review the State of Secrets in AppSec for the operational gap between confidence, developer behaviour, and actual remediation speed.

What this signals

Adaptive authentication should be treated as a session-entry control, not a universal trust verdict. The more identity programmes rely on contextual login risk, the more they need to understand where authentication ends and authorisation begins. In practice, that means tying step-up logic to session limits, downstream privilege checks, and event review paths across IAM and PAM.

The programme risk is not just poor login quality. It is overconfidence in the control itself. When risk-based auth is tuned mainly to reduce user friction, it can stop being a meaningful security signal and start becoming a compliance checkbox.

For teams building a broader identity roadmap, the useful next question is where adaptive auth sits alongside passwordless, device trust, and Zero Trust policy. Those controls should reinforce each other, not compete for the same trust decision.

For practitioners

• 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.
• Align adaptive auth with Zero Trust policy Use adaptive authentication as one input into continuous verification, then reinforce it with session limits, device posture, and privilege checks under a Zero Trust Architecture model.

Key takeaways

• Adaptive authentication improves login assurance by using context to decide when extra verification is needed.
• The control reduces friction, but it does not remove the need for lifecycle, session, and privilege governance after authentication succeeds.
• IAM teams should measure whether the control changes attacker outcomes, not just whether it reduces MFA prompts.

Key terms

• Adaptive Authentication: Adaptive authentication changes the strength of login checks based on context such as device, location, source network, and session history. It helps IAM teams respond to suspicious access without forcing every user through the same high-friction path.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
• MFA Fatigue: MFA fatigue is the behavioural pressure created when repeated login prompts make a person more likely to approve access without checking carefully. It is a control failure in the authentication experience, and it becomes dangerous when the approved session carries broad privilege or long-lived access.
• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

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

👉 Ory's full post covers the hook-based implementation details and event triggers behind adaptive authentication.

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.