A common mistake is adding controls that make work harder than the insecure workaround. If security blocks normal tasks, users will bypass it. Effective programmes reduce friction, support the business, and make the secure path the easiest path. That balance is essential for adoption in distributed, cloud-heavy environments.
Where Security Friction Becomes a Business Problem
The core mistake is treating productivity loss as an acceptable side effect of security design. When a control slows routine work, people do not experience it as “better security”; they experience it as delay, workarounds, and inconsistency. That is why the balance question matters operationally, not just culturally. Security programmes that ignore workflow reality often create shadow processes, duplicate approvals, and unmanaged exceptions that weaken control coverage instead of strengthening it.
For non-human access, the same pattern shows up when service accounts, automation, and application secrets are made harder to use than the systems they protect. The result is usually more sharing, more static credentials, and less visibility into what actually holds access. OWASP Non-Human Identity Top 10 is useful here because it frames how poor lifecycle and access design turns routine operations into ongoing exposure. In practice, many security teams first notice the cost of friction only after users have already normalised bypasses and exception handling.
How Security and Productivity Should Fit Together in Daily Operations
Effective balance starts with mapping controls to actual work patterns rather than to abstract policy goals. The question is not whether a control is strong in theory, but whether it can be used correctly under deadline pressure, with interruptions, across devices, and by different user groups. A control that is technically sound but operationally awkward often fails in exactly the places where risk is highest: urgent access requests, onboarding, remote collaboration, and recovery tasks.
In practice, good programmes reduce the number of decisions users must make. They pre-authorise common actions, remove repeated prompts where risk is stable, and reserve higher-friction steps for genuinely sensitive changes. That does not mean lowering standards. It means shifting effort away from everyday use and toward exception handling, high-risk transactions, and privileged operations. Where teams get this wrong, they often apply the same friction everywhere, even though routine access and administrative access have very different risk profiles.
- Use the least disruptive control that still materially reduces the risk being addressed.
- Design for the common path first, then add stronger checks only for sensitive actions.
- Measure whether users are completing work through approved paths, not through exceptions.
- Review whether repeated approvals, re-authentication, or manual steps are compensating for a weak underlying design.
This approach breaks down when organisations rely on controls that are too coarse to distinguish normal use from elevated risk, because then productivity and protection both deteriorate.
Common Misjudgments and the Trade-offs Teams Overlook
Tighter control often increases operational overhead, so organisations need to balance assurance against the cost of constant interruption. The trade-off is not simply “more security versus more speed”; it is usually “better-targeted friction versus broad friction that users will work around.” That distinction matters because a control that is annoying in low-risk contexts can become invisible in high-risk contexts if users stop taking it seriously.
One common misjudgment is assuming users resist security because they are careless. More often, they are responding to controls that do not fit the task at hand. Another mistake is optimising for policy compliance while ignoring actual task completion. A programme can look strong on paper and still be weak in practice if users move work into messaging tools, personal devices, or shared credentials to stay productive.
There is also a governance edge case: teams sometimes confuse convenience with risk acceptance. Not every friction point is a flaw, and not every bypass is malicious, but persistent workarounds are a signal that the control design no longer matches the operating environment. Where that happens, the answer is usually not to remove security entirely, but to redesign the control so that the secure path is easier than the risky one.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Balances access restrictions with authorised business use. |
| Recommendation — Tune access rules so legitimate work stays possible without relying on exceptions. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Access friction must support secure use without driving unsafe workarounds. |
| GV.OV — Oversight | User productivity impacts belong in governance review of security decisions. | |
| Recommendation — Design access controls so routine tasks remain usable while stronger checks protect sensitive actions. Review security controls for business impact and usability before treating them as effective. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Non-Human Identity Inventory and Ownership | Automation and service identities need usable ownership to avoid hidden operational bypasses. |
| NHI-03 — Secrets Management | Overly burdensome secret handling often drives insecure sharing or reuse. | |
| Recommendation — Maintain clear ownership for machine identities so teams do not create shared or unmanaged access paths. Make secret handling practical enough that users do not bypass it with shared credentials. | ||
Practitioner Guidance
What to prioritise: Start with the controls that sit in the highest-volume work paths, because those create the most bypass pressure when they are clumsy. If a safeguard only works when users remember it, accept it, and repeat it correctly under stress, it is too dependent on ideal behaviour.
What to verify: Check whether the control protects the activity that actually creates risk, not just the activity that is easiest to govern. A useful test is whether users can complete legitimate work without inventing side channels, shared accounts, or manual exceptions.
What practitioners underestimate: Friction compounds across adjacent controls. A login step, an approval step, and a device check may each seem reasonable alone, but together they can make the sanctioned path slower than the unsafe workaround. That is when adoption fails even though the individual controls look defensible.
Practitioner takeaway: The right balance is not achieved by lowering security until users are comfortable; it is achieved by removing unnecessary friction from normal work and reserving stronger controls for the moments where risk really changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
