Who should own secrets governance in a zero trust programme?

Why This Matters for Security Teams

secrets governance in a zero trust programme is not just a hygiene task. It determines whether the organisation can actually constrain access when identities are non-human, workloads are ephemeral, and credentials are embedded in CI/CD, cloud services, and automation. Zero trust depends on continuous verification, but static secrets create standing access that bypasses that model. NIST’s NIST SP 800-207 Zero Trust Architecture makes this dependency clear: trust must be evaluated at the moment of access, not assumed because a secret already exists.

That is why ownership cannot sit in one silo alone. IAM teams may define identity policy, PAM may govern elevation, and platform teams often operate the systems that actually store or inject secrets. If those responsibilities are not coordinated, rotation fails, revocation lags, and audit trails become incomplete. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets proliferate across pipelines and services once ownership is unclear. In practice, many security teams discover secret sprawl only after a leak, not through intentional control design.

How It Works in Practice

The most effective zero trust programmes treat secrets governance as a shared operating model with explicit accountability, not a single team’s backlog item. IAM usually owns identity policy and authentication standards, PAM owns privileged secrets and elevation workflows, and platform or cloud engineering owns the technical control plane where secrets are issued, mounted, injected, or revoked. Security governance defines the standard, measures compliance, and resolves exceptions. That division maps well to the access-first logic of zero trust and aligns with the OWASP Non-Human Identity Top 10, which highlights how poorly managed machine credentials create persistent attack paths.

Operationally, the programme should define four control points:

• Issuance: who approves a secret, for what workload, and with what expiry.
• Rotation: who sets TTLs, enforces automatic renewal, and validates downstream updates.
• Revocation: who can invalidate secrets immediately after compromise, role change, or task completion.
• Auditability: who can prove where the secret lived, who used it, and when it was removed.

For machine-to-machine access, many teams are now reducing long-lived secrets in favour of workload identity and just-in-time credentials. NHIMG’s Guide to SPIFFE and SPIRE is a useful reference point here because it frames identity around cryptographic proof of workload identity rather than reusable shared secrets. Current guidance suggests this is most effective when combined with policy-as-code and central logging, so that revocation and replacement can be enforced automatically. These controls tend to break down when legacy applications require hard-coded credentials because rotation and revocation become manual, brittle, and slow.

Common Variations and Edge Cases

Tighter secrets governance often increases operational overhead, so organisations have to balance automation against application compatibility and release speed. That tradeoff is especially sharp in hybrid environments where some systems support dynamic secrets and others still depend on static configuration files or environment variables.

There is no universal standard for ownership boundaries yet, but best practice is evolving toward a federated model: one accountable control owner, several delegated operators, and shared metrics. In highly regulated environments, PAM may own approval for high-risk secrets while platform teams own enforcement in Kubernetes, cloud IAM, and CI/CD. In fast-moving engineering orgs, the platform team often implements the tooling while IAM and security set the policy and retention rules.

Edge cases usually appear in third-party integrations, emergency access, and developer tooling. Vendor credentials, API keys in pipelines, and temporary break-glass secrets all require explicit exception handling. The key test is whether the organisation can answer, without delay, who issued the secret, who can revoke it, and how quickly misuse would be detected. NHIMG’s The 2024 State of Secrets Management Survey shows why this matters: secrets sprawl remains a major concern, and fragmented management is still a common dissatisfaction driver.

Related resources from NHI Mgmt Group

• Who should own CIEM governance in an identity programme?
• Who should be accountable for identity governance in a Zero Trust model?
• Who should own lifecycle governance in a modern identity programme?
• Who should own AI agent privilege governance in an identity programme?