Notifications
Clear all
Topic starter
12/06/2026 12:50 am
TL;DR: Credential management still relies on strong passwords, MFA, SSO, PAM, and vaulting, but Zluri’s guide shows the real problem is lifecycle control across growing credential populations. The case for tighter NHI governance is no longer theoretical when 96% of organisations still store secrets outside vaults and 97% of NHIs carry excessive privileges.
NHIMG editorial — based on content published by Zluri: Security & Compliance Credential Management: The Ultimate Guide
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: What breaks when credentials are stored outside a secrets manager?
A: When credentials live in code, config files, or CI/CD systems, they bypass the controls that make secrets governable.
Q: Why do service accounts and API keys create outsized IAM risk?
A: Service accounts and API keys often outlive the task, team, or vendor relationship that created them.
Q: How do organisations know if credential management is actually working?
A: Look for evidence that secrets are vaulted, rotated, and revoked on time, and that orphaned credentials are being removed quickly after the owner changes.
Practitioner guidance
- Map every credential repository and spill point Inventory code repositories, CI/CD variables, configs, shared documents, endpoints, and ticketing systems for stored secrets, then remove any persistent credential that can be replaced with vault-backed retrieval.
- Tie rotation to identity lifecycle events Rotate API keys, tokens, and certificates when roles change, vendors offboard, or workloads are reconfigured, instead of relying on calendar-based rotation alone.
- Separate privileged access from credential persistence Use PAM for session control, but enforce short-lived issuance, revocation, and ownership for the underlying secret so a logged session does not mask a durable compromise path.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanations of the credential management lifecycle, from creation through deletion
- Plain-language breakdowns of MFA, SSO, PAM, and credential vaulting as separate control types
- Examples of how zero trust and least privilege are positioned inside the credential management model
- Broader product context around Zluri's access management approach and how it is framed for buyers
👉 Read Zluri's guide to credential management and secure access controls →
Credential management and NHI sprawl: where controls are breaking?
Explore further
12/06/2026 10:19 am
Credential management fails when organisations treat credentials as objects to store rather than identities to govern. The article describes passwords, MFA, SSO, PAM, and vaulting as separate mechanisms, but the real risk is the lifecycle gap between issuance, use, rotation, and revocation. That gap is where service accounts and API keys become long-lived access paths instead of governed identities. Practitioners should treat every credential as an identity with an expiry, not a static secret.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when exposed credentials are used in an attack?
A: Accountability usually sits across IAM, security operations, application owners, and platform teams because the failure is rarely isolated. If the credential was created, stored, or shared outside policy, ownership needs to be explicit before the incident happens. Post-incident, the key question is which control failed to revoke access before misuse became possible.
👉 Read our full editorial: Credential management is failing where NHI risk is expanding
