Centralised credential control stores and brokers privileged secrets, while real access governance enforces who can use them, where they can be used, and when they are removed. A team can have strong vaulting and still leave Kubernetes or cloud access outside the governed lifecycle. Governance is about scope and enforcement, not storage alone.
Why Credential Control and Access Governance Are Not the Same Thing
Centralised credential control is about managing the secret itself, where it is stored, how it is rotated, and how it is issued to systems or people. Real access governance is about the entitlement around that secret: who may use it, under what conditions, across which environments, and when access must be removed. A strong vault can exist without strong governance.
The practical difference is that centralisation reduces sprawl, while governance reduces unauthorised use. A team can move secrets into one platform and still leave standing access, unmanaged service accounts, or stale Kubernetes permissions untouched. That is why a credential vault is a control point, not a complete access model.
Seen through an identity lens, governance is the policy layer that constrains the credential lifecycle and the access paths it enables. If the same secret can authenticate into production, development, and a third-party tool with no review trail, the organisation has central storage but not meaningful control over privilege.
What Real Governance Adds Across Cloud, Kubernetes, and Service Accounts
Governance becomes real when it enforces lifecycle rules, scope boundaries, and removal events. That means binding access to ownership, environment, role, and purpose, then revoking it when the task, operator, or workload changes. It also means knowing where credentials are consumed, not just where they are kept. NHIMG’s IAM and IGA Basics is useful here because the distinction between authentication, authorization, and access governance is the core issue.
In practice, cloud and Kubernetes expose the weakness fast because secrets are only one part of the access path. If workloads keep long-lived tokens, cluster roles, or cross-account privileges after the original need has passed, the vault has done its job but governance has failed. NHIMG’s IAM and IGA Basics and Joiner-Mover-Leaver (JML) Guide both reinforce that access decisions need a lifecycle, not just a storage location.
This is also why access review and offboarding matter more than centralisation alone. A credential can be perfectly vaulted and still outlive the service account, pipeline, or human owner that should have triggered its removal. Governance is the discipline that ties the secret to a business or operational need and then ends that need cleanly.
How Practitioners Tell the Difference in a Real Environment
The fastest test is to ask whether the control can answer four questions: who may use the credential, from where, for what purpose, and until when. If the answer is only “it is in the vault,” then the organisation has centralised credential control, not access governance. If the answer also includes approval, scope, expiry, review, and revocation, the control is closer to actual governance.
Another test is blast radius. If one vaulted secret can still open many systems because permissions were never scoped down, centralisation has made the secret easier to manage but not safer to use. That is why role design, segregation of duties, and environment separation matter when teams want access governance rather than a prettier secret store. NHIMG’s Role Mining and Role Design Guide is a natural next step when the real problem is overbroad entitlement design.
For teams operating at scale, governance also needs evidence. You should be able to show access review outcomes, ownership of each credential, and the event that caused revocation or renewal. Without that evidence, the system may be centrally managed, but it is still guesswork whether access is actually governed.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Defines lifecycle control over accounts that use credentials and secrets. |
| IA-5 — Authenticator Management | Covers storage, rotation, and lifecycle of authenticators and secrets. | |
| AC-6 — Least Privilege | Access governance requires limiting how far a credential can be used. | |
| Recommendation — Tie each credential to an accountable account lifecycle and remove access on change or exit. Rotate, expire, and revoke authenticators on a managed schedule with ownership. Constrain each credential to the minimum scope needed for the approved task. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Centralised secrets still create risk when permissions stay too broad. |
| NHI-07 — Long-Lived Secrets | Credential control must address expiry and rotation, not storage alone. | |
| NHI-01 — Improper Offboarding | Governance must remove access when the owner or workload no longer needs it. | |
| Recommendation — Reduce each non-human credential to the narrowest viable permission set. Replace long-lived secrets with short-lived or rotated credentials wherever possible. Revoke credentials and related access immediately when the owning entity is decommissioned. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Directly fits the distinction between storing secrets and governing their use. |
| GV.OC-01 — Organizational Context | Access governance depends on defined ownership and business context for credentials. | |
| Recommendation — Enforce approval, scope, and revocation rules for every credentialed access path. Assign each credential to a business owner and use case before granting access. | ||
Practitioner Guidance
What to prioritise: Prioritise the access path, not the vault. First map where each credential is consumed, then decide what must be constrained by role, environment, expiry, and review.
What to verify: Verify that every privileged secret has an owner, a defined purpose, and a removal trigger. If you cannot show those three items, the credential is being stored, not governed.
Common mistake: Teams often treat secret centralisation as a finished control and stop before fixing standing permissions, stale service accounts, and cross-environment reuse. That leaves the highest-risk access paths intact.
Decision rule: If a credential can still reach production after its business purpose has ended, treat it as an access-governance failure even if the secret remains safely vaulted.
Practitioner takeaway: Good credential control reduces chaos, but only governance limits authority. The decisive question is not where the secret lives, but whether the organisation can prove who may use it, where, and when that access ends.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between human IAM controls and NHI governance?