Friction drift

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.

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?