Who is accountable when privileged access policies do not cover secrets, certificates, and session controls together?

Why This Matters for Security Teams

When privileged access policies stop at the account layer, they miss the controls that actually govern misuse: secrets, certificates, and session state. That gap matters because a token can outlive an approval, a certificate can be reused outside its intended workflow, and a privileged session can continue after the original risk has changed. NHI Management Group has shown how quickly fragmentation turns into exposure in the Guide to the Secret Sprawl Challenge, especially when access, storage, and revocation are handled in separate systems.

Security teams often assume PAM ownership is enough, but the real failure is policy discontinuity. The identity team may govern entitlements, while platform and operations teams manage vaults, certificates, and session brokers without a shared decision model. That makes audit evidence incomplete and revocation slow. The problem is not abstract: NHI incidents frequently start with one control being bypassed and end with several others failing to compensate, as seen across the 52 NHI Breaches Analysis. In practice, many security teams discover the ownership gap only after a secret has already been used in a live session.

How It Works in Practice

The accountable function is usually the identity and security team, but effective governance only works when it defines control boundaries across the full privileged access chain. Current guidance suggests treating secrets, certificates, and sessions as one policy domain rather than three disconnected tools. That means the team responsible for privileged access should define approval rules, lifecycle requirements, logging expectations, and revocation triggers, while platform teams implement the technical integrations.

A workable model starts with unified policy intent. Privileged access should be granted only when the system can verify who or what is requesting access, what secret or certificate is being used, and whether the session is still within approved parameters. For example, a certificate issued to an automation workload should be tied to a workload identity, a short time-to-live, and a revocation path that also closes any associated session. This is where standards such as the NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 help translate governance into operational controls.

• Assign one accountable owner for the policy, even if multiple teams operate the tooling.
• Bind secret issuance, certificate validity, and session duration to the same approval record.
• Automate revocation when a secret is rotated, a certificate expires, or a session deviates from policy.
• Track evidence centrally so audits can show what was approved, what was used, and what was terminated.

For implementation patterns, the operational lessons in the 230M AWS environment compromise and the Shai Hulud npm malware campaign show why runtime control matters more than static policy alone. These controls tend to break down in CI/CD-heavy environments because secrets, certificates, and sessions are created and consumed too quickly for manual oversight.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance faster delivery against stronger governance. That tradeoff is most visible in hybrid estates, where one team owns cloud identity, another owns the secrets manager, and a third owns session brokering. There is no universal standard for this yet, but current practice increasingly favors a single policy owner with delegated technical administration rather than shared accountability without clear decision rights.

Edge cases usually appear where machine identities behave like human privileged users. Long-lived certificates for legacy services, break-glass accounts, and service-to-service sessions can all fall outside traditional PAM review cycles. In those cases, the accountable team should still define the policy, but exceptions need explicit expiry dates, compensating monitoring, and post-use validation. The guidance becomes harder to apply when certificates are embedded in appliances or when sessions are brokered by tools that cannot emit complete audit logs. In those environments, the policy should be simplified before it is expanded, because fragmented evidence is often worse than no evidence at all.

For broader context on why secrets sprawl and fragmented ownership keep driving incidents, see the State of Secrets in AppSec and the Ultimate Guide to NHIs. Those references reinforce the same operational lesson: accountability without unified control coverage creates blind spots that attackers exploit quickly.

Related resources from NHI Mgmt Group

• Who is accountable when privileged ERP access allows an inappropriate change to financial or supplier data?
• Who is accountable when a web application leaks sensitive files or bypasses access controls?
• Who is accountable for access governance when ERP cloud controls fail an audit?
• Who should be accountable for access governance when enterprise API tools use SCIM, domain capture, and domain lock together?