What do security teams get wrong about adaptive authentication?

Why This Matters for Security Teams

adaptive authentication is often described as a way to increase friction only when risk rises, but that framing misses the operational point. It is a decision engine, not a dashboard. When organisations rely on scores without binding them to allow, challenge, step-up, or block actions, they create visibility without enforcement. That gap is especially dangerous when credentials are reused, stolen, or replayed across sessions, as seen in incidents such as Microsoft Midnight Blizzard breach and Salt Typhoon US telecoms breach. The control only works when risk signals influence live access decisions across the journey, not after the fact.

Security teams also get the trust boundary wrong. They assume adaptive authentication is mainly about human logins, when in practice it must account for session context, device posture, location, velocity, impossible travel, and privilege sensitivity. That is why current guidance from the NIST Cybersecurity Framework 2.0 emphasizes risk-based protection outcomes rather than static checkpoints. In NHI-heavy environments, the same principle applies to service access and API-driven workflows. In practice, many security teams discover adaptive authentication failures only after a suspicious session has already been allowed to persist.

How It Works in Practice

Effective adaptive authentication starts with defining the decision points. A risk score should trigger a specific action, such as requiring step-up authentication, reducing session scope, issuing a shorter-lived token, or blocking the request entirely. The policy needs to be explicit enough that operators can explain why a decision happened and what changed the outcome. For identity teams, that means separating telemetry collection from enforcement and ensuring both are tied into the same policy workflow.

In mature programmes, the control plane considers several inputs together:

• User or workload identity confidence, including whether the session is known, new, or anomalous
• Device and endpoint posture, such as managed status, patch level, and local trust signals
• Request context, including geography, time, privilege level, and resource sensitivity
• Behavioural drift, such as velocity anomalies, repeated failures, or unusual privilege escalation

This aligns with the NIST Cybersecurity Framework 2.0 emphasis on continuous risk management. For NHI governance, the same logic appears in the Ultimate Guide to NHIs, which underscores how excessive privilege and poor rotation amplify blast radius when a session is compromised. Adaptive authentication should therefore be paired with least privilege, short-lived credentials, and step-up requirements for sensitive actions, not just initial login events. When properly implemented, the system can make a real-time decision at each important boundary rather than trusting a single successful sign-in.

These controls tend to break down in environments with shared accounts, legacy VPN concentrators, or applications that cannot pass context reliably because the policy engine cannot distinguish normal from risky use at request time.

Common Variations and Edge Cases

Tighter adaptive authentication often increases user friction and operational overhead, requiring organisations to balance stronger assurance against support load and workflow disruption. That tradeoff becomes more visible in high-change environments where contractors, automation, and third-party access all converge on the same systems.

Best practice is evolving for service accounts and machine-to-machine traffic. Traditional adaptive checks built for humans do not translate cleanly to API calls, CI/CD pipelines, or scheduled jobs, because there may be no browser, no interactive user, and no stable device posture to score. In those cases, the control should shift from user-centric prompts to workload identity, short-lived tokens, and policy evaluated at runtime. Current guidance suggests treating any manual exception as temporary and auditable, not as a permanent bypass.

Another edge case is over-reliance on score thresholds. If the model is not calibrated and reviewed, teams can either create alert fatigue by challenging too often or miss real compromise by setting the threshold too high. The practical answer is to link adaptive authentication to a documented response matrix, test it against real attack scenarios, and review outcomes after every material identity incident. That is where the lesson from Salt Typhoon US telecoms breach matters most: once a valid session is abused, static trust assumptions fail quickly.

Related resources from NHI Mgmt Group

• What do security teams get wrong about token revocation and rotation?
• What do security teams get wrong about passwordless authentication and AI risk?
• What do security teams get wrong about passwordless authentication?
• What do security teams get wrong about passwordless authentication in regulated environments?