TL;DR: Machine identities now outnumber human users, AI-driven attacks are rising, and identity teams are struggling with complexity across expanding environments, according to Bravura Security’s 2025 IDSA Trends in Identity Security Report. The shift is no longer about user protection alone; identity programmes must govern automated access and machine-level trust assumptions.
At a glance
What this is: This is a 2025 identity security trends report showing machine identities overtaking human users, with AI-driven attacks and operational complexity widening the governance gap.
Why it matters: It matters because IAM, IGA, PAM, and cloud security teams must treat machine and workload access as a primary governance domain, not a side effect of user identity control.
By the numbers:
- The report is based on 512 identity and security professionals.
- Which identity controls would have prevented 43 percent of incidents.
Context
Machine identity is the governance problem created when services, workloads, tokens, APIs, and other non-human actors outnumber and outpace human users. In this report, Bravura Security argues that the center of gravity in identity security has moved away from user authentication and toward the control of automated access.
The practical issue is not just scale. Identity teams now have to govern growth in machine identities, AI-driven attack pressure, and operational complexity at the same time, while proving which controls reduce incidents rather than simply adding more tooling.
For IAM and security leaders, the report frames 2025 as a reset point. Programmes built around human user oversight alone will miss the identities that increasingly power infrastructure and create the largest exposure surface.
Key questions
Q: How can IAM teams bring machine identities into lifecycle governance?
A: Apply the same lifecycle discipline used for human access to service accounts, tokens, cloud services, and AI-connected identities. That means assigning owners, reviewing entitlements, tracking purpose, and revoking access when the identity is no longer needed. Machine identities should be governed as first-class access subjects, not as infrastructure leftovers.
Q: Why do machine identities create more risk than human identities in some environments?
A: Machine identities are often numerous, long-lived, and embedded in code or infrastructure. They are harder to review manually, easier to overlook during offboarding, and more likely to carry excessive privilege. That combination increases blast radius when a secret or token is exposed.
Q: What are the signs that machine identity governance is no longer keeping up?
A: Common signs include surprise certificate expirations, repeated manual renewals, inconsistent policy enforcement, and teams that cannot answer who owns a given key or trust anchor. If controls only produce occasional snapshots, the programme is already behind the pace of the environment.
Q: Should organisations prioritise Zero Trust for machine identities before broader IAM changes?
A: Yes, if machine identities are already driving a large share of your access surface. Zero Trust is most useful when it constrains the identities that can move laterally, call services, or carry long-lived privileges. If those identities remain over-privileged or unmanaged, broader IAM improvements will still leave the highest-risk access paths exposed.
Technical breakdown
Why machine identity governance now outweighs user-centric control
Machine identities include service accounts, API keys, tokens, certificates, and workload credentials that act independently of human logins. Their growth changes the scale and cadence of identity governance because these identities are often created automatically, used by systems rather than people, and spread across cloud and DevOps pipelines. That makes traditional user-centred review cycles insufficient. The important technical shift is not just volume, but lifecycle complexity: issuance, scope, rotation, offboarding, and reuse all happen differently for non-human actors.
Practical implication: inventory machine identities separately from human accounts and govern them through their own lifecycle controls.
Why AI-driven attacks increase pressure on identity controls
AI-driven attacks increase the speed and variability of identity abuse by helping attackers find weak trust paths, reuse exposed credentials, and exploit control gaps faster than manual methods. In practice, that raises the value of strong authentication for services and workloads, tighter authorisation boundaries, and better credential hygiene. The article does not describe a single exploit chain, but it does show that identity programmes now face a threat environment where automated abuse is part of the baseline, not an edge case.
Practical implication: tighten machine authentication, credential exposure monitoring, and privilege scope before attack volume grows further.
Why complexity is now a control failure, not just an operating cost
Complexity becomes a security issue when teams can no longer see what identities exist, who owns them, or which ones can still authenticate. In machine identity estates, fragmentation across platforms, cloud services, and application teams produces blind spots that weaken governance and delay remediation. The result is not just slower administration; it is a weaker assurance model. When identity control depends on manual reconciliation, the programme cannot keep pace with the environment it is supposed to govern.
Practical implication: reduce fragmentation in inventory, ownership, and policy enforcement so identity governance can keep pace with the environment.
Threat narrative
Attacker objective: The objective is to turn machine identity sprawl into broad, repeatable access that bypasses human-centric identity controls.
- Entry occurs when AI-driven attackers or automated abuse paths target exposed or weakly governed machine identity surfaces rather than human login flows.
- Credential access follows when service credentials, tokens, or other non-human secrets are discovered or reused across environments.
- Escalation happens when over-scoped machine access lets an attacker move from one workload or platform boundary into others.
- Impact is achieved by abusing automated trust at scale, expanding the attacker’s reach across infrastructure and identity workflows.
Breaches seen in the wild
- 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 has become the primary identity governance surface. Once non-human identities outnumber human users, the programme can no longer treat them as technical leftovers. The governance question shifts to whether ownership, lifecycle, and privilege are defined well enough to survive scale. IAM teams should assume machine identity volume is now a core architectural input, not a clean-up task.
Identity attack reduction now depends on controlling the machine estate, not just the workforce estate. The report’s 43 percent incident-prevention figure points to a familiar pattern: many incidents remain preventable if controls are applied where credentials and access actually live. In practice, the highest-value work sits in service accounts, tokens, and workload trust paths. Teams should re-rank identity investment around the assets attackers can reuse fastest.
Ephemeral trust debt is the new identity backlog. Machine identities accumulate security risk when credentials, ownership, and usage history outlive the business process that created them. That debt is harder to spot than user privilege creep because it is distributed across automation layers. Practitioners should treat unmanaged machine identity growth as an operational liability with direct security impact.
Machine identity governance cannot be borrowed from human IAM without distortion. Human access review, user lifecycle, and authentication assurance are necessary but insufficient for automated identities. The report reinforces that identity security now spans service accounts, APIs, and workload credentials that do not behave like employees. Practitioners should redesign governance to match the subject being governed, not the subject they are most familiar with.
Zero Trust only remains credible when it includes non-human trust paths. Near-universal Zero Trust adoption does not solve machine identity exposure if the programme still leaves service-to-service access largely implicit. The field is moving toward a model where identity control quality is judged by whether it can constrain automated trust relationships in real time. Teams should measure Zero Trust against machine access, not just user sign-in events.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Key Research and Survey Results
What this signals
Machine identity sprawl is now a programme design issue, not a niche technical problem. As machine identities overtake human users, the reader should expect ownership, lifecycle, and privilege scope to become board-level identity questions rather than implementation details. The most effective programmes will separate machine governance from user governance instead of forcing both into one review model.
Identity operations will keep lagging until control coverage matches the subject being governed. If your review cadence, offboarding process, and evidence model still assume human-paced access, they will miss the identities that actually drive infrastructure trust. The practical response is to rebuild control coverage around service accounts, tokens, certificates, and workload credentials, not around employee login patterns.
Machine identity growth is the point at which Zero Trust either broadens or becomes cosmetic. Near-universal adoption is not meaningful if service-to-service paths remain outside the same visibility and authorization standards applied to users. Teams should judge their programme by how well it constrains non-human access in live environments, not by how many user journeys have been modernised.
For practitioners
- Inventory machine identities as a separate governance domain Map service accounts, tokens, API keys, certificates, and workload credentials separately from human users, then assign ownership and lifecycle status to each.
- Prioritise controls that reduce incident likelihood Use incident data to rank the machine identity controls most likely to prevent compromise, starting with authentication strength, privilege scope, and exposed secrets.
- Tie machine identity ownership to offboarding Require explicit revocation and reassignment when applications, vendors, or environments are retired, so credentials do not outlive the process they support.
- Measure governance coverage against the full identity estate Track whether machine identities are inventoried, reviewed, rotated, and removed with the same discipline used for human access decisions.
Key takeaways
- Machine identities are no longer a side category in identity security because they now outnumber human users in many enterprise environments.
- AI-driven abuse and operational complexity make blind spots around service accounts, tokens, and workload credentials materially more dangerous.
- Identity programmes need separate machine governance, stronger lifecycle discipline, and control coverage that matches the real trust paths in modern infrastructure.
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Machine identities outnumbering users raises the likelihood of excess privilege in service and workload accounts. |
| NHI-07 — Long-Lived Secrets | The report's concern with machine identity exposure maps directly to secrets that persist beyond their safe window. | |
| NHI-03 — Vulnerable Third-Party NHI | Machine identity growth often extends into vendor and external system access paths that need separate governance. | |
| Recommendation — Review machine identity scopes and remove any privilege that exceeds the workload's actual function. Shorten credential lifetimes and rotate machine secrets before they become persistent exposure points. Track third-party machine identities separately and revoke them when the business relationship changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing who or what can access systems across a growing identity estate. |
| Recommendation — Apply entitlement reviews to non-human access paths and validate that permissions match current business need. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article highlights attack pressure on machine credentials and the resulting spread across environments. |
| Recommendation — Map exposed machine credentials to credential-access and lateral-movement detections in your monitoring stack. | ||
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.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Standing Trust: Persistent confidence in an identity, broker, or automation path to request privilege without sufficient ongoing verification. For NHIs, standing trust can remain even when credentials are short lived, which means the organisation has reduced exposure time but not necessarily reduced the chance of abuse.
- Zero Trust For External Access: Zero Trust for external access is the practice of verifying every vendor request instead of treating an outside party as trusted because it was previously onboarded. The model relies on continuous checks, narrow entitlements, and session-level controls rather than one-time approval.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org