How should security teams implement stronger authentication without creating more user friction?

How to strengthen authentication without making every login feel harder

The practical move is to separate authentication strength from authentication frequency. Use stronger methods where the blast radius is highest, then make ordinary sign-ins quiet and predictable. That means fewer prompts for low-risk access, more demanding checks for sensitive actions, and tighter rules for recovery, privilege changes and unusual access conditions.

Good rollout starts with an access-policy view, not a login-page view. Not every user, device or action needs the same assurance level, so security teams should map which accounts deserve phishing-resistant sign-in, which workflows can use risk-based step-up, and which recovery paths need extra scrutiny. Workforce Identity Security Guide is useful here because it ties phishing-resistant methods, step-up authentication and account recovery into one operating model.

The strongest implementations also reduce user friction by removing unnecessary repetition, not by weakening the control. SSO, federation and remembered device signals can cut prompt volume for routine work, while authentication context can be raised only when the action or location changes the risk. OAuth Step-Up Authentication Challenge Guide covers the protocol pattern for asking for higher assurance only when a transaction really needs it.

Where friction usually drops and where it should not

Users tolerate stronger authentication best when it is consistent and explainable. Common access should stay low-friction because it is familiar and low impact, but sensitive actions should feel different on purpose. That separation matters for password resets, privilege elevation, enrollment changes, recovery flows and logins from unfamiliar networks or devices. MFA Guide is a useful reference for choosing methods that resist phishing and for understanding where weaker methods fail.

Phishing-resistant methods are most valuable for the users and roles that would cause outsized damage if compromised, such as administrators, finance approvers, help desk operators and other high-impact accounts. For the rest of the workforce, the real design question is whether the policy can distinguish routine access from risky access without turning every sign-in into a challenge loop. Passwordless and Passkeys Guide gives a practical path for using passkeys and FIDO2 where the strongest protection is justified.

Recovery is often the hidden friction point. If password reset or MFA reset is too easy, users experience convenience while attackers experience a shortcut. If it is too hard, the service desk becomes the bottleneck and users look for workarounds. The balance is to make recovery explicit, well logged and more careful than normal sign-in, while keeping day-to-day access simple. MFA Guide and Workforce Identity Security Guide both reinforce that recovery design is part of the authentication decision, not a separate admin task.

Designing policies that protect high-risk actions without over-challenging everyone

Risk-based authentication works best when the policy engine is narrow and defensible. The trigger should be a real increase in risk, not a vague sense that "something looks different". Unusual location, device change, impossible travel, privilege change, recovery flow and access to sensitive systems are the kinds of events that justify step-up because they change the trust level of the action itself.

Teams should also avoid treating "more prompts" as a security win. If users get challenged too often, they will either abandon the flow or normalize the prompts, which reduces the value of the control. Stronger authentication should be paired with fewer, better-timed prompts and with clear transaction boundaries so users understand why they are being challenged.

That is why step-up for sensitive actions is more effective than step-up for every login. When the control is applied only at privilege changes, recovery, data release, configuration change or other high-impact moments, it protects the places where compromise matters most and keeps the routine path fast.

Risk and Threat Considerations

Authentication controls fail when security teams add friction in the wrong place. If every login is challenged, users become frustrated and the business starts bypassing the control; if recovery and privilege changes stay too easy, attackers go after the paths that still have weak assurance. The real danger is not just weaker sign-in, but a control that trains users to ignore prompts while leaving the highest-value actions under-protected.

Failure mechanism: Excessive prompts, weak recovery checks and broad MFA exceptions create predictable abuse paths for phishing, MFA fatigue, session theft and help desk social engineering.

Impact: Attackers can preserve access long enough to change settings, escalate privileges, reset credentials or pivot into sensitive systems while ordinary users experience the control as routine noise.

Practitioner Guidance

What to prioritise: Protect high-impact users and high-impact actions first. If a role can approve payments, administer infrastructure or reset access for others, it should receive stronger sign-in and tighter recovery handling before the rest of the population.

Decision rule: If an action changes privilege, recovery state or access to sensitive data, require a stronger check for that action even when the original login was already successful. If the action is routine and low-impact, keep the path quiet.

What to verify: Confirm that the policy distinguishes sign-in risk from transaction risk, that recovery flows are not weaker than login, and that exception handling is auditable rather than informal.

Practitioner takeaway: The best user experience is not fewer controls, it is fewer unnecessary interruptions, with the strongest checks reserved for the moments that actually expand attacker opportunity.

Related resources from NHI Mgmt Group

• How should security teams implement context-aware authentication without creating too much user friction?
• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams implement SaaS DLP without creating too much user friction?
• How should organisations implement two-factor authentication in high-risk digital services without creating unnecessary user friction?