Notifications
Clear all
Topic starter
06/06/2026 2:11 am
TL;DR: Sixty-eight percent of breaches involve a non-malicious human element, and the source article argues that credential vaulting reduces exposure by centralising secrets, enforcing rotation, and improving auditability across users, service accounts, and third parties, according to Imprivata. The governance issue is not storage alone, but whether organisations can control how credentials are accessed, used, and retired.
NHIMG editorial — based on content published by Imprivata: credential vaulting and privileged access security
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
Questions worth separating out
Q: What breaks when credential vaulting is used without lifecycle governance?
A: Vaulting without lifecycle governance preserves control over storage but not over ownership, expiry, or offboarding.
Q: Why do shared service accounts still create risk even when secrets are vaulted?
A: Shared service accounts remain risky because the vault may protect the secret while multiple systems continue to use the same identity.
Q: How do security teams know if vaulting is actually reducing exposure?
A: Look for fewer direct secret disclosures, shorter credential lifetimes, and a higher percentage of retrievals tied to named approvals or workflows.
Practitioner guidance
- Map every vaulted secret to a named owner Require an accountable business or technical owner for each password, service account, API key, certificate, and SSH key.
- Separate human, vendor, and workload access paths Use different approval logic, session controls, and revocation rules for employees, third parties, and automated processes even when they share the same vault platform.
- Enforce rotation after use for high-value secrets Set rotation triggers for privileged credentials that are retrieved for administrative work, break-glass activity, or third-party support sessions.
What's in the full article
Imprivata's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how credential vaults centralise passwords, service accounts, API keys, and SSH keys across environments
- The article's access-security framing for privileged access, third parties, and AI agents using the same platform
- The vendor's explanation of audit logging and compliance support for HIPAA, PCI DSS, and SOX
- The article's implementation-oriented view of integrating vaulting with SSO and PAM workflows
👉 Read Imprivata's analysis of credential vaulting for privileged access security →
Credential vaulting: what IAM teams still miss about access control?
Explore further
06/06/2026 3:43 am
Credential vaulting is an access-governance control, not just a storage control. The article correctly frames the problem as more than password protection because the real issue is reuse, visibility, and accountability across multiple systems. Centralisation helps, but only if access is brokered with policy and not merely parked in a secure repository. Practitioners should treat the vault as part of the control plane for secrets, not the endpoint of the control.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: How should organisations govern vaulted credentials for third parties and automation?
A: Treat third-party and automated access as separate governance paths with distinct ownership, approval, and revocation rules. Third parties need time-bounded access and explicit offboarding, while automation needs tightly scoped machine identity controls. A shared vault does not eliminate the need to distinguish actor type.
👉 Read our full editorial: Credential vaulting and the identity gap in human and machine access
