What should organisations do when machine identities already outnumber human identities?

Treat that as a governance design change, not just an inventory problem. Rebuild identity controls around lifecycle enforcement, automated renewal and revocation, and continuous drift detection so the programme matches machine speed instead of reporting on it after the fact.

Why This Matters for Security Teams

When machine identities outnumber human identities, the problem stops being “too many accounts” and becomes an operating model issue. Service accounts, API keys, workload tokens, and certificates can be created faster than they are reviewed, which means inventory alone will always lag the real exposure surface. NHIMG research shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, and that scale is where manual review, periodic recertification, and spreadsheet-based ownership break down.

Security teams often assume existing IAM controls will scale if they simply apply them more broadly. In practice, machine identities behave differently from people: they authenticate continuously, integrate across pipelines, and persist long after the application owner changes. That is why lifecycle enforcement, not just access approval, becomes the core control objective. NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces this shift by treating identity protection as an ongoing governance function rather than a one-time provisioning event. The practical lesson is that an organisation cannot secure what it cannot continuously account for.

In practice, many security teams encounter machine identity sprawl only after a secrets leak, privilege escalation, or failed offboarding has already occurred, rather than through intentional governance design.

How It Works in Practice

The operational response is to rebuild identity governance around the machine lifecycle: issue, bind, use, rotate, monitor, and revoke. That means every non-human identity should have an owner, purpose, expiry condition, and a defined revocation path. Where possible, replace long-lived static secrets with short-lived credentials and workload-bound tokens, because TTL matters differently for autonomous and highly automated systems. A secret that survives application changes for months becomes a latent credential risk, not a convenience.

Good practice also requires continuous drift detection. If a service account suddenly authenticates from a new pipeline, a new region, or a new tool chain, that behaviour should be evaluated in context, not only against a pre-approved role. Current guidance suggests pairing lifecycle controls with policy enforcement at the point of use, because machine identities are often embedded in code, CI/CD, and orchestration layers. NHIMG has documented how JetBrains GitHub plugin token exposure and Hard-Coded Secrets in VSCode Extensions show how quickly credentials leak when identities are baked into developer workflows.

• Inventory all machine identities, then assign an accountable service owner and a business purpose.
• Enforce automatic expiration and revocation for secrets, certificates, and API keys.
• Use continuous discovery to find shadow accounts, orphaned credentials, and stale integrations.
• Alert on privilege drift, unusual source systems, and identity reuse across environments.
• Map controls to NIST SP 800-53 Rev 5 Security and Privacy Controls so the programme is auditable, not ad hoc.

These controls tend to break down when identities are embedded across legacy apps, unmanaged pipelines, and third-party integrations because ownership and revocation paths are no longer technically enforceable.

Common Variations and Edge Cases

Tighter machine identity governance often increases operational overhead, so organisations must balance security gains against deployment friction and service uptime. That tradeoff is especially visible in environments with microservices, ephemeral jobs, and vendor-managed integrations, where frequent rotation can disrupt brittle dependencies if the rollout process is immature.

Best practice is evolving for shared service accounts and cross-team platform identities. There is no universal standard for this yet, but current guidance suggests reducing shared credentials wherever possible and compensating with stronger segmentation, conditional access, and explicit logging when sharing cannot be eliminated. The same applies to third-party and supply-chain identities: when an external tool holds standing access, the revocation window must be shorter and monitoring must be stricter than for internal workloads. NHIMG research on Code Formatting Tools Credential Leaks is a reminder that non-obvious tooling can become an identity distribution channel.

For organisations moving toward Zero Trust, the question is not whether machine identities exist in large numbers, but whether each one can be proven, constrained, and retired on demand. When that is not true, the identity programme is already behind the environment it is meant to control.

Related resources from NHI Mgmt Group

• 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?
• How should security teams govern non-human identities in Salesforce?