What do organisations get wrong about balancing security and user productivity?

Why This Matters for Security Teams

The usual failure is not that organisations care too much about security or productivity, but that they optimise each in isolation. Teams add prompts, approvals, MFA steps, scanning, or ticket gates without mapping them to the actual workflow, so the secure path becomes slower than the unsafe one. When that happens, people route around controls, shadow IT grows, and exceptions become the operating model.

This is especially visible in identity-heavy environments where secrets, service accounts, and delegated access keep the business running. NHI Management Group’s Ultimate Guide to NHIs — The NHI Market notes that 97% of NHIs carry excessive privileges and 71% are not rotated within recommended time frames, which shows how easily convenience-driven shortcuts become systemic exposure. The security goal is not maximum friction. It is to make the secure path the most usable path for legitimate work, aligned to the NIST Cybersecurity Framework 2.0 function of protecting access without creating avoidable operational drag.

In practice, many security teams encounter bypasses only after a business-critical team has already built a faster workaround.

How It Works in Practice

Balancing security and productivity starts with understanding actual work patterns, not policy ideals. The most effective programmes map high-frequency tasks, identify where users lose time, and then remove friction from the secure version of those steps. For NHIs and agentic workloads, that often means replacing long-lived secrets with short-lived credentials, using workload identity, and applying just-in-time access so access exists only for the task at hand. Guidance from the Ultimate Guide to NHIs — The NHI Market is consistent with this: excessive privilege and poor rotation are not just security flaws, they are productivity problems because they increase break-glass events and incident cleanup.

Operationally, security leaders should focus on controls that reduce user effort while tightening assurance:

• Use single sign-on, workload identity, and policy-based access so users do not juggle multiple credential sets.
• Automate approvals for low-risk, high-frequency requests, while reserving human review for exceptional cases.
• Set defaults that are secure but practical, such as short TTLs, scoped permissions, and reusable guardrails.
• Instrument workflows so teams can see where time is lost, where rework happens, and where controls are being bypassed.

Current guidance suggests that the best control is often the one users barely notice because it is embedded in the workflow, not bolted onto it. This aligns with NIST’s emphasis on risk-based, outcome-focused security in NIST Cybersecurity Framework 2.0, where protection should support mission delivery rather than interrupt it. These controls tend to break down in highly fragmented environments where each team owns its own toolchain, because inconsistent identity patterns make automation and least-privilege enforcement hard to sustain.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance assurance against speed, exception handling, and support burden. That tradeoff is real, especially in regulated environments where every additional approval must be defensible. The mistake is assuming that more friction automatically means more security; in many cases, it only means more escalation paths and more stale exceptions.

There is no universal standard for exactly how much friction is acceptable. Best practice is evolving toward risk-tiered controls: low-risk actions should be nearly self-service, while high-impact actions should trigger stronger checks, shorter credential lifetimes, or step-up verification. For NHI-heavy workflows, this often means separating routine machine access from privileged automation, and using the NHI market guidance to justify why long-lived shared credentials undermine both productivity and control.

Where organisations often get it wrong is treating every workflow as if it deserves the same level of resistance. A finance approval, an internal data pull, and a production deployment do not need identical guardrails. Security teams that calibrate controls by business impact, rather than by fear or uniform policy, usually get better adoption and fewer workarounds.

Related resources from NHI Mgmt Group

• What do security teams get wrong about search and filtering in large user directories?
• What do organisations get wrong about user friction in security controls?
• What do security teams get wrong about client-level access controls in shared service environments?
• What do security teams get wrong about regional PII coverage in global platforms?