When security teams talk about identity security, they almost always mean user accounts: employee logins, administrator credentials, privileged access. But in modern enterprise infrastructure, the identities that humans use directly are a small minority of the total identity population. For every human user in your environment, there are dozens — sometimes hundreds — of service accounts, API keys, OAuth tokens, bot credentials, and machine certificates that authenticate to systems on behalf of applications and automated processes. These are Non-Human Identities (NHI), and they represent the largest, fastest-growing, and least-governed segment of your identity estate.
What Counts as a Non-Human Identity
Non-Human Identities are credentials that allow a machine, process, or application to authenticate and act. The category is broader than most security teams initially assume, spanning every layer of the technology stack.
Service accounts are the most familiar type: accounts created in Active Directory or LDAP to run Windows services, scheduled tasks, application pools, and system processes. A typical enterprise Active Directory environment contains hundreds of service accounts, many created years ago for applications that may no longer be running, with passwords that have never been changed and permissions that were granted for convenience and never reviewed.
API keys are static credentials that applications use to authenticate to external services — SaaS platforms, cloud APIs, payment processors, data providers. Every SaaS integration in your environment almost certainly uses at least one API key. These keys are typically generated by a developer, stored in a configuration file or environment variable, and never rotated unless a security incident forces the issue. The average enterprise has hundreds of API keys scattered across code repositories, CI/CD platforms, and infrastructure configuration.
OAuth tokens are short-lived credentials issued by identity providers like Okta or Microsoft Entra ID that authorise applications to access resources on behalf of a user or system. The short-lived access token is paired with a longer-lived refresh token that allows new access tokens to be obtained continuously — turning what appears to be a temporary credential into a persistent one if the refresh token is not managed.
Certificates and PKI credentials are used for machine-to-machine authentication — TLS client certificates that authenticate servers and services to each other, code signing certificates that establish the authenticity of software, and device certificates in MDM-enrolled endpoint programmes. Certificates have defined expiry dates but require active management to rotate before they expire; an expired certificate is a production outage, and an expired-but-still-trusted certificate is a security failure.
Bot and RPA credentials are the accounts used by Robotic Process Automation workflows — automated processes that log in to applications and perform actions as if they were human users. These credentials are often created as standard user accounts rather than purpose-built service accounts, meaning they carry the full permissions of a human user with none of the behavioural monitoring that would detect anomalous activity.
Cloud workload identities — AWS IAM roles, Azure Managed Identities, GCP Service Accounts — are the cloud-native equivalents of on-premises service accounts. In cloud environments, every compute instance, serverless function, and container workload can be assigned an identity that grants it access to other cloud resources. These identities are often created with excessive permissions (the cloud equivalent of a service account with Domain Admin rights) and are rarely reviewed after initial provisioning.
The Scale of the Problem
Industry analysis consistently finds that Non-Human Identities outnumber human identities by a factor of 10 to 45 in typical enterprise environments, with the ratio increasing as cloud adoption and automation expand. A 1,000-employee organisation may have 10,000 to 45,000 NHIs in its environment — most of which have never been inventoried, let alone governed. This is not a hypothetical scale; organisations that run their first systematic NHI discovery exercise routinely discover two to three times as many NHIs as they expected.
The governance investment tells a different story. While human identity programmes — HR-driven provisioning, access certification, MFA enforcement, offboarding automation — receive continuous investment and executive attention, NHI governance in most enterprises is characterised by informal creation processes, no formal decommissioning, no rotation schedules, and no ownership records. The identities that outnumber human users by a factor of 45 receive a fraction of the security programme investment that the human minority does.
Microsoft's January 2024 disclosure of the Midnight Blizzard (APT29) breach explicitly identified a legacy OAuth application with elevated permissions as the entry point. The application had been granted access to Microsoft's corporate environment and had not been reviewed in years — a textbook NHI governance failure. The attacker did not need to find a vulnerability. They needed to find an ungoverned machine identity with permissions that nobody was watching. In the average enterprise, the supply of such targets is not limited.
Why NHIs Are the #1 Attack Surface
Three properties make Non-Human Identities disproportionately attractive as attack targets compared with human user accounts.
First, they are persistent. Human user accounts are subject to password policies, MFA requirements, and periodic access reviews. NHIs typically are not. A service account password set when the application was deployed five years ago is still the same password today. An API key generated for a project that was completed two years ago is still valid. A certificate that expired three months ago may still be trusted by the application that was too hard to update. Long-lived, unrotated credentials are the attacker's preferred credential type — they do not expire under pressure, they survive employee offboarding events, and they require no social engineering to obtain.
Second, they are over-privileged. NHIs are provisioned by developers and operations teams who grant broad permissions to avoid friction during development and to prevent future access requests. The service account that needs to read from one database table is given access to the entire database. The API key that needs to query one endpoint is granted write access across the API surface. The cloud IAM role that needs to read from one S3 bucket is given S3 full access. This over-provisioning is endemic and almost never reviewed — there is no quarterly certification for service account permissions in the typical enterprise.
Third, they are invisible to most monitoring. User behaviour analytics platforms build baselines from human interaction patterns — login times, access sequences, data volumes. They are poorly positioned to detect anomalous behaviour from service accounts and API credentials, because the baseline of "normal" for a service account that runs batch jobs overnight is fundamentally different from human behaviour. An attacker operating as a service account generates traffic that looks like scheduled automation — regular, predictable, machine-speed — and blends into the background of normal NHI activity unless specific NHI monitoring is in place.
The NHI Attack Lifecycle
Understanding how NHIs are exploited in practice clarifies what governance controls actually prevent. The typical NHI-based attack follows a consistent pattern across incidents.
Initial access comes from credential theft rather than vulnerability exploitation — an API key found in a public GitHub repository, a service account password obtained through phishing of the developer who knew it, or a secrets vault accessed through a misconfigured cloud storage bucket. The barrier to NHI credential theft is often lower than for human credentials because NHIs are stored in the places where credential exposure incidents are most common: source code, configuration files, CI/CD pipeline variables.
Lateral movement is the attack phase where NHI over-privilege creates the most damage. An attacker with a compromised service account that has database access, file system access, and network service credentials — because the account was provisioned with everything it might ever need — can pivot horizontally across the environment without escalating privilege. They already have it. The blast radius of the initial NHI compromise determines the scope of the breach; NHI over-privilege makes that blast radius large.
Persistence through NHIs is more durable than persistence through human accounts. When a human account is compromised, password resets and MFA re-enrolment can remove the attacker's access. When a service account is compromised, the attacker may have extracted the credential from configuration storage — meaning rotation of the credential in the identity store does not remove access unless every location where the credential is stored is also updated. In environments with poor secrets hygiene, an attacker may retain access through cached NHI credentials even after the owning account's password has been changed.
Building an NHI Security Programme
An effective NHI security programme has four components that must be implemented in sequence, because each depends on the previous.
Discovery: You cannot govern what you cannot see. Run discovery tooling across your entire environment — Active Directory, cloud IAM platforms, CI/CD systems, code repositories, SaaS administration consoles — to produce a complete NHI inventory. Expect the inventory to be two to three times larger than any estimate made without systematic discovery. The discovery output is the foundation for everything that follows.
Ownership assignment: Every NHI in the inventory needs a documented owner — the team or individual accountable for the credential and the access it grants. Without ownership, certification and decommissioning are impossible because there is nobody to make the decision. Ownership assignment is typically the most difficult step in an NHI programme because many NHIs have no obvious owner, and assigning ownership requires a decision-making process that does not exist in most organisations. Build it deliberately; the ownership model is the governance infrastructure that everything else runs on.
Access certification: With an inventory and ownership model in place, run quarterly access certification campaigns for privileged NHIs and annual campaigns for lower-privilege ones. The certification questions are simple — is this NHI still needed? is its access scope still appropriate? — but answering them correctly requires the inventory and ownership model to be current. NHIs that fail certification (no owner, no active use, scope cannot be justified) are revoked; the revocation record is the evidence your NIS2 or DORA examiner will want to see.
Lifecycle governance: Build NHI deprovisioning into the business events that should trigger it — project closure, application decommission, vendor offboarding, employee departure. This requires integrations between your identity governance platform (SailPoint, Saviynt, or equivalent) and your ITSM system, so that a project closure ticket automatically triggers NHI revocation workflows for the credentials associated with that project. The goal is that NHIs age out of the environment automatically, rather than accumulating as orphans until a discovery exercise surfaces them.