The resistance people feel when a security control asks them to change a familiar routine. In identity programmes, friction is often the hidden cause of low adoption, weak compliance, and shadow workarounds that preserve the old behaviour.
Expanded Definition
Behavioural Friction is the operational resistance created when a security control changes how people or operators normally complete work. In NHI and IAM programmes, it is not merely annoyance. It is the gap between a policy intent and the habits, shortcuts, and timing that users rely on to keep systems moving.
Definitions vary across vendors and programme teams, but the practical meaning is consistent: if a control feels slower, more complex, or less predictable than the workflow it replaces, adoption often drops and compensating behaviours appear. That makes behavioural friction a governance issue, not just a UX concern. It is closely related to the control objectives described in the NIST Cybersecurity Framework 2.0, but NIST does not use this exact term as a formal control category.
The distinction matters because some friction is deliberate and valuable, such as forcing approvals or reauthentication at sensitive moments. The challenge is distinguishing protective friction from unnecessary friction that users route around. The most common misapplication is treating user complaints as mere resistance, which occurs when teams add controls without matching them to actual task flow, escalation path, or operational urgency.
Examples and Use Cases
Implementing behavioural friction rigorously often introduces a real tradeoff between stronger control and slower execution, requiring organisations to weigh compliance assurance against the temptation to bypass the process.
- A developer is asked to request a fresh token for every deployment, but the approval path is slower than the release cadence, so the team stores a long-lived credential in a config file.
- An operations analyst must reauthenticate before revoking a sensitive service account, which improves accountability but can delay urgent incident response if the workflow is poorly designed.
- A security team adds a secret rotation step that is technically sound, yet it is too disruptive during on-call windows, leading operators to postpone rotation until the next outage cycle.
- In a Zero Trust rollout, login prompts and device checks may be appropriate, but if they appear repeatedly during routine service-to-service work, users may create shadow tooling to preserve speed.
- The Ultimate Guide to NHIs shows why this matters for service accounts and API keys, where routine shortcuts often become lasting exposure points.
For a standards lens, the control design principles in NIST Cybersecurity Framework 2.0 help teams decide where friction should be intentional and where it should be reduced.
Why It Matters in NHI Security
Behavioural friction becomes critical in NHI security because machines do not “forget” controls, but the humans managing them do choose workarounds under pressure. If a secret rotation, offboarding, or approval process is too cumbersome, teams often defer it, duplicate credentials, or embed secrets directly into code and pipelines. NHIMG research found that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 71% of NHIs are not rotated within recommended time frames, both of which reflect control paths that were easier to bypass than to follow.
This is why behavioural friction is a governance signal. It reveals where a policy is technically correct but operationally fragile. It also explains why identity programmes fail after audit findings, incident response, or a leaked secret exposes a hidden dependency. At that point, the organisation is no longer debating user experience. It is dealing with a broken control chain that already affected access, rotation, or containment.
Practitioners typically encounter behavioural friction as the root cause only after a breach review shows that the documented control existed, but the real workflow never made it practical to use.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Control friction often drives unsafe secret handling and bypass behaviour. |
| NIST CSF 2.0 | PR.AC-1 | Access control effectiveness depends on workflows people can actually follow. |
| NIST Zero Trust (SP 800-207) | Zero Trust adds verification points that can create either necessary or harmful friction. | |
| NIST SP 800-63 | AAL2 | Assurance requirements shape how much friction is acceptable in identity workflows. |
Design NHI controls so rotation and revocation are usable enough to avoid shadow workarounds.
Related resources from NHI Mgmt Group
- When does zero trust IAM create more friction than risk reduction?
- Why do Kubernetes workloads need both posture checks and behavioural monitoring?
- Should organisations prioritise token rotation or behavioural detection first?
- How should organisations implement PSD2 controls without adding too much checkout friction?
