Yes. New vaults add new trust edges, new policies, and new places where secrets can be copied or exposed. If security does not approve that onboarding, the enterprise is expanding identity risk without a governance checkpoint. Vaults are part of the identity estate, not just infrastructure plumbing.
What makes vault onboarding an identity governance decision?
Vault onboarding is not just a platform request. It creates a new trust boundary for credentials, decides who can administer and approve access, and defines how secrets are discovered, stored, rotated, and retired. If those choices are made outside governance, the organisation is effectively granting a new identity control surface without accountability, review, or lifecycle ownership.
The practical test is whether the vault will hold material secrets, certificates, or tokens that can authorise access to production systems. If yes, onboarding should follow the same scrutiny you would apply to a new identity repository or access path, including ownership, segregation of duties, and reviewability.
That is why vault onboarding belongs alongside identity governance and access governance decisions, not buried inside infrastructure implementation. When a vault becomes the authoritative place where secrets are issued, copied, or retired, it shapes the enterprise’s control over privilege just as much as an identity platform or access review process does. NHIMG’s IAM and IGA Basics is a useful reference for the boundary between access administration and governance.
What changes when a vault becomes part of the identity estate?
A vault changes the identity estate because it becomes a control point for the credentials that let systems act. That means onboarding is really about defining ownership, permitted uses, approval paths, and the conditions under which a secret can be created, copied, exported, rotated, or revoked. A vault with weak policy boundaries can become a privileged shortcut around normal identity controls.
This matters most when multiple teams rely on the vault for application credentials, service credentials, or signing material. In that case, the vault is not merely storing secrets, it is mediating the lifecycle of access itself. The onboarding decision should therefore specify which identity domains are in scope, who can request exceptions, and how access is reviewed over time. NHIMG’s Guide to the Secret Sprawl Challenge is relevant because vault sprawl and secret sprawl often grow together when governance is weak.
Vault onboarding should also define the failure mode for migration and decommissioning. If the old secret store remains active after the new vault is introduced, you have two places where the same secret can live, which weakens revocation and makes ownership unclear. That is an identity governance problem, not just a migration detail. NHIMG’s Joiner-Mover-Leaver (JML) Guide reinforces the lifecycle logic that should apply when secrets and access paths are added or removed.
How should organisations govern vault onboarding in practice?
The strongest approach is to treat onboarding as an approval gate with defined control evidence, not as a one-time technical setup. The decision should establish who owns the vault, which teams may store material secrets there, what logging and review evidence is required, and what conditions trigger reapproval or retirement. That keeps the vault aligned to governance expectations instead of ad hoc team preference.
What to verify: confirm the vault has an accountable owner, documented approval criteria, rotation and revocation processes, and a clear list of systems and secret classes it may manage. If those cannot be demonstrated before go-live, the onboarding is incomplete.
Decision rule: if the vault can protect production credentials or signing material, require identity governance sign-off before any production secret is migrated into it. If it only stores low-risk non-production material, the control bar can be lighter, but the ownership and lifecycle expectations should still be explicit.
Practitioner takeaway: Treat vault onboarding as a governance gate because the vault changes how access is granted, reviewed, and revoked. The key question is not whether the vault works, but whether the organisation can still explain and control who can use the secrets inside it.
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 surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Vault onboarding governs secret lifecycle and rotation for authenticators. |
| AC-2 — Account Management | Vault approval and ownership affect who may create and use privileged secrets. | |
| AU-2 — Event Logging | Vault governance depends on auditable evidence for secret access and changes. | |
| Recommendation — Define vault onboarding rules that control secret issuance, rotation, and revocation. Tie vault access to approved accounts and reviewable ownership. Log vault access, policy changes, and secret lifecycle events for review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Vault onboarding sets access rules for secrets and privileged administration. |
| A.5.18 — Access rights | Vault onboarding determines how access rights are granted, reviewed, and removed. | |
| Recommendation — Define access rules for vault administration and secret use before onboarding. Review and revoke vault-related access rights on a defined cadence. | ||
| CIS Controls v8 | CIS-5 — Account Management | Vaults introduce privileged credentials that need controlled lifecycle management. |
| Recommendation — Track and govern vault access as part of account and privilege management. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Vault onboarding should reduce secret lifetime and unmanaged exposure. |
| NHI-05 — Overprivileged NHI | A vault can concentrate excessive privilege if onboarding lacks governance. | |
| Recommendation — Prefer short-lived secrets and enforce rotation during vault onboarding. Limit vault permissions to the minimum required for each secret class. | ||
Practitioner Guidance
What to prioritise: start with ownership, scope, and lifecycle rules before implementation detail. A vault that has strong cryptography but unclear approval and revocation rules can still increase identity risk.
What good looks like: each onboarded vault has a named business owner, a security approver, defined secret classes, and a process for reviewing privileged use and exceptions. The vault should also be visible in the broader identity inventory so it is not treated as an invisible control island.
Common mistake: teams often treat vault onboarding as a platform deployment and skip the governance decision until after secrets are already migrating. By then, the organisation has usually accepted the control surface without proving who owns it or how it will be governed.
Practitioner takeaway: If a vault can hold credentials that confer production access, onboarding it is a governance decision first and an engineering decision second.
Related resources from NHI Mgmt Group
- Should organisations treat PAM as a vault problem or an identity governance problem?
- Why is it important to integrate identity and data governance?
- When should organisations treat an NHI as a high-priority risk?
- Should organisations prioritise external exposure or internal credential governance first?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org