How can IAM teams make authentication stronger without adding too much friction?

Use adaptive authentication so low-risk sessions stay simple while higher-risk logins trigger stronger proof. Combine trusted devices, phishing-resistant factors, and clear recovery paths to avoid repeated unnecessary challenges. The goal is not more prompts, but better assurance per prompt.

Why This Matters for Security Teams

Strong authentication is only useful if people can still complete their work. When every sign-in demands the same proof, security teams create alert fatigue, help desk tickets, and workarounds that weaken assurance over time. Current guidance from NIST Cybersecurity Framework 2.0 supports risk-based access decisions, which is why adaptive authentication has become the practical middle path between strict control and usable access.

The real issue is not adding more prompts, but choosing the right prompt at the right moment. A low-risk session on a trusted device may only need a normal factor, while a new location, unusual device posture, or sensitive action should trigger stronger proof. That pattern is especially important in environments where authentication is used to protect secrets, admin portals, and workload control planes. NHIMG research shows that many organisations still rely on weak or inconsistent identity practices, and that gap makes friction more likely to become a business problem rather than a security win. See Ultimate Guide to NHIs for the broader identity and lifecycle context.

In practice, many security teams discover that repeated login prompts are not improving assurance, only increasing user resistance after the first wave of friction has already been normalised.

How It Works in Practice

Adaptive authentication works by evaluating context at sign-in and step-up moments, then deciding how much proof is needed. That usually includes device trust, geolocation, session age, IP reputation, privilege level, and the sensitivity of the action being requested. The objective is to make the default path easy for low-risk activity while reserving stronger checks for higher-risk situations.

Most mature programmes combine three layers:

• Trusted device signals, so a known and healthy endpoint can move through low-risk flows with less interruption.
• Phishing-resistant factors such as FIDO2 or hardware-backed passkeys for high-value access and recovery paths.
• Session and transaction risk scoring, so a fresh device, impossible travel event, or admin action can trigger step-up authentication.

For teams looking at identity architecture, this is where NIST Cybersecurity Framework 2.0 aligns with operational practice: identify the critical assets, protect them with stronger assurance, and detect anomalies that justify additional verification. NHIMG guidance also shows why this matters when identity sprawl is high and secrets are widely exposed, as discussed in Azure Key Vault privilege escalation exposure. In that kind of environment, authentication strength has to work alongside secrets governance, not in place of it.

Clear recovery paths matter just as much as the primary login flow. If recovery is harder than daily use, people route around controls. Best practice is evolving, but most guidance suggests using separate recovery assurance, short-lived fallback access, and auditable admin approval for account re-establishment.

These controls tend to break down in highly distributed environments where unmanaged devices, contractor access, and legacy applications cannot reliably consume modern risk signals.

Common Variations and Edge Cases

Tighter authentication often increases operational overhead, requiring organisations to balance stronger assurance against support load and user frustration. That tradeoff becomes most visible in hybrid workforces, shared workstations, and regulated business units where one policy does not fit every access path.

There is no universal standard for adaptive thresholds yet. Some organisations use static rules for known high-risk actions, while others use continuous signals and policy engines to decide in real time. The better approach depends on how much identity telemetry is available, how mature the device posture programme is, and whether users can tolerate occasional step-up challenges without falling back to insecure habits.

A few common edge cases deserve attention:

• Privileged users should face stronger controls than standard users, even when they are on trusted devices.
• Break-glass accounts need separate treatment because they are meant for exceptional access, not routine convenience.
• Third-party users often require stricter sign-in policy because their device and network posture is harder to validate.
• Service accounts and other non-human identities should not be forced into human MFA patterns; they need workload-specific assurance and secret handling instead.

For teams building a stronger but less painful programme, the practical goal is to reduce unnecessary prompts while increasing the quality of each decision. That is the same security logic that appears throughout NHI governance, especially where standing access and long-lived credentials create hidden risk. Current guidance from Ultimate Guide to NHIs reinforces that identity assurance has to be paired with lifecycle controls, not treated as a one-time login problem.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams secure hybrid and remote work without adding too much user friction?
• How should security teams implement context-aware authentication without creating too much user friction?
• How should teams detect free trial abuse without adding too much friction?