Accountability should sit with the team that owns the application and its runtime access paths, supported by platform, security, and identity teams. Developers need safe patterns for delivery, security teams need policy and detection, and operations teams need reliable revocation and rotation. Shared responsibility only works when ownership is explicit for each secret and environment.
Why This Matters for Security Teams
Application secrets are not just a developer convenience problem. They are a shared operational risk that spans code, CI/CD, cloud runtime, incident response, and audit. If accountability is vague, secrets tend to accumulate in repositories, pipeline variables, images, and ad hoc handoffs, where revocation becomes slow and detection becomes reactive. The Guide to the Secret Sprawl Challenge shows why sprawl is so hard to contain once multiple teams own different parts of the path. NHIMG research also notes that only 44% of developers consistently follow secrets management best practices in The State of Secrets in AppSec, which makes process ownership as important as technical tooling.
The right accountability model is usually not “security owns secrets” or “developers own secrets” in isolation. Security should define policy, guardrails, and detection. Platform and operations should manage reliable rotation, revocation, and workload access paths. Application teams should own the secret’s purpose, usage scope, and retirement when the app changes. In practice, many security teams discover the ownership gap only after a leaked credential has already been reused across environments, rather than through intentional governance.
How It Works in Practice
Clear accountability starts by mapping each secret to a specific application, environment, and runtime path. That means identifying who can create it, where it is stored, how it is injected, when it rotates, and who can revoke it during an incident. The practical goal is to keep the secret tied to the workload that needs it, not to a person, ticket, or undocumented deployment habit. This aligns with the control philosophy in the OWASP Non-Human Identity Top 10 and with the baseline control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
- Application owners define the business purpose, approved dependencies, and acceptable secret exposure surface.
- Security teams set policy for storage, rotation intervals, logging, and exception handling.
- Platform and cloud operations enforce provisioning, delivery, short TTLs, and revocation.
- Identity teams ensure non-human identities and workload credentials are issued through governed paths.
In mature environments, this becomes a lifecycle: request, issue, use, rotate, revoke, and retire. The strongest pattern is to reduce static secrets wherever possible and move toward workload-bound, short-lived credentials, especially for cloud services and CI/CD systems. NHIMG’s 2024 Non-Human Identity Security Report reports that 59.8% of organisations see value in dynamic ephemeral credentials, which reflects where the operational pressure is heading. These controls tend to break down when multiple platform teams manage different clouds with different secret stores and no single owner for revocation.
Common Variations and Edge Cases
Tighter secrets control often increases operational overhead, requiring organisations to balance faster delivery against stricter governance. In shared services models, it is common for a central platform team to own the tooling while application teams retain accountability for the secret’s use. That split can work, but only if there is a named owner for every secret and a documented path for emergency revocation. Otherwise, the organisation gets tool coverage without true accountability.
Current guidance suggests that exceptions should be temporary and visible. For local development, short-term developer secrets may be permitted, but they should not be the same credentials used in production. For third-party integrations, the application owner still owns the risk even if a vendor-issued token is involved. For legacy systems that cannot support rotation cleanly, security teams should track compensating controls and a retirement plan instead of treating the exception as permanent.
Secret accountability also intersects with supply chain risk. Incidents such as the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly secrets can leak when code and pipeline ownership are unclear. Best practice is evolving, but there is no universal standard for this yet: organisations still need explicit ownership, fast revocation, and continuous detection across development and cloud operations.
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, NIST Zero Trust (SP 800-207) 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 | Supports identity and access governance for application secrets and workloads. |
| NIST SP 800-63 | Identity assurance principles help distinguish workload credentials from human access. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust reinforces continuous verification for secret use across runtime paths. |
| NIST AI RMF | GOVERN | Governance requires accountable ownership for high-risk automated access paths. |
Assign each application secret an owner and enforce rotation, revocation, and retirement on a defined schedule.
Related resources from NHI Mgmt Group
- Who should be accountable for API security findings across development and cloud operations?
- Who should be accountable for cloud permission governance across security, operations, and development teams?
- Who should be accountable for cleaning up inactive identities across cloud platforms?
- Who is accountable for secrets governance across multiple cloud vaults?
