The difference usually comes down to incentives, identity, and perceived effort. Developers who value speed, craftsmanship, proof, or team recognition are more likely to engage when security fits those priorities. Resistance grows when security feels like rework, vague criticism, or a blocker to delivery. Effective programs make the security outcome visible, practical, and personally relevant to the developer’s working style.
Why Security Feels Like Craft to Some Developers, and Friction to Others
Developer attitudes usually track how security work lands in the day-to-day workflow. When security is presented as a concrete engineering problem, such as reducing secret exposure, tightening authorization, or preventing fragile integrations, it can feel like craftsmanship. When it arrives as abstract policy, late review, or an after-the-fact gate, it reads as interruption. The same control can be welcomed or resisted depending on whether it reinforces the developer’s sense of quality and ownership.
Motivation also depends on whether the work preserves autonomy. Developers who like to reason about systems tend to respond well when security guidance is specific enough to support design choices, code changes, and measurable outcomes. Resistance tends to rise when the work is framed only as compliance, because then the benefit is distant while the effort is immediate. Programs that make the security outcome visible and technically actionable usually convert more of that resistance into engagement.
- Show the concrete failure mode, not just the rule.
- Connect the control to reliability, maintainability, or user trust.
- Give developers a path to fix the issue in code, config, or pipeline.
What Usually Drives Resistance in Practice
Resistance is rarely about hostility to security in the abstract. More often, it reflects cost, ambiguity, and bad past experiences. If a team has seen security feedback that is inconsistent, hard to reproduce, or disconnected from delivery priorities, they learn to treat it as overhead. If the control requires extra steps without a clear reduction in risk, developers rationally optimise around it.
Another common cause is that security work is sometimes communicated as criticism rather than collaboration. Developers tend to engage when the task is framed as improving system behaviour, reducing rework, or protecting a design they already care about. They resist when security appears only at the end of the process, because late change amplifies effort and makes the work feel externally imposed. A practical sign of maturity is when security is discoverable early enough that fixing it is cheaper than arguing about it.
When security work is about secrets, access, or deployment safety, the payoff is often clearer because the failure modes are tangible. For example, guidance that helps teams reduce leaked credentials or overexposed automation usually feels more real than generic “be more secure” advice. Resources such as NHI Mgmt Group’s Ultimate Guide to NHIs are useful precisely because they connect practical developer behaviour to concrete risks like overprivilege, poor rotation, and secrets sprawl.
How to Make Security More Acceptable to Developers
The most effective approach is to align security work with the developer’s own standards of good engineering. That means making the issue observable, the fix actionable, and the result testable. If a control cannot be expressed in a ticket, a test, a pipeline check, or a code change, it will often remain too abstract to win sustained support.
What to prioritise: Reduce unnecessary review friction first. Teams adopt security more readily when they see fast feedback, clear ownership, and a direct link between the recommendation and the code path they control.
What to verify: Check whether the control is presented as a technical improvement or just a policy demand. If developers cannot tell what success looks like, the program will usually be experienced as drag rather than enablement.
Practitioner takeaway: Security work gains developer support when it behaves like good engineering, specific, measurable, and low-friction, rather than like an external judgment layered onto delivery.
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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 5 — Account Management | Developer resistance often centers on access and credential hygiene. |
| CIS Control 16 — Application Software Security | This question is about fitting security into development work. | |
| Recommendation — Automate account and credential cleanup so developers see a clear, low-friction access lifecycle. Embed security checks into the software delivery path instead of adding late manual gates. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Non-Human Identity Inventory and Ownership | Developer workflows often involve service accounts, API keys, and other non-human identities. |
| NHI-03 — Secrets Sprawl and Storage | The answer uses secrets exposure as a concrete developer-facing security problem. | |
| NHI-04 — Overprivileged Non-Human Identities | Overprivilege is a practical example of security work developers may resist or embrace. | |
| Recommendation — Assign clear owners for machine identities and their secrets to reduce vague security friction. Eliminate ad hoc secret storage and move sensitive values into controlled secret management. Apply least privilege to machine access so security feedback is tied to a concrete risk reduction. | ||
Related resources from NHI Mgmt Group
- Why do some application flaws become security vulnerabilities while others remain functional defects?
- Why do some teams fix security findings much faster than others?
- Why does shifting security work to developers create both speed and risk?
- What are the signs that application security is too detached from how developers actually work?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
