TL;DR: Machine identities now outnumber human identities 45 to 1, while 68% of organisations expect more SaaS deployments and 80% will use three or more cloud providers, according to CyberArk research. That scale makes unmanaged secrets and machine access a structural zero trust gap, not an edge case.
At a glance
What this is: This is a CyberArk analysis arguing that machine identities and their secrets must be governed as part of zero trust because their scale and dynamism outpace manual control.
Why it matters: IAM, IGA and PAM teams need to treat machine identities as first-class governance objects because unmanaged secrets and weak lifecycle controls widen the attack surface across cloud and DevOps environments.
By the numbers:
- Machine identities now outnumber human identities by a factor of 45:1.
- The CyberArk 2023 Identity Security Threat Landscape 2023 report finds that organizations expect an increase of 68% in the number of SaaS applications deployed in their environment.
Context
Zero trust assumes every identity must be verified continuously, but that model weakens when machine identities are created faster than teams can inventory, govern and revoke them. In this article, CyberArk argues that machine identities are not a peripheral control issue but a core part of zero trust strategy.
The governance gap is not abstract. Machine identities rely on secrets, API keys, cloud access keys and certificates, and those credentials now underpin hybrid cloud, SaaS and DevOps workflows at a scale manual processes struggle to follow. When lifecycle control is weak, the zero trust boundary is enforced for people while machines remain under-governed.
The article’s core point is that machine identity security belongs in identity governance policy, not as a separate infrastructure afterthought. That framing is typical for modern enterprise environments, where machine-to-machine communication has become routine rather than exceptional.
Key questions
Q: Why do machine identities challenge zero trust architectures?
A: Because zero trust depends on continuous verification, while many machine identities are issued once and then trusted for far too long. If certificates and keys are broad, stale, or hard to revoke, the architecture becomes trust-on-first-use in practice. Strong machine identity governance is what makes zero trust believable for non-human access.
Q: What breaks when machine identities are not governed like first-class identities?
A: Access becomes persistent, hard to attribute, and easy to overextend across systems. Without lifecycle control, a service account or API key can survive long after its purpose changes, creating a standing credential risk that traditional human IAM reviews are unlikely to catch. The result is larger blast radius and weaker accountability.
Q: How do teams reduce risk from machine identities in cloud environments?
A: Start with inventory, because you cannot govern what you cannot see. Then remove default credentials, shorten token lifetimes, restrict privileges to the task at hand and monitor for unusual use patterns. Machine identities should be treated as production assets with owners, scope limits and lifecycle controls.
Q: What should security teams do first when hardcoded secrets are discovered in code or Git history?
A: The first step is to identify every place the secret appears, assign ownership, and revoke or rotate it before treating the finding as closed. Discovery without invalidation leaves the credential usable. Teams should also check dependent systems, because one leaked secret may authenticate to cloud, source control, CI/CD, or other downstream services.
Technical breakdown
Why machine identities expand the zero trust attack surface
Machine identities are non-human identities used by applications, workloads, scripts, virtual machines and devices to authenticate to other systems. They depend on secrets, API keys, certificates and cloud access keys, which means the security problem is not just access, but credential lifecycle and authorization scope. In a distributed environment, each new workload can create multiple identities and credential paths. Zero trust assumes trust is continuously re-established, yet machine identities often persist with broad access and limited oversight. The technical challenge is that scale and velocity outstrip manual inventory, renewal and revocation.
Practical implication: treat machine identity inventory and credential lifecycle as part of zero trust enforcement, not a separate admin task.
Why hard-coded secrets and manual rotation fail in hybrid cloud
The article links hybrid and multi-cloud environments to rapid secret proliferation. Hard-coded secrets are especially dangerous because they are embedded in application code, automation scripts or build pipelines, which makes discovery and revocation slow once exposed. Manual rotation cannot keep pace with DevOps and cloud change rates, so credentials can survive long after the workload they support has changed. The result is a wider exposure window and weaker auditability. A machine identity programme needs automated issuance, renewal and revocation because the lifecycle itself is the control surface.
Practical implication: move from manual secret handling to automated issuance, renewal and revocation for workload credentials.
What centralized machine identity governance changes technically
Centralized management gives security teams a way to see which machines and applications use which secrets, whether identities are managed or unmanaged, and where certificates are provisioned. That visibility matters because zero trust depends on knowing which entity is speaking and whether it should still be trusted. Regular audits and monitoring add detection for abnormal or unauthorized activity, while centralized rotation reduces the chance that a single compromised secret remains usable across multiple services. The article also points to integration in CI/CD pipelines, which is where identity control can be built into deployment flows instead of bolted on later.
Practical implication: enforce machine identity controls in CI/CD and monitoring workflows so trust decisions happen at issuance and deployment time.
Threat narrative
Attacker objective: The attacker seeks to use trusted machine credentials as a durable entry path into sensitive enterprise systems and data.
- Entry occurs through unmanaged machine identities or exposed secrets that already exist in cloud, SaaS or DevOps workflows.
- Credential access follows when hard-coded or poorly rotated secrets are discovered and used to authenticate as the workload or application.
- Escalation and lateral movement become possible because the compromised machine identity may already have access to multiple resources and services.
- Impact is unauthorized access to sensitive data and services across the enterprise environment.
Breaches seen in the wild
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Machine identity governance is not a separate control layer, it is the trust substrate for zero trust. Zero trust only works when every identity that can authenticate and authorize itself is continuously governed, and that includes workloads, scripts, certificates and service accounts. Once machine identities outnumber human identities at enterprise scale, leaving them outside governance means the architecture is complete only for people, not for the systems that actually move data. Practitioners should treat machine identity lifecycle as foundational security architecture, not an adjunct control.
Hard-coded secrets create identity debt that zero trust cannot absorb. A secret embedded in code or automation is not just a credential risk, it is a governance failure because it breaks traceability, revocation and ownership. When secrets are distributed across hybrid and multi-cloud environments, the organization loses the ability to answer basic lifecycle questions about who uses what and for how long. The practitioner implication is that identity governance must follow the credential, not just the account.
Visibility is the real prerequisite for machine identity control. The article’s 62% visibility figure points to a deeper problem: teams cannot secure what they cannot inventory, classify and monitor. That gap becomes more damaging when machine identities are created dynamically through DevOps and cloud automation. The implication is that machine identity policy must be tied to discovery and telemetry, or governance remains aspirational.
Centralized secrets governance is becoming the practical zero trust control point. In dynamic cloud environments, the decisive issue is no longer whether an identity exists, but whether it can be issued, renewed, revoked and audited at machine speed. That shifts identity programmes toward lifecycle orchestration, especially where CI/CD and hybrid cloud expand the number of trust relationships faster than human teams can review them. Practitioners should reframe machine identity management as a continuous control plane, not a periodic audit exercise.
Machine identity sprawl is a governance signal, not just an operations symptom. When organisations scale SaaS, cloud providers and automated deployments faster than manual control can follow, the identity layer becomes fragmented by design. That fragmentation weakens policy enforcement across access, monitoring and revocation. The implication for IAM, IGA and PAM leaders is to measure machine identity maturity as part of zero trust readiness, because unmanaged scale will otherwise define the control boundary.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- The 2025 Gartner Machine Identity Management in a Hybrid, Automated AI World Survey showed that 32% of organizations use mostly automated methods to manage credentials and only 1% use fully automated methods.
- Read next: Ultimate Guide to NHIs
What this signals
Machine identity governance is now a zero trust readiness issue. Once machine identities outnumber human identities by 25x to 50x in modern enterprises, the gap is not volume alone but control coverage. IAM, IGA and PAM teams need a governance model that can follow workload credentials through creation, rotation, renewal and revocation.
Identity governance must move closer to issuance time. Access reviews assume a privilege persists long enough to be certified, but machine identities in cloud and DevOps environments are created, used and rotated too quickly for periodic review to carry the full burden. The practical implication is that policy enforcement has to happen at provisioning and rotation points, not only at recertification.
For practitioners
- Inventory machine identities and secrets Build a current inventory of applications, scripts, workloads, virtual machines and devices that authenticate with machine credentials, then classify the secrets and certificates they use.
- Automate credential issuance and revocation Replace manual handling with automated issuance, renewal and revocation so machine credentials do not outlive the workload or service they support.
- Embed controls into CI/CD pipelines Add identity checks and secret handling controls into build and deployment pipelines so machine trust is enforced before production rollout.
- Audit for hard-coded secrets and unmanaged access Search code, configuration and automation artefacts for embedded secrets, then revoke any credentials that cannot be traced to an owner or lifecycle process.
- Monitor abnormal machine activity Use monitoring and threat analytics to spot unusual authentication patterns, unexpected service-to-service calls and unauthorized use of managed credentials.
Key takeaways
- Machine identities are part of the zero trust trust boundary, and leaving them outside governance creates a structural control gap across cloud and DevOps environments.
- The main risk is not just scale but lifecycle drift, where hard-coded or unmanaged secrets outlive the workloads they were meant to secure.
- Practitioners need discovery, automated renewal and revocation, and pipeline-integrated controls if they want zero trust to cover non-human access.
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 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on exposed and hard-coded secrets used by machine identities. |
| NHI-05 — Overprivileged NHI | The article warns that machine identities often hold more access than teams can govern well. | |
| NHI-07 — Long-Lived Secrets | The article emphasizes automated rotation, renewal and revocation to stop secrets from lingering. | |
| Recommendation — Scan for leaked machine secrets and revoke any credential that cannot be traced and rotated promptly. Review machine identity entitlements and reduce access scope to the minimum required for each workload. Automate secret rotation and revocation so machine credentials do not outlive the systems they support. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing access permissions for machine identities in zero trust environments. |
| Recommendation — Map machine identity permissions and authorizations to PR.AA-05 and audit them continuously. | ||
| CIS Controls v8 | CIS-5 — Account Management | Machine identity lifecycle management is an account management problem at enterprise scale. |
| Recommendation — Apply account management controls to track, revoke and govern machine identities and their secrets. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.
Published by the NHIMG editorial team on May 29, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org