Machine identity blind spots are widening faster than governance

At a glance

What this is: This is a vendor-published analysis of machine identity governance, and its key finding is that machine identities now outnumber human identities in most organisations while management remains largely manual.

Why it matters: This matters because machine identity sprawl directly affects NHI governance, audit readiness, and access control design across service accounts, bots, and workload identities.

By the numbers:

• 69% of companies surveyed now manage more machine identities than human ones.
• 72% of identity professionals surveyed find machine identities more difficult to manage than human identities.
• Only 38% of companies surveyed reported having a real-time list of their active machine identities.

👉 Read SailPoint's analysis of machine identity blind spots and governance gaps

Context

Machine identity governance is the discipline of tracking, controlling, and reviewing non-human accounts such as service accounts, bots, and RPAs across their full lifecycle. In this article, the primary problem is not the existence of machine identities but the mismatch between their growth and the controls used to manage them.

The governance gap is familiar to IAM teams: when identities are created faster than they are inventoried, certified, and removed, access becomes opaque. That is especially true for machine identities because many enterprises still rely on manual processes, fragmented ownership, and incomplete visibility rather than automated lifecycle control.

The article shows that this is now a scale problem as much as a security problem. Once machine identities exceed human identities, programmes designed around user-centric review cycles and manual exception handling stop being reliable enough for day-to-day assurance.

Key questions

Q: How should security teams govern machine identities at scale?

A: Security teams should govern machine identities as a lifecycle problem, not a one-time provisioning task. That means maintaining an authoritative inventory, assigning clear ownership, tying access to workload purpose, and removing identities when the service is retired or replaced. Manual spreadsheets and ad hoc exceptions do not scale once machine identities outnumber human users.

Q: Why do machine identities create more risk than human accounts in many environments?

A: Machine identities often have broader access, longer-lived credentials, and weaker oversight than human accounts. They are also harder to track because they are embedded in systems, pipelines, and integrations rather than tied to a named user. That combination makes stale access and unnoticed privilege creep much more likely.

Q: What do organisations get wrong about machine identity auditing?

A: They treat auditing as a periodic report instead of a live control. By the time an audit runs, the machine identity landscape may already have changed, so the evidence no longer reflects current access. Effective auditing depends on continuously updated inventory, ownership, and usage data.

Q: How do teams reduce the blast radius of unmanaged service accounts?

A: Teams reduce blast radius by narrowing permissions, removing inactive identities, and preventing credentials from persisting after their business purpose ends. The goal is to make every service account easy to attribute, easy to review, and easy to revoke when its workload changes or disappears.

Technical breakdown

Why machine identity sprawl breaks manual governance

Machine identities are non-human accounts that execute workloads, connect systems, or trigger automation. Unlike human identities, they often exist in large numbers, are created programmatically, and are tied to applications rather than named owners. That makes them difficult to inventory, certify, and retire with human-centric workflows. When 63% of organisations rely on manual processes to track inactive machine identities, the operational model itself becomes the constraint. The issue is not only scale. It is that manual governance cannot keep pace with ephemeral provisioning, hidden dependencies, and unclear ownership across application and infrastructure teams.

Practical implication: replace manual tracking with authoritative inventory and lifecycle ownership for every machine identity.

Audit and compliance failures in machine identity environments

Auditability depends on knowing what identities exist, who owns them, what they can access, and whether they are still required. Machine identities often fail that test because they are embedded in code, scripts, pipelines, or integration paths that are rarely reviewed end to end. When only 38% of organisations have a real-time list of active machine identities, audit evidence becomes stale almost immediately. Compliance issues arise because the same identity may persist after the workload changes, the team changes, or the integration is retired. In practice, this creates a gap between nominal governance and actual control.

Practical implication: tie machine identity records to live asset, application, and owner data so audit evidence reflects current reality.

Why excessive access becomes the default state for machine identities

Machine identities are frequently granted broad permissions because teams fear breaking integrations if access is tightened. That leads to persistent overprovisioning, especially where certificates, tokens, or API keys are reused across services. The survey’s finding that 57% of respondents have seen inappropriate access granted to a machine identity shows how easily this pattern turns into a standing privilege problem. Once access is inherited from deployment convenience rather than explicit business need, the identity becomes an enduring blast-radius amplifier. Governance then depends on exceptions, not policy.

Practical implication: recertify machine identity permissions against workload need, not historical convenience or deployment defaults.

Threat narrative

Attacker objective: The attacker seeks persistent access through an unmanaged machine identity that outlives the business need it was created for.

