What are the signs that IAM automation is creating too much friction for end users?

Common signs include repeated password reset requests, frequent help desk tickets for entitlement changes, slow support resolution, and users trying to bypass formal IAM steps. In higher education, friction shows up quickly because students and faculty are often time sensitive and remote. If users avoid the process, the program may be technically sound but operationally failing where it matters most.

What friction looks like when IAM automation is overreaching

The clearest signal is not that automation exists, but that users start working around it. If routine access changes feel slow, opaque, or overly rigid, people will keep asking for manual exceptions, repeat the same requests, or avoid the formal path entirely. In practice, the system is then measuring control strength but missing user experience, which is often where adoption breaks first.

Friction becomes especially visible when the process is correct on paper but still too costly for the task at hand. A good automated flow should reduce waiting, reduce guesswork, and make the next step obvious. When it adds repeated prompts, inconsistent approvals, or unnecessary re-entry of information, it stops behaving like enablement and starts behaving like resistance.

Which operational signals usually show up first

The earliest warning signs are usually behavioural and support-driven. Repeated password reset requests, entitlement tickets that never seem to close cleanly, and users asking peers or managers to “just do it for me” all point to a process that is too hard to complete. Help desk volume matters here because it shows where automation is generating avoidable exception handling instead of removing it.

Another useful signal is time. When approval or provisioning latency becomes part of normal work, users stop treating the IAM process as a control and start treating it as a blocker. That is particularly visible in environments with remote or time-sensitive work, where delays are felt immediately and where people are more likely to seek shortcuts if the sanctioned path is slower than the task itself. NHIMG’s IAM and IGA Basics is useful background for separating the access request flow from the governance decision behind it.

Watch for requests that look technically valid but are repeatedly reworked because the workflow is hard to interpret, the roles are too coarse, or the business context is not captured well enough to route the request correctly. That pattern often indicates the automation is too generic for the operating model, not that users are inherently resistant.

How to tell usability problems from healthy control

The key question is whether the control is forcing the right decision or simply forcing extra effort. Good iam automation should make the secure action the easiest one to complete. If the control causes repeated resubmission, frequent manual overrides, or informal approvals outside the tool, the design has likely crossed from guardrail into friction.

This is where lifecycle and entitlement quality matter. When roles are poorly defined, access reviews are too broad, or the request model does not match how people actually work, automation can amplify confusion rather than reduce it. NHIMG’s NHI Lifecycle Management Guide and IAM and Identity Provider Buyer’s Guide both reinforce the practical point that lifecycle clarity and user fit are part of control quality, not just implementation detail.

One reliable test is whether users can complete the intended task without needing an exception for ordinary work. If exceptions are becoming routine, the workflow may still be secure in theory, but it is failing in adoption, which usually leads to shadow processes, duplicate requests, and weaker auditability over time.

Risk and Threat Considerations

When IAM automation creates too much friction, the main risk is not only user dissatisfaction. Excessive resistance pushes people toward bypasses, shared workarounds, and off-platform approvals, which weakens visibility and can undermine the very access controls the automation was meant to enforce.

Failure mechanism: Users encounter slow, confusing, or repetitive steps, then shift to informal channels, duplicate identities, or manual exceptions that are harder to govern and monitor.

Impact: Access processes become less trustworthy, support load rises, and the organisation can end up with both poorer user experience and weaker control assurance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Excess friction often signals over-restrictive access design that blocks normal work.
	IA-5 — Authenticator Management	Repeated resets and login help tickets are direct signs of poor authenticator usability.
Recommendation — Right-size access so legitimate users can complete routine tasks without repeated exceptions. Tune authenticator lifecycle and recovery flows to reduce avoidable reset burden.
CIS Controls v8	5 — Account Management	User friction commonly appears in account, entitlement, and request handling workflows.
Recommendation — Streamline account and entitlement workflows so routine access changes are fast and auditable.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	The question is about whether access control automation is working for users without creating avoidable friction.
Recommendation — Measure access-control usability alongside enforcement outcomes and fix the workflow that causes bypasses.

Practitioner Guidance

What to prioritise: Track where the process loses users, not just where it enforces policy. The most useful signals are repeat tickets, abandoned requests, exception rates, and the specific step where users stall.

What to verify: Check whether the friction comes from the policy itself, the role model, the approval chain, or the interface. Those are different problems, and they need different fixes. A slow process is not always an overly strict process, sometimes it is simply a poorly designed one.

Decision rule: If users are repeatedly bypassing a step to complete normal work, treat that as a control-design failure, not a training issue alone. If the request is truly exceptional, keep the control; if it is common, simplify the path.

Practitioner takeaway: The goal is not maximum automation, but usable control, if people cannot complete legitimate access tasks efficiently, they will eventually route around the process you built to protect them.