Accountability should sit with the security and engineering leaders who own the control plane, not with individual developers alone. Security teams define policy, monitoring, and escalation paths, while platform and application teams implement the workflows. Shared ownership works best when policy is enforceable, exceptions are tracked, and remediation is measured in days, not weeks.
Why This Matters for Security Teams
secrets governance breaks down fastest when accountability is split by convenience instead of control ownership. Developers need speed, but they do not own the policy engine, the secret store, or the monitoring pipeline, so they cannot be the sole accountable party when exposure happens. NHI Management Group’s research on the State of Secrets in AppSec shows that the average time to remediate a leaked secret is 27 days, even though 75% of organisations say they are confident in their secrets management.
That gap matters because secrets are not just configuration values. They are active credentials that can unlock production systems, CI/CD pipelines, cloud APIs, and third-party services. The practical question is not whether developers should care, but who can enforce rotation, detect drift, and approve exceptions when productivity pressure tempts teams to bypass controls. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 points to shared accountability, but the control owner must be explicit.
In practice, many security teams discover weak ownership only after a leaked token has already been reused across multiple systems.
How It Works in Practice
The most workable model is shared execution with clear accountability: security sets the control requirements, engineering owns the implementation path, and platform teams operate the tooling that makes secure behaviour the default. That usually means defining where secrets may live, how they are issued, how they are rotated, who can approve exceptions, and what telemetry proves the process is working. The issue is not policy alone. It is whether policy can be enforced at the point where developers actually work.
In mature environments, this often includes central secret managers, automated scanning in source control and CI/CD, short-lived credentials, and break-glass workflows for edge cases. The operational goal is to replace manual handling with controls that are fast enough to use. The Guide to the Secret Sprawl Challenge is a useful reminder that fragmented tooling creates blind spots, while the State of Non-Human Identity Security shows how often over-privilege and weak rotation contribute to compromise.
- Security defines minimum standards for storage, rotation, logging, and exception handling.
- Engineering integrates those standards into build, deploy, and runtime workflows.
- Platform teams provide the secret delivery mechanism and enforceable guardrails.
- Risk and compliance track exceptions, overdue rotations, and remediation latency.
This guidance breaks down in highly decentralized environments with multiple unmanaged secret stores because no single team can reliably prove what exists, where it is used, or whether it has been rotated.
Common Variations and Edge Cases
Tighter secrets controls often increase delivery friction, so organisations have to balance developer autonomy against the risk of silent credential sprawl. That tradeoff is real, especially in fast-moving product teams, legacy estates, and M&A integrations where standard tooling is inconsistent. Best practice is evolving, but current guidance suggests that the more variable the environment, the more explicit the accountability model must be.
There are a few common edge cases. In startup-style teams, the platform function may be small, so security may need to temporarily own more of the control design until automation matures. In regulated environments, the accountability chain usually extends to audit, legal, and compliance, but that does not remove engineering ownership of implementation. For NHI-heavy workloads, especially those described in Ultimate Guide to NHIs — Static vs Dynamic Secrets, the priority should shift toward ephemeral credentials and task-based issuance rather than long-lived shared secrets.
The practical rule is simple: if a team can create, expose, or rotate a secret, it must also be accountable for the control that prevents misuse. If it cannot enforce the control, then it owns only part of the process, not the outcome.
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 NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation and lifecycle control for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Covers identity and access control accountability for systems and users. |
| NIST SP 800-63 | Identity assurance principles support governance for issued credentials. | |
| NIST AI RMF | Governance and accountability are core AI risk management functions. |
Document decision owners, escalation paths, and exception handling for secrets-related risk decisions.
Related resources from NHI Mgmt Group
- Who is accountable when productivity and security goals conflict in access governance?
- How do security teams know if supply chain controls are actually improving developer trust and delivery speed?
- Who should own secrets security and NHI governance across the enterprise?
- Who should be accountable for access governance when enterprises use a partner to implement identity controls?
