The gradual expansion of security controls from targeted enforcement into broad, routine obstruction. It usually appears when a policy is rewritten to cover too many cases, causing false positives, user complaints, and workarounds that weaken the original control objective.
What Friction Drift Looks Like in Practice
Friction drift starts as a narrow safeguard and gradually mutates into a broad source of delay. The original intent is still “security,” but the lived experience becomes repeated prompts, blocked workflows, and exceptions that users expect to bypass.
That shift usually happens when the control is rewritten to cover edge cases instead of refining the underlying rule. A policy that is too expansive can catch legitimate activity often enough that people begin treating the control as background noise rather than a meaningful boundary.
Why Friction Drift Weakens the Control Objective
The core problem is not inconvenience by itself, but loss of signal. When a control creates too many false positives, people spend attention on navigating it instead of understanding what it is meant to stop. Over time, the original objective is diluted by routine obstruction.
This is why friction drift often produces workarounds. Once users or operators believe the control is broadly misaligned with real activity, they create shadow paths, exception habits, or informal approvals that bypass the intended safeguard and reduce consistency across the environment.
Common Patterns That Cause Friction Drift
Friction drift often appears in policies that try to be universally safe by adding more conditions, more approvals, or more exceptions without a clear boundary for when they apply. The control becomes less precise as it tries to handle every possible scenario, including rare ones.
It also shows up when teams optimize for complaint reduction instead of risk reduction. If the main feedback loop becomes “users are unhappy,” controls may be loosened in the wrong places or made so broad that they interfere with normal work more than they reduce exposure.
In identity and access contexts, a closely related failure mode is overbroad enforcement against tokens, sessions, or approvals that were originally scoped for a specific use case. NHIMG’s Salesloft OAuth token breach shows how token-related drift and reuse can turn a narrow integration path into a wider access problem.
How to Keep Security Controls Targeted
Friction drift is best prevented by preserving a tight link between the control and the risk it is meant to address. If the policy no longer maps cleanly to the threat or failure mode, it should be re-scoped rather than expanded by habit.
Controls also need a review path that distinguishes real protection from accumulated inconvenience. In access-heavy environments, that often means checking whether the rule still reflects least-privilege intent instead of merely adding another layer of routine obstruction. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls can help anchor that kind of control discipline.
For broader governance, teams should treat control fatigue as a design problem, not a user-education problem. A policy that creates persistent bypass pressure is usually telling you that the control boundary, not the people, needs correction.
Risk and Threat Considerations
Friction drift creates a security risk because repeated false positives and broad obstruction encourage exceptions, shortcuts, and informal workarounds. Once that pattern becomes normal, the control may still exist on paper but no longer function as an effective barrier.
Failure mechanism: The policy expands beyond its original target, generates too many benign hits, and pushes users toward bypass paths that weaken enforcement consistency.
Impact: The organisation loses control fidelity, gains false confidence from a rule that is widely circumvented, and may leave genuinely risky activity less visible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 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 | Friction drift often reflects access rules that became broader than intended. |
| AC-3 — Access Enforcement | The term concerns controls that stop working well when enforcement becomes too broad or noisy. | |
| CM-7 — Least Functionality | Friction drift can arise when controls accumulate unnecessary breadth and exception handling. | |
| Recommendation — Re-scope access rules to preserve least privilege and reduce routine bypass pressure. Tune enforcement points so they block only the activity they are meant to stop. Remove unnecessary control scope and keep policies narrowly tied to required function. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The concept maps to controls that should limit access without becoming broadly obstructive. |
| Recommendation — Implement least-privilege access paths that stay targeted and operationally usable. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Drift in control scope can result in broad, excessive permissions or enforcement gaps around identities. |
| Recommendation — Review identity-related permissions and narrow any access that has expanded beyond intent. | ||
Practitioner Guidance
Why practitioners should care: Friction drift is a design smell, not just an adoption issue. When a safeguard becomes a routine source of interruption, it is usually signalling that the rule has outgrown its original threat model or was never scoped tightly enough.
Common misunderstanding: More coverage is not always better security. A control that tries to catch every edge case often becomes so broad that it creates exceptions faster than it reduces exposure.
Practitioner takeaway: Treat persistent user workarounds as evidence that the control boundary needs refinement, not just more enforcement.
Related resources from NHI Mgmt Group
- How should universities roll out passphrases without creating user friction or policy drift?
- How should security teams think about a compromised integration like Drift?
- How can security teams reduce privilege drift in Kubernetes RBAC?
- When does zero trust IAM create more friction than risk reduction?