Who is accountable when secret access decisions are not properly governed?

Why This Matters for Security Teams

Secret access decisions are not just an administration problem. They define who can authenticate, which systems can be reached, and how quickly an attacker can move if a token, API key, or certificate is misused. When policy ownership is unclear, organisations tend to accumulate exceptions, stale access, and weak approvals that are hard to reverse later.

NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which is why access governance has to be treated as a control with named accountability, not a ticket queue. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both frame this as a lifecycle issue, not a one-time approval issue. In practice, many security teams discover misgoverned access only after a secret has already been copied into a pipeline, repo, or workload, rather than through intentional review.

How It Works in Practice

Accountability starts with three decisions that must be explicit: who owns the policy, who can approve exceptions, and who is responsible for revocation when access is no longer needed. In mature environments, the identity team defines the control set, the application or data owner approves business need, and the security function validates that the process is auditable. The question is not only “who said yes,” but also “who can prove the decision was constrained, time-bounded, and reversible.”

Good governance also requires evidence. Teams should be able to trace the requester, the justification, the granted scope, the expiry time, and the revocation event. That is consistent with the control intent in NIST Cybersecurity Framework 2.0 and the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where least privilege, auditability, and lifecycle management intersect. For secrets, that usually means integrating vault approvals, CI/CD policies, and privileged access workflows so that approvals are not isolated in spreadsheets or chat threads.

• Assign one policy owner for each secrets domain, such as production apps, pipelines, or third-party integrations.
• Require business justification and expiry for every exception, including temporary emergency access.
• Log approval, issuance, and revocation events in systems that security can review later.
• Review access on a fixed cadence and after role changes, incidents, or vendor offboarding.

NHIMG’s Guide to the Secret Sprawl Challenge is especially relevant here because secret sprawl often begins when ownership is ambiguous and no one is clearly accountable for cleanup. These controls tend to break down when secrets are embedded in CI/CD automation owned by multiple teams because approval and revocation responsibilities become fragmented across toolchains.

Common Variations and Edge Cases

Tighter approval control often increases operational friction, requiring organisations to balance faster delivery against stronger oversight. That tradeoff is real, especially in incident response, development sandboxes, and vendor integrations where access needs can change quickly. Current guidance suggests using short-lived access and explicit expiry rather than permanent exceptions, but there is no universal standard for every environment yet.

Emergency access is the most common edge case. Best practice is evolving toward time-boxed elevation with post-event review, but some organisations still rely on verbal approval or informal channel messages. That creates weak accountability because the approval may exist, yet the scope and removal point are impossible to verify later. The same problem appears with third-party systems, where a service account may be owned by one team, approved by another, and rotated by a vendor. NHIMG’s Top 10 NHI Issues highlights how often visibility and rotation failures compound this problem.

In cloud-native and agentic environments, the question expands beyond human approval chains. If tools can request secrets at runtime, accountability must extend to the policy engine that evaluated the request and the workload identity that made it. This is where identity governance, not just access review, becomes the practical control boundary.

Related resources from NHI Mgmt Group

• Who is accountable when non-employee access is not governed properly in regulated environments?
• Who is accountable when workflow access reviews and source-of-truth decisions are inconsistent?
• Who is accountable when physical access decisions do not match HR status or security policy?
• Who should be accountable for secure access decisions across systems, networks, and communications?