What are the signs that identity controls are creating too much friction for legitimate users?

Why Identity Friction Becomes a Security Signal

Identity controls are supposed to reduce unauthorised access without blocking legitimate work, so friction is itself a signal that the control design may be out of balance. When users repeatedly fail enrolment, MFA, password reset, step-up authentication, or recovery flows, the issue is not just convenience. It can indicate poor policy fit, weak user journeys, overbroad risk scoring, brittle device checks, or controls that are stricter than the business process can tolerate.

For security teams, the key question is whether the control is improving assurance or simply shifting effort into support, workarounds, and abandonment. That distinction matters because frustrated users often create shadow processes, store access details insecurely, or seek exceptions that weaken the policy over time. The strongest programmes measure both protective effect and operational cost, rather than assuming more challenge always means better security.

Ultimate Guide to NHIs provides useful practitioner context on how identity governance, lifecycle control, and visibility affect whether access controls are sustainable at scale.

How Friction Shows Up in Real Workflows

Too much friction usually appears first in routine journeys, not in obvious security incidents. Users begin failing at the same step, repeating authentications, or avoiding protected pathways altogether. In customer-facing environments, this shows up as abandoned sign-ins, failed checkout or onboarding flows, and rising contact-centre volume. In workforce environments, it can appear as more password resets, more override requests, and more tickets asking for exceptions to standard access steps.

The practical issue is that identity controls often operate as layered decisions: enrolment, device trust, session risk, factor challenge, recovery, and re-authentication. If any one layer is too strict or poorly tuned, the whole journey feels broken. Current guidance suggests separating true fraud or compromise signals from ordinary user behaviour, because a control that treats common behaviour as suspicious will create unnecessary challenge and reduce completion rates.

Helpful diagnostics include looking at failure rates by step, time to complete an access journey, volume of approved exceptions, and the proportion of support cases tied to authentication or recovery. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference when teams want to map those outcomes back to control expectations rather than treating every user complaint as anecdotal.

• High retry counts at the same step usually point to policy or UX mismatch, not user negligence.
• Rising help-desk volume after an access change often means the control moved risk into support.
• Repeated exception approvals are a sign the standard flow is no longer operationally credible.

At scale, these issues become more serious because small mis-tunings multiply across many users, devices, and applications, and the control begins to shape behaviour instead of governing it. These controls tend to break down when the same authentication path is used for both low-risk routine access and high-risk privileged actions, because the policy cannot distinguish normal work from meaningful exposure.

When Security Meets Usability Limits

Tighter identity controls often increase user effort, so organisations have to balance assurance against completion. That tradeoff is especially visible in systems that serve both employees and external customers, where the tolerance for challenge is very different. Best practice is evolving, but the general direction is clear: step-up controls should be reserved for meaningful risk changes, while routine access should stay predictable and fast.

There is also a difference between friction that is acceptable and friction that is destabilising. A small amount of challenge can be justified if it protects privileged access or sensitive transactions. But if the same control triggers too often, users stop trusting it, support teams absorb the workload, and business owners begin asking for bypasses. That is usually the point where the control is no longer operating as intended, even if it looks strong on paper.

Practitioners should also be wary of using one metric in isolation. A lower fraud rate does not automatically mean the experience is healthy, and a smoother journey does not prove the control is too weak. The right interpretation comes from pairing security outcomes with operational signals and watching for patterns that show the control is causing avoidable failure rather than meaningful resistance.

Practitioner Guidance

What to prioritise: Start with the steps that create the most user-visible failure, especially authentication, recovery, and step-up prompts. If those steps account for most abandonment or ticket volume, tune them before you widen policy or add more challenge.

What to verify: Check whether the failures are concentrated in a specific user group, application, device type, or journey stage. Concentrated failure usually points to an avoidable policy mismatch, while broad failure suggests the control is misaligned with normal operating conditions.

Decision rule: If a control is reducing completion more than it is reducing meaningful risk, treat it as a design problem rather than a discipline problem. The usual fix is not to remove assurance entirely, but to make it conditional, shorter-lived, or better targeted.

Practitioner takeaway: The best identity controls are not the harshest ones; they are the ones users can complete reliably while still forcing genuinely risky actions through a higher-friction path.

Related resources from NHI Mgmt Group

• How should businesses build transaction monitoring programs that reduce fraud without creating too much friction for legitimate users?
• What are the signs that security controls are creating too much user friction?
• What are the signs that workload identity controls are too weak for modern automation?
• How should consumer applications implement zero trust step-up authentication without creating too much friction for legitimate users?