1. Entry occurs when a service account, bot, or API credential is created with broader access than the workload actually needs, often because automation and speed are prioritised over review.
2. Escalation follows when the identity is left active after purpose change, with manual processes failing to retire or narrow the account before it can be reused or abused.
3. Impact emerges when the stale identity is exploited for unauthorized access, compliance exposure, or lateral movement across systems that still trust the credential.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Machine identity sprawl is a lifecycle failure before it is a visibility problem. The article shows that organisations have more machine identities than human ones, yet still depend on manual workflows and incomplete inventories. That combination means the real failure is not simply that identities exist, but that their creation, ownership, and retirement are not governed as a continuous lifecycle. Practitioners should treat the growth of machine identities as evidence that governance has drifted behind operational reality.

Auditability collapses when machine identities are not tied to live ownership and current purpose. A real-time inventory is not a reporting feature, it is the minimum condition for proving that a service account or bot still has a legitimate reason to exist. When 38% of organisations can only partially see active machine identities, recertification becomes retrospective theatre rather than control. Practitioners should read that as a warning that audit evidence is already stale when it is generated.

Excess access in machine identities is usually a design default, not an exception. Teams fear breaking production, so they keep permissions broad and credentials persistent. That creates a standing privilege model for non-human identities, which is precisely where lateral movement and hidden persistence become likely. Practitioners should recognise that the security issue is not just overpermissioning, but the operational habit that normalises it.

Identity blast radius is the right named concept for this problem. Once machine identities multiply faster than governance can absorb them, every missed lifecycle event increases the amount of access that can be abused, inherited, or forgotten. The article makes clear that the blast radius is driven by unmanaged persistence, not by a single misconfigured account. Practitioners should use that lens when prioritising which identities to inventory, review, and retire first.

Machine identity controls cannot remain an add-on to human IAM. The survey describes a governance environment where machine accounts are more numerous, more manual, and harder to audit than employee identities. That means the operating model must move from user-centric exception handling to machine-specific ownership, certification, and deprovisioning. Practitioners should treat machine identity management as a core NHI programme, not as a side task for platform teams.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the natural next read for teams rebuilding machine identity governance.

What this signals

Machine identity governance is now a control-plane issue, not a back-office review task. As non-human accounts multiply, the programme risk shifts from isolated credential hygiene to systemic ownership, inventory, and retirement failure. Teams that still rely on manual review cycles will keep discovering stale access after it has already become operational debt, so the next move is to make machine identities visible in real time and govern them with lifecycle semantics.

Identity blast radius will become the organising concept for machine account remediation. The practical question is no longer whether an account exists, but how much downstream access its continued existence preserves. With 97% of NHIs carrying excessive privileges according to the Ultimate Guide to NHIs, prioritisation should focus on the identities whose persistence creates the widest exposure.

Machine identity programmes should be benchmarked against IAM and Zero Trust operating assumptions, not just security tool coverage. When identity is non-human, continuous verification, ownership clarity, and revocation discipline matter more than periodic review theatre, which is why governance teams should align machine account controls with NIST Cybersecurity Framework 2.0 and the lifecycle guidance in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

For practitioners

• Build a live machine identity inventory Create a system of record that ties every service account, bot, token, and certificate to an owner, workload, and business purpose. Reconcile that inventory with cloud, CI/CD, and application telemetry so inactive identities are visible before they are forgotten.
• Enforce lifecycle ownership at creation Require named ownership and expiry logic whenever a machine identity is provisioned. If the account cannot be attributed to a service, team, and retirement path, it should not be allowed to persist beyond initial deployment.
• Recertify non-human access by workload need Review permissions against the current application or service requirement, not the historical deployment pattern. Remove permissions that exist only because the identity was convenient to create or risky to change.
• Automate deprovisioning for inactive identities Detect stale service accounts, retired bots, and unused credentials through activity signals and asset lifecycle events. Use those signals to revoke access before dormant identities become unintended persistence paths.

Key takeaways

• Machine identities have become numerically dominant in many enterprises, but governance maturity has not kept pace.
• Manual tracking and delayed offboarding turn routine service accounts into persistent security and compliance liabilities.
• Teams need live inventory, named ownership, and lifecycle-driven revocation if they want to reduce machine identity blast radius.

Key terms

• Machine Identity: A machine identity is a non-human account used by software, infrastructure, or automation to authenticate and access resources. It can include service accounts, API keys, certificates, tokens, bots, and workload identities. In practice, it needs the same lifecycle discipline as human identity, but with faster provisioning and tighter revocation controls.
• Lifecycle Ownership: Lifecycle ownership is the assignment of clear responsibility for creating, maintaining, reviewing, and retiring an identity across its full life. For machine identities, that means a specific team or system owner must be accountable for why the identity exists, what it can access, and when it must be removed.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and operational privilege that can be affected if an identity is misused or left active. For machine identities, blast radius is often amplified by broad permissions, weak ownership, and credentials that remain valid long after the workload changes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SailPoint: The silent security threat: Why machine identities are your biggest blind spot. Read the original.