Why do identity controls fail when they create too much friction?

They fail because users optimise for speed and continuity of work. If the secure process is disruptive, people look for shortcuts, fall back to passwords, or avoid enrollment altogether. That turns a policy into an exception pattern. The real test is whether the control can be followed consistently by the people who must use it every day.

Why This Matters for Security Teams

Identity controls only work when people can use them repeatedly without bypassing them. When enrolment, MFA, approval chains, or secret rotation add too much friction, users optimise for continuity of work and create shadow paths that weaken the control rather than strengthen it. That is why a policy that looks strong on paper can become an exception culture in practice.

This pattern matters most for NHI and agentic workloads, where the “user” may be an application, pipeline, or autonomous agent. In those environments, identity friction can delay releases, break integrations, or push teams toward long-lived secrets and shared service accounts. NIST’s NIST Cybersecurity Framework 2.0 treats usable, risk-based control as part of resilience, not an optional convenience. NHIMG’s Ultimate Guide to NHIs frames the same problem from the machine identity side: if the control path is too hard, operations will route around it.

In practice, many security teams encounter bypassed identity controls only after users have already normalised the workaround rather than through intentional policy adoption.

How It Works in Practice

The practical failure mode is simple: the control asks for more effort than the user perceives as necessary for the task. For humans, that may mean repeated MFA prompts, overly frequent re-enrolment, or cumbersome approval steps. For NHI and agentic systems, it may mean service accounts that expire too quickly, manual secret retrieval, or access requests that cannot keep pace with deployment and runtime changes.

When that happens, teams compensate by reusing credentials, extending TTLs indefinitely, or storing secrets in places that are easy to reach and hard to govern. The right response is not to remove control, but to reduce friction through better design: just-in-time access, workload identity, short-lived tokens, and policy evaluation at request time. That approach aligns with current guidance in The State of Secrets in AppSec, which shows how fragmented secrets practices and weak day-to-day adoption create durable exposure.

For software and agents, this usually means:

• Use workload identity rather than shared static credentials so the system proves what it is, not just what secret it knows.
• Issue short-lived credentials only when a task is needed, then revoke them automatically.
• Make approval and policy checks contextual, so low-risk actions do not inherit the same burden as high-risk ones.
• Log and review exceptions, because repeated exceptions are often a design defect disguised as an operational workaround.

For implementation detail, teams often pair this with SPIFFE or similar workload identity patterns and policy engines that evaluate access dynamically. These controls tend to break down when legacy apps require static credentials or when platform teams cannot automate identity issuance across heterogeneous environments.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance stronger assurance against developer velocity, uptime, and support load.

There is no universal standard for how much friction is acceptable, so current guidance suggests measuring control success by sustained adoption, not by the strictness of the policy text. A control that is technically sound but routinely bypassed is weaker than a simpler control that people actually use. NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the same operational lesson: brittle identity processes create gaps that attackers can exploit.

Edge cases matter. In regulated environments, more friction may be justified if the workflow supports strong evidence, separation of duties, and auditability. In fast-moving engineering environments, the better pattern is usually invisible security: federated auth, automated enrolment, and secretless access where possible. For autonomous agents, that becomes even more important because humans cannot manually approve every action without breaking the system. Best practice is evolving, but the direction is clear: reduce friction by making secure behaviour the easiest path, not the exceptional one.

Related resources from NHI Mgmt Group

• What breaks when identity controls create too much friction for teams?
• What breaks when access controls create too much friction?
• Why do SaaS apps create identity governance risk as they spread across the business?
• Why do collaboration automations create identity risk even when they save time?