When controls feel obstructive, organisations should redesign the experience around the employee’s job, not around security convenience. That means explaining the business reason for the control, using role-specific examples, and listening when users work around a process. The goal is to make the secure path the easiest path, while preserving accountability for repeated risky behavior.
Why Employees Push Back When Controls Feel Obstructive
When people work around a control, it is often a signal that the control is mismatched to the task, too slow for the risk it is meant to reduce, or explained in a way that fails to connect to the employee’s actual job. A control that ignores workflow friction tends to lose legitimacy, which drives shadow processes and weakens the very protection it was meant to provide.
The practical issue is not whether users like the control, but whether the control competes with real work. If the secure path adds unnecessary steps, unclear approvals, or repeated interruptions, employees will naturally seek a faster route. That makes usability part of security design, not a separate concern.
How to Redesign Controls Around the Work It Protects
The most effective response is to redesign the control around the business action it supports, then make the secure path as close as possible to the default workflow. That usually means reducing avoidable friction, using language that explains why the control exists, and tailoring the experience to different roles rather than applying one generic process everywhere.
Good redesign is specific. A finance approver, a developer, and a customer service agent do not face the same operational trade-offs, so the same control may need different presentation, timing, or exception handling. The point is to preserve the control objective while removing friction that does not actually reduce risk.
This is also where NIST Cybersecurity Framework 2.0 is useful at the programme level, because it reinforces governance, protection, and recovery as business capabilities rather than isolated technical checks. For control implementation, NIST SP 800-53 Rev 5 Security and Privacy Controls gives practitioners a way to anchor access, auditing, and configuration decisions without turning every safeguard into an arbitrary user burden. In mature environments, CIS Controls v8 is often the clearest way to translate policy into operational safeguards that are easier to standardise and explain.
What Happens When Users Start Working Around the Process
Workarounds matter because they are evidence that the control is no longer the path of least resistance. Users may delay adoption, reuse credentials, share access, store data in the wrong place, or ask for exceptions that quietly become normal. At that point, the organisation is not just dealing with inconvenience, it is dealing with control drift.
The right response is to treat repeated workarounds as operational feedback and as a governance signal. One-off exceptions may be acceptable if they are tracked and time-bound, but repeated risky behaviour usually means the process needs redesign or the control needs stronger management sponsorship. The objective is to distinguish genuine business need from avoidable non-compliance.
That is why teams should preserve accountability while still improving usability. If a shortcut materially increases exposure, the organisation should not normalise it just because employees prefer it. Instead, it should either fix the friction, shorten the approval path, or make the exception visibly owned and reviewable.
Risk and Threat Considerations
Controls that are perceived as obstructive often create a predictable risk pattern: employees bypass them, share access, or store sensitive material in less controlled places. Over time, that can weaken auditability, increase exposure, and reduce confidence that the control environment reflects real behaviour.
Failure mechanism: friction, poor explanation, or role mismatch leads users to choose unofficial paths, and those paths can become repeatable shadow processes that are harder to monitor or reverse.
Impact: organisations may end up with weaker enforcement, more exceptions, and a false sense of control strength because the policy exists on paper while actual work happens elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Controls should fit business workflow and risk tolerance. |
| Recommendation — Align control friction with the organisation's risk management strategy. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits access while avoiding unnecessary permission burden. |
| AU-6 — Audit Review, Analysis, and Reporting | User workarounds need reviewable evidence and accountability. | |
| Recommendation — Apply least privilege to keep controls proportionate to job needs. Review audit data to detect repeated workaround behaviour. | ||
| CIS Controls v8 | CIS-5 — Account Management | User friction often stems from account and access handling. |
| Recommendation — Standardise account processes to reduce avoidable control friction. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access controls must be usable enough to be followed consistently. |
| Recommendation — Design access control procedures that users can follow reliably. | ||
Practitioner Guidance
What to prioritise: start with the controls that interrupt the most common business workflows, because those are the ones most likely to be bypassed at scale. If a safeguard affects a high-frequency task, its usability is a security issue, not a cosmetic one.
What to verify: confirm that the control owner can explain the business reason for each major step, and that frontline users can describe what the control is protecting. If neither group can state the risk clearly, the design is probably too abstract or too cumbersome.
Common mistake: adding extra approval or warning steps when the real problem is poor timing, unclear language, or a workflow that was built for policy convenience rather than task completion.
Practitioner takeaway: secure-by-design controls work best when they feel operationally fair, understandable, and proportionate; if users consistently resist them, the control design, not just the user behaviour, needs review.
Related resources from NHI Mgmt Group
- How can organisations evaluate whether their email security controls are stopping attacks before employees engage?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
