Who is accountable for secrets management when R&D creates secrets but security owns risk?

Why This Matters for Security Teams

Secrets ownership sounds administrative until a leaked token, API key, or certificate exposes production systems, source code, or cloud control planes. When R&D creates secrets but security owns the risk, the real issue is not who typed the credential into a pipeline, but who can enforce policy, prove custody, and revoke access fast enough to limit blast radius. NHIMG’s Guide to the Secret Sprawl Challenge shows how quickly unmanaged secrets become operational debt rather than isolated exceptions. This aligns with the NIST Cybersecurity Framework 2.0 expectation that governance and protection responsibilities must be explicit, not implied.

For security teams, accountability means setting the rules for creation, storage, rotation, and emergency revocation, even when engineering teams need to generate credentials inside development workflows. The failure mode is usually a split brain: R&D optimises for delivery speed while security assumes someone else is tracking exposure. In practice, many organisations discover the gap only after a secret has already been reused across environments or embedded in a build artifact.

How It Works in Practice

Accountability should be assigned by control, not by who first handled the secret. R&D can own day-to-day usage in code, build jobs, and test environments, but security should own the policy framework, exception handling, and oversight required to keep secrets from drifting into shadow processes. That means defining where secrets may be created, how they are approved, where they are stored, and when they must be rotated or destroyed. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because secrets should be treated as lifecycle-managed assets, not one-time implementation details.

In practice, mature programmes centralise control through policy and workflow:

• Security defines the approved secrets platform, rotation standards, and revocation triggers.
• Engineering consumes secrets through automated delivery paths, not manual copy-paste.
• CI/CD and runtime systems receive short-lived credentials where possible, reducing dwell time.
• Audit logs tie each secret to an owner, system, and purpose so incidents can be contained quickly.

Where organisations are moving toward stronger controls, current guidance suggests combining workload identity, privileged access controls, and policy-as-code so secrets are issued and revoked based on context, not convenience. The OWASP Non-Human Identity Top 10 is relevant because unmanaged machine credentials are a common path to lateral movement, especially when secrets are shared across services. These controls tend to break down when development teams can create ad hoc credentials outside central tooling because security loses the authoritative inventory.

Common Variations and Edge Cases

Tighter secrets governance often increases delivery friction, requiring organisations to balance developer autonomy against auditability and revocation speed. That tradeoff is real, especially in research environments, labs, and short-lived proof-of-concept work where teams create credentials quickly and dispose of them just as fast. Best practice is evolving, but the accountability model should still remain the same: security owns the control plane, while R&D may own operational use within approved bounds.

One common edge case is delegated creation. A platform team may automate secret issuance for developers, but that does not transfer accountability unless the platform team is also formally responsible for policy enforcement and evidence collection. Another edge case is legacy tooling, where static secrets are embedded in scripts or configuration files because the environment cannot yet support dynamic issuance. In those cases, security still owns the risk and should require compensating controls such as tighter rotation, stronger monitoring, and emergency replacement procedures.

NHIMG’s Guide to the Secret Sprawl Challenge is especially relevant when multiple teams, repositories, or cloud accounts create overlapping credential sprawl. The practical rule is simple: if security cannot see it, rotate it, or revoke it, then accountability has not been properly assigned.

Related resources from NHI Mgmt Group

• Who is accountable when a security team cannot show clear ownership for application risk?
• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?