Yes. When developers spend large amounts of time on security but still ship vulnerable code, friction is telling you that the process is misaligned. That usually means the feedback is too late, the guidance is too vague or the approval chain is too slow to support secure delivery at scale.
Why This Matters for Security Teams
Developer friction is not just a productivity issue. It can reveal that security controls are arriving too late in the delivery lifecycle, that policy language is too abstract to act on, or that approval steps are creating workarounds instead of safer outcomes. When that happens, security becomes a bottleneck rather than a design constraint. The right response is not to remove controls, but to inspect whether the control design matches how software is actually built and released.
That is why this question belongs in security governance, not just engineering operations. The NIST Cybersecurity Framework 2.0 emphasises risk-based governance, continuous improvement, and control execution that supports the business rather than interrupting it. In practice, friction is often the earliest signal that a control is poorly integrated, poorly prioritised, or being interpreted inconsistently across teams. In practice, many security teams encounter the real control failure only after developers have built compensating shortcuts to keep delivery moving.
How It Works in Practice
Treating friction as a risk signal means measuring where security work slows delivery, then asking what that slowdown is actually telling you. Some delays are acceptable because they reflect genuine risk decisions. Others indicate that the team is spending effort on manual review, repetitive evidence collection, or unclear exceptions that do not materially reduce risk.
Security and platform teams should look at friction across the full delivery path: code commit, build, test, deployment, secrets handling, access requests, and incident response. If the same issue keeps resurfacing, it is usually a design problem rather than a training problem. Controls should be specific enough to be executable and early enough to shape decisions before code reaches production.
- Track where security findings are first detected and compare that point with when code is already merge-ready or deployed.
- Separate high-friction steps caused by risk from high-friction steps caused by vague policy, duplicate approvals, or missing automation.
- Use control language that maps to developer actions, not just audit categories.
- Prefer guardrails that scale, such as secure defaults, automated checks, and policy-as-code, over repeated manual exceptions.
Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls are most effective when they are translated into build-time and release-time enforcement that developers can actually follow. The practical test is whether a secure path is easier than an insecure workaround. These controls tend to break down when organisations bolt them onto legacy release pipelines with separate ticket queues, because the friction is then caused by process fragmentation rather than risk complexity.
Common Variations and Edge Cases
Tighter control often increases review overhead, requiring organisations to balance assurance against delivery speed. That tradeoff is real, and best practice is evolving around how much friction is acceptable for different classes of change. A low-risk documentation update should not face the same approval path as a production privilege change or a secret rotation event.
The nuance is that not all friction should be removed. Some friction is a healthy signal that a change needs scrutiny, especially where identities, permissions, or sensitive data are involved. The challenge is distinguishing useful friction from accidental friction. Current guidance suggests focusing on control intent: if the goal is to reduce exposure, the mechanism should be as automated and contextual as possible.
This matters even more in environments with distributed engineering teams, frequent release trains, or shared platform dependencies, where small delays compound quickly. In those settings, security often feels slow because it is added after architecture decisions have already been made. The better approach is to treat friction data as a feedback loop, then refine the control rather than blaming the developer. That distinction becomes especially important when identity or privileged access is part of the path, because slow approvals can push teams toward standing privileges and manual exceptions.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 | Friction can signal misaligned security objectives and operating constraints. |
| NIST SP 800-53 Rev 5 | SA-11 | Security testing should catch issues early enough to avoid late-stage friction. |
Shift verification earlier in the SDLC so findings are actionable before release pressure builds.
Related resources from NHI Mgmt Group
- Should organisations treat certificate expiry as an operational risk or a security risk?
- Should organisations treat shadow AI as a security risk or an innovation issue?
- When should organisations treat developer AI tooling as an NHI risk?
- When should organisations treat an NHI as a high-priority risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
