Look for repeated abandonment during login or verification, rising help-desk contacts, account recovery misuse, and workarounds such as shared access or excessive resets. Those patterns indicate that assurance is not translating into usable trust, even if the underlying policy is technically sound.
What User Rejection Looks Like Before It Becomes a Control Failure
When identity controls are too difficult to accept, the first signal is usually behavioural rather than technical. Users stop completing challenges reliably, avoid enrolment steps, or route around the process with informal shortcuts that preserve speed but weaken assurance. That matters because identity control only works when people can complete it repeatedly under real operating conditions, not just in a policy document.
For identity teams, the practical question is whether friction is creating compensating behaviour that the organisation cannot see from control design alone. A control can look strong on paper and still fail in practice if it drives abandonment, bypass, or excessive exception handling. The issue is not simply inconvenience. It is that low acceptance changes the security posture by pushing users toward weaker access patterns and more manual recovery paths. In practice, many security teams discover this only after abandonment and workarounds have already become normal operating behaviour.
For a control baseline perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it frames identity-related controls as part of an operating system of governance and enforcement, not a one-time deployment decision.
How Friction Turns Into Bypass, Exceptions, and Weak Trust
Acceptance problems usually emerge where a control asks users to do too much, too often, or in a way that conflicts with their task flow. Common examples include repeated prompts, confusing recovery journeys, device constraints that break legitimate work, and step-up checks that appear unrelated to the risk being managed. Once users experience those barriers as routine, they adapt by seeking the fastest available path, not the safest one.
- High repetition makes a control feel punitive, especially when the same person is challenged multiple times in a short period.
- Recovery paths become a pressure point when users see them as easier than the primary login path.
- Manager or service-desk exceptions can quietly become the preferred route if the normal control is slow or unreliable.
- Shadow practices, such as shared access or delegated approval without proper identity binding, often appear when the control is misaligned with the business process.
What matters operationally is not just whether the control is secure, but whether it is consistently usable for the people, devices, and situations it was designed to cover. Teams should look at completion rates, retry patterns, recovery volume, and the volume of manual exceptions together, because any single metric can hide the real failure mode. If a control is accepted only by the most compliant users or only in low-pressure scenarios, it is not resilient enough for enterprise use. That guidance breaks down when the user population is highly variable and the control is applied without segmenting by role, risk, or access context.
Where the Usability Threshold Changes Across Identity Journeys
Tighter identity assurance often increases user effort, so organisations have to balance stronger verification against the operational cost of rejection and workarounds.
Not every identity control fails for the same reason. Some controls are rejected because they are slow, while others fail because they are hard to understand, fail unpredictably, or do not match the user’s actual working context. This is why broad consensus only goes so far: there is no single friction threshold that works for every workforce, customer base, or privileged access scenario. A step that is acceptable for a small admin group may be excessive for a large internal population, and a consumer-facing journey may need a different tolerance again.
The key edge case is when resistance is not visible as outright refusal. Users may appear compliant while relying on fallback methods, cached sessions, alternate devices, or help-desk mediated resets that weaken the intended assurance. In those cases, the control is not being rejected in public, but it is being replaced in practice. That distinction matters because acceptance issues often surface first in the recovery and exception channels rather than in the primary login flow. The strongest indicator is not whether a control exists, but whether users can complete it without creating a second, weaker system beside it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | User acceptance directly affects whether access control works as intended. |
| PR.PT — Protective Technology | Controls that rely on protective enforcement must still fit real operating conditions. | |
| DE.CM — Security Continuous Monitoring | Abandonment and recovery misuse are observable signals that need monitoring. | |
| Recommendation — Measure abandonment and fallback use to confirm access control remains usable. Validate that protective technology does not force unsafe compensating behaviour. Track abandonment and recovery patterns as indicators of control breakdown. | ||
| CIS Controls v8 | 6 — Access Control Management | Hard-to-accept identity controls often drive exceptions and shared-access workarounds. |
| Recommendation — Review access exceptions and recovery paths to reduce bypass-driven exposure. | ||
| NIST SP 800-63 | AAL — Authenticator Assurance Level | Friction is central when assurance expectations exceed what users can sustain. |
| Recommendation — Align assurance level to the user journey so verification remains usable. | ||
Practitioner Guidance
What to prioritise: Treat abandonment, recovery volume, and exception requests as design feedback, not just support noise. If those signals rise together, the control is likely asking for more effort than the user population will sustain.
What to verify: Check whether the control is failing in the primary journey or being displaced into fallback paths. A control can look successful if completion is measured only after the user has already switched to a weaker route.
Common mistake: Increasing strictness to compensate for poor acceptance usually worsens the behaviour problem. Teams often make the journey harder instead of making the control easier to complete correctly.
Practitioner takeaway: The real test of an identity control is whether people can use it at normal speed, under normal pressure, without creating a shadow recovery process or an informal bypass.
Related resources from NHI Mgmt Group
- What signals show that healthcare identity controls are becoming too restrictive?
- How should security teams improve compliance and budget outcomes without making identity controls too rigid for users to work around?
- What are the signs that identity controls in an app are too weak for security teams to rely on?
- What are the signs that identity verification is too cumbersome for legitimate users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
