How do security teams know whether added authentication controls are creating too much friction?

How teams tell whether the added control is actually worth the friction

authentication friction becomes a governance problem when security measures start changing user behaviour instead of just strengthening assurance. The practical question is not whether the control is “secure,” but whether it preserves completion for legitimate users while still raising the effort, cost, or uncertainty for abuse. Teams usually learn this by comparing abandonment, retries, help-desk contact, and step-level conversion before and after the control goes live.

That matters because friction can be invisible in approval meetings and obvious only in production, where a well-meant step adds delay at the exact moment users need to finish a task. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames authentication, monitoring, and access control as measurable safeguards rather than abstract policy language, while the NHIMG Ultimate Guide to NHIs — Standards shows how poorly governed authentication patterns often fail when they are not tied to lifecycle and visibility discipline. In practice, teams often discover that a “stronger” step is really just a higher-friction step after users have already found workarounds.

What good measurement looks like in production

Useful measurement starts with a baseline. Teams should know the normal rate of successful sign-in or transaction completion, the number of attempts per completed journey, where users pause, and how often people abandon the flow after a challenge appears. If a new control is introduced, compare the same journey segments before and after rollout, and separate first-time user behaviour from returning-user behaviour because those groups react very differently.

It also helps to look at the nature of the friction, not only the volume. A control may be acceptable if it adds one predictable extra step but becomes a problem if it creates repeated retries, timeout failures, or inconsistent prompts across devices. That is where user frustration and security bypass habits begin. Strong measurement usually combines product analytics with identity telemetry, support tickets, and exception requests so that teams can see both the user journey and the operational cost of the control.

For mature programmes, the right question is often whether the control changes risk in the intended direction. A control that sharply lowers completion but does not reduce suspicious activity, risky access patterns, or account abuse is probably misaligned. Teams can use NIST SP 800-53 Rev 5 Security and Privacy Controls as a reference point for thinking about measurable access control outcomes, and the NHIMG research on NHI visibility and rotation gaps is a reminder that authentication friction is often a symptom of deeper governance problems rather than a standalone user-experience issue. The ISO/IEC 27001:2022 Information Security Management standard is also relevant when teams need a management-system view of whether control changes remain proportionate to the risk they address.

These controls tend to break down when they are measured only at login rather than across the full transaction path, because the real cost appears later in abandonment, exception handling, and shadow workarounds.

Where friction becomes a signal of a bad control design

Tighter authentication often improves assurance but increases operational cost, so teams have to balance resistance to abuse against user completion and support load. The key trade-off is not “more prompts versus less prompts”; it is whether the control is proportional to the sensitivity of the action and the likelihood of misuse.

Current guidance suggests treating repeated friction as a design signal when it clusters around specific moments: device changes, step-up challenges that arrive too late, poorly timed reauthentication, or prompts that users cannot understand. In those cases, the issue may be timing, clarity, or policy logic rather than the underlying authentication strength. Teams should also watch for compensating behaviours such as users switching browsers, relying on shared accounts, or escalating to manual approval just to avoid the control.

Decision rule: if the control creates materially higher abandonment without a visible drop in risky access or suspicious activity, it is probably adding friction faster than it is reducing exposure. Decision rule: if the same control is tolerated for high-risk actions but rejected for routine ones, scope it more narrowly instead of applying it uniformly.

Practitioner takeaway: The best friction metric is not whether users complain, but whether the control is forcing predictable, risk-based behaviour without pushing legitimate users toward unsafe workarounds.

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 just-in-time access without creating too much friction?
• How should fintech teams embed fraud controls without creating too much customer friction?