Why do security controls sometimes appear to reduce developer productivity?

Why This Matters for Security Teams

Security controls often feel slower than insecure shortcuts because they shift effort into approval, verification, and exception handling. That tradeoff is not accidental. Controls are meant to reduce rework, limit blast radius, and make risky behaviour visible before it becomes an incident. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls frames security as a set of outcomes, not a bundle of obstacles, which is the right way to judge developer experience too.

The common mistake is treating every added step as wasted time. In practice, some controls are expensive because they are compensating for weak engineering hygiene, unclear ownership, or late-stage security review. When security is bolted on at the end of a sprint, it competes with delivery deadlines instead of shaping the work earlier. That is when teams start to blame the control rather than the workflow around it.

Security leaders should separate temporary friction from structural friction. Temporary friction is the one-time learning curve of a new control. Structural friction is repeated, manual, and fragile approval work that scales badly across teams and systems. In practice, many security teams encounter developer resistance only after release delays and exception requests have already become the default operating model, rather than through intentional control design.

How It Works in Practice

Controls affect productivity through four main mechanisms: context switching, waiting, rework, and duplication. A developer who must leave an editor to request access, gather evidence, or chase multiple approvers loses flow. A pipeline that fails late because security checks were added after implementation creates rework. A duplicate control, such as two tools scanning the same artefact without shared results, adds cost without improving assurance.

Good practice is to move the control as close as possible to the point where the risk appears. For application teams, that often means policy-as-code in the CI/CD pipeline, pre-approved templates, centrally managed secrets, and least-privilege access that avoids ad hoc exceptions. For identity-heavy environments, this also means reducing manual privilege grants and aligning with NIST Zero Trust Architecture principles so access decisions are based on context rather than static trust.

• Automate checks that can be evaluated consistently, such as configuration, dependency, and secrets scanning.
• Push review earlier in the lifecycle so defects are caught before merge, release, or production access.
• Define clear ownership for exceptions so “temporary” bypasses do not become permanent habits.
• Make control results visible in the tools developers already use, rather than forcing separate workflows.

Developer productivity improves when controls are designed as part of the delivery path, not layered on top of it. Security teams should also measure outcomes that matter to engineers, including lead time, merge failures, and exception volume, alongside risk reduction. Guidance from the CISA Secure by Design initiative supports this shift by favouring controls that remove classes of defects instead of just detecting them later. These controls tend to break down in highly fragmented toolchains because each platform enforces its own workflow and no single team owns the end-to-end path.

Common Variations and Edge Cases

Tighter controls often increase coordination cost, requiring organisations to balance assurance against speed. That tradeoff is especially visible in highly regulated environments, where stronger review can be justified even when it slows delivery.

Best practice is evolving around how much friction is acceptable for different risk tiers. A production change that affects customer data should usually face more scrutiny than a low-risk internal script. Likewise, a mature platform team can often absorb stricter guardrails better than a small product team with limited DevSecOps support. There is no universal standard for this yet; the right balance depends on the asset, the threat model, and the team’s operating maturity.

Two edge cases matter most. First, controls can look inefficient when the organisation has already accumulated technical debt, because the control exposes hidden weaknesses that were previously ignored. Second, controls can become productivity traps when exceptions are easier to obtain than compliance. In those environments, the real fix is usually governance and architecture, not removing the control. For identity-related workflows, the same pattern appears when access governance is manual: the slowdown is often a signal that entitlement design, not the control itself, needs repair.

Where regulatory obligations apply, such as security control guidance, the question is not whether to remove friction entirely, but whether the organisation can make the friction predictable, auditable, and proportionate. That is what turns security from a blocking function into an engineering constraint that teams can design around.

Related resources from NHI Mgmt Group

• How should security teams reduce risk from AI agents and developer tools that use secrets locally?
• How should security teams reduce risk from fragmented IAM controls?
• How should security teams reduce secret sprawl on developer workstations?
• How should security teams reduce risk in software delivery pipelines with NHI controls?