What breaks when organisations cannot see all of their non-human identities?

Why This Matters for Security Teams

When organisations cannot see all of their non-human identities, they lose the ability to govern access as a system, not just as a collection of accounts. That matters because NHIs are often the machinery behind CI/CD, cloud workloads, APIs, bots, and service integrations. If discovery is incomplete, ownership is unclear, rotation becomes inconsistent, and stale secrets can sit outside review cycles for months. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into their service accounts, which explains why control failures often persist until something breaks.

The practical impact is broader than credential sprawl. Hidden identities also undermine NIST Cybersecurity Framework 2.0 goals around governance, access control, and response because teams cannot protect what they have not enumerated. The problem is visible in real incidents such as the Schneider Electric credentials breach and JetBrains GitHub plugin token exposure, where exposed machine credentials created downstream risk far beyond the original system.

In practice, many security teams encounter missing NHI ownership only after a secret has already been used from an unexpected workload or region.

How It Works in Practice

Discovery gaps break the lifecycle in several places at once. If an identity is not in inventory, it is unlikely to be tied to a business owner, tagged to a system, or assigned a renewal cadence. That means access review, rotation, and offboarding all become guesswork. The organisation may still have PAM tooling, RBAC policies, and vaults, but those controls do not help if the underlying workload identity is invisible or duplicated across environments.

Effective practice starts with establishing a complete inventory of NHIs, then mapping each identity to its workload, purpose, secret type, and renewal owner. Current guidance suggests aligning this to a repeatable governance loop: discover, classify, assign ownership, reduce standing privilege, and verify rotation. For cloud and automation-heavy environments, teams should also distinguish between long-lived static secrets and just-in-time credential patterns. Ephemeral credentials are much easier to revoke when the task ends, while static secrets tend to linger and expand blast radius.

That is also where workload identity matters. Standards-oriented approaches such as SPIFFE and OIDC help prove what a workload is at runtime, instead of relying only on a secret that may already be copied into scripts or pipelines. For policy structure, NIST Cybersecurity Framework 2.0 is useful for framing governance, protection, and detection, while identity-specific guidance is better informed by NHI-focused research and incident patterns like the JetBrains GitHub plugin token exposure case.

• Inventory all service accounts, API keys, tokens, certificates, and bot identities.
• Bind every NHI to a named owner, purpose, and system of record.
• Rotate or replace long-lived secrets with short-lived issuance where possible.
• Use runtime policy checks so access reflects current context, not just a saved role.

These controls tend to break down when identities are created automatically by CI/CD, ephemeral cloud workloads, or SaaS integrations because the inventory lags the real environment.

Common Variations and Edge Cases

Tighter NHI control often increases operational overhead, requiring organisations to balance visibility against automation speed. That tradeoff is real in environments where developers spin up temporary credentials frequently or where third-party tooling creates identities without a central approval flow. There is no universal standard for this yet, but current guidance suggests using risk-based treatment rather than trying to force every NHI into the same process.

One common edge case is service accounts that are technically “known” but not effectively governed because their purpose has changed over time. Another is secrets embedded in code, config files, or deployment tooling, where discovery may reveal the identity but not the full blast radius. In those cases, visibility is only the first step; teams still need to decide whether the identity should be converted to a workload identity, moved to JIT provisioning, or retired entirely. The risk is especially high when secrets are shared across multiple systems, because a single compromise can become a multi-system access path.

For organisations building toward ZTA, hidden NHIs also weaken the assumption that every request can be continuously verified. The most useful response is usually to pair discovery with ownership, then shrink standing privilege over time. The NIST Cybersecurity Framework 2.0 helps organise that work, but the operational lesson from incidents like the Schneider Electric credentials breach is simple: hidden identities tend to fail first where automation is fastest and review is weakest.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot see their non-human identities?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?