The majority of NHIs are created automatically by automation tools, pipelines, and infrastructure-as-code. Terraform provisions IAM roles. CI/CD pipelines generate service accounts and tokens. Container orchestration platforms create service accounts automatically. Most are created without security review, owner assignment, or defined lifecycle.
Why This Matters for Security Teams
Most NHIs are not born through a security-approved request process. They are emitted by Terraform, CI/CD, Kubernetes, cloud services, and developer tooling because systems need machine credentials to function. That makes creation speed a feature of modern delivery, but also a governance gap. When identity creation is embedded in automation, ownership, purpose, and revocation can be skipped unless they are enforced by design.
This matters because uncontrolled creation scales faster than manual review. The Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and Top 10 NHI Issues shows how excess privilege and weak lifecycle controls become routine. In practice, many security teams encounter these identities only after a pipeline, cluster, or integration has already been compromised, rather than through intentional governance.
Current guidance from the NIST Cybersecurity Framework 2.0 and zero trust programs is to treat identity as a control point, not just a login mechanism. For NHIs, that means creation should be tied to policy, inventory, and lifecycle state from the first moment of issuance.
How It Works in Practice
In modern environments, NHI creation usually follows the workload rather than the other way around. A Terraform plan may create a cloud role, a CI/CD job may mint a token for deployment, or a container platform may bind a service account to a pod automatically. The challenge is not only that identities are created quickly. It is that they are often created with defaults that are too broad, too durable, or too detached from business ownership.
A better model is to make creation conditional on security context. That includes naming an owner, defining the workload purpose, setting an expiration window, and requiring a review path for privileged roles. For machine identities, the practical control set usually includes:
- policy-driven issuance instead of ad hoc creation
- short-lived credentials where possible, especially for deployment and agent workflows
- workload identity binding so the identity proves what the workload is, not just what secret it holds
- automatic inventory updates so the NHI can be tracked from birth to retirement
- revocation hooks when a pipeline, pod, or cloud stack is destroyed
This is where the 52 NHI Breaches Analysis is useful: it reinforces that weaknesses rarely begin with exotic exploits, but with creation patterns that outpace governance. For implementation teams, the closest external benchmark is still the NIST Cybersecurity Framework 2.0, especially around inventory, access control, and continuous monitoring. These controls tend to break down in fast-moving multi-cloud estates because identity creation is distributed across tooling that security does not centrally own.
Common Variations and Edge Cases
Tighter control over NHI creation often increases delivery overhead, requiring organisations to balance automation speed against identity discipline. That tradeoff becomes visible in serverless, ephemeral containers, and cross-account integrations where identities are created and discarded rapidly. Best practice is evolving, and there is no universal standard for every platform, but the direction is consistent: the more autonomous the workload, the more important it is to constrain how its identity is issued.
One common edge case is developer-owned infrastructure, where teams assume the platform will handle identity safely. Another is third-party or vendor-managed automation, where NHIs may be created outside the core security approval path. A third is high-velocity CI/CD, where long-lived tokens are reused because short-lived alternatives were never wired into the pipeline. The Cisco DevHub NHI breach is a reminder that exposed machine credentials often become a breach path when ownership and rotation are unclear.
For organisations aligning to NIST Cybersecurity Framework 2.0, the practical question is not whether automation creates NHIs. It is whether every identity created by automation is immediately governed as an asset with a known owner, scope, and end date.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Creation without ownership or review maps to NHI identity governance gaps. |
| NIST CSF 2.0 | PR.AC-1 | Automated issuance still needs access control and identity governance. |
| CSA MAESTRO | IAM-2 | Agentic and workload identities need controlled issuance and lifecycle management. |
Issue workload identities through policy, then revoke them automatically at workload end.
