What Is a Non-Human Identity?
A non-human identity (NHI) is any credential, token, key, or account used by software, automated processes, or machines to authenticate and access resources — rather than by a person. The category includes:
- Service accounts. Domain user accounts in Active Directory or Entra ID used by applications, services, and scheduled tasks. The most numerous NHI type in on-premises Windows environments.
- API keys. Long-lived static credentials used to authenticate to external services — SaaS platforms, cloud APIs, data providers. Commonly stored in application configuration files, environment variables, and source code repositories.
- OAuth 2.0 client credentials. Client ID and secret pairs used by applications to request access tokens from identity providers. Widely used for service-to-service authentication in cloud and SaaS environments.
- SSH keys. Key pairs used for secure shell access to servers and for automated deployment pipelines. Private keys stored on CI/CD build agents, jump servers, and developer workstations.
- Certificates and private keys. X.509 certificates used for mutual TLS authentication, code signing, and service identity. High risk when private keys are stored insecurely or when certificates expire unexpectedly.
- Workload identities. Cloud-native identities for compute workloads — AWS IAM roles for EC2 and Lambda, Azure Managed Identities, GCP service accounts. Attached to infrastructure rather than human users.
- Personal access tokens (PATs). Developer-created tokens for source code platforms (GitHub, GitLab, Azure DevOps) that are frequently granted broad repository access and never revoked.
Why NHIs Are the Highest-Value Target
Attackers target NHIs because the economics of exploitation are favourable. A human user who has their credentials stolen will notice — they cannot log in, they receive unexpected MFA prompts, or helpdesk notices failed logins and resets the account. A compromised API key or service account credential may be used continuously for months without triggering any alert, because the access pattern looks identical to legitimate use.
The Long Dwell Time Problem
Dwell time — the period between an attacker gaining access and detection — is substantially longer for NHI compromises than for human account compromises. The average dwell time across all breach types is measured in weeks. For NHI compromises, where the credential is exfiltrated and used from an attacker-controlled system mimicking normal service access, months-long dwell times are common. The attacker is not triggering failed login events. They are not accessing systems that would generate anomalous alerts. They are authenticating with a valid credential from a new location, and there is no monitoring specifically watching for that.
Supply Chain Exposure
NHIs create supply chain risk that human identity management does not. An API key embedded in a third-party application's configuration gives that vendor's compromised developer environment access to your systems. An OAuth client secret shared with a SaaS integration partner gives any attacker who breaches that partner access to your data. The SolarWinds attack is the canonical example: the build environment compromise propagated access because the software's credentials had privileged access to customer environments. Human credentials operate within the same organisation. NHI credentials routinely bridge organisational boundaries.
Secrets in Source Code
A persistent and widely-observed pattern is NHI credentials committed to version control repositories. Development teams embed API keys, database connection strings, and service account passwords in application code, environment files, or configuration templates. When these repositories are pushed to GitHub — or even internal GitLab instances — the credentials become accessible to anyone who can read the repository, including historical commits after the credential has been rotated and removed. Scanning tools consistently find thousands of exposed secrets across enterprise repository sets, many of which are still active.
The Governance Challenge: You Cannot Govern What You Cannot See
The fundamental problem with NHI security is inventory. Organisations typically have no accurate count of their NHIs. Service accounts are created by application teams without central registration. API keys are generated by individual developers using their personal SaaS accounts. SSH keys are created on workstations and deployed to servers without any central record. OAuth client registrations accumulate in identity providers and are never removed when the application is decommissioned.
The Orphan NHI Problem
NHIs outlive the applications and people that created them. When a developer leaves, their personal access tokens for GitHub and Azure DevOps remain active. When an application is decommissioned, its service account and API key registrations remain in AD and in third-party platforms. When a project ends, the CI/CD pipeline credentials remain valid. These orphan NHIs represent access to production systems with no accountability — there is no owner to revoke them and no process that triggers their removal.
Lifecycle Management Gaps
Human identity lifecycle management has mature processes — joiners, movers, and leavers workflows trigger provisioning, access updates, and deprovisioning. NHI lifecycle management is largely absent. There is no systematic process that identifies NHIs associated with a decommissioned application, reviews their continued necessity, and removes them. The result is exponential accumulation: new NHIs are added with each deployment, old ones are never removed, and the attack surface grows continuously.
Controls for Non-Human Identity Security
1. Establish a Comprehensive NHI Inventory
The starting point is knowing what exists. For service accounts, this means AD enumeration — all accounts with SPNs, all accounts with non-interactive logon history, all accounts in privileged groups. For API keys and OAuth clients, this requires querying identity provider admin APIs and cataloguing registered applications and their associated credentials. For SSH keys, this involves scanning servers for authorised_keys files and correlating public keys to known key pairs. For cloud workload identities, this means querying IAM policies across AWS, Azure, and GCP to inventory all service principals and their permission assignments.
2. Implement Secrets Management
Static credentials in configuration files and environment variables should be replaced with dynamic secrets fetched at runtime from a secrets management system — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or equivalent. The application requests a short-lived credential at startup; the secrets manager generates one. The credential expires automatically. There is no long-lived static secret to exfiltrate. This eliminates the "credential in config file" attack vector and removes the operational burden of manual rotation.
3. Use Workload Identity Where Available
Cloud-native workload identities — AWS IAM roles for EC2/Lambda, Azure Managed Identities, GCP Workload Identity Federation — replace static credentials with cryptographic identity bound to the workload itself. The compute resource has an identity; the identity has permissions; access tokens are issued automatically and are short-lived. There is no credential to exfiltrate because there is no static credential. For cloud workloads, this should be the default authentication mechanism, not an enhancement.
4. Scan Repositories for Exposed Secrets
Secret scanning should be applied to all repositories — current commits and git history. Tools like GitHub Advanced Security (GHAS), GitGuardian, and Trufflehog detect patterns matching API keys, connection strings, and private keys across commit history. For enterprises using Microsoft platforms, GHAS secret scanning is available in GitHub Enterprise and detects over 200 credential patterns including provider-specific formats. Newly detected secrets should trigger immediate rotation — a secret that has been in a repository must be treated as compromised.
5. Apply Least Privilege to NHIs
Every NHI should have the minimum permissions required for its function. For service accounts, this means scoping AD group memberships, file system ACLs, and database permissions. For API keys, this means using vendor-specific scopes and restricting IP allowlists where the platform supports it. For OAuth clients, this means requesting only the OAuth scopes needed and avoiding *.ReadWrite.All Microsoft Graph permissions when Mail.Send would suffice. For cloud IAM roles, this means condition-based policies that restrict actions to specific resources and regions.
6. Implement Rotation Policies
Where secrets cannot be replaced with dynamic credentials, mandatory rotation schedules must be enforced. API keys should rotate quarterly or more frequently. SSH keys used in automation should rotate annually at minimum. OAuth client secrets should have expiry dates set in the identity provider and a rotation process that predates expiry by 30 days. Service accounts not yet migrated to gMSA should have password rotation at 90-day intervals enforced through a PAM vault that handles the update to all consuming applications.
7. Monitor NHI Behaviour
NHIs should have baseline behavioural profiles — the times they authenticate, the source IPs they authenticate from, the resources they access. Deviations from this profile are high-fidelity signals: an API key authenticating from an unfamiliar geographic region, a service account accessing resources outside its normal pattern, or an OAuth token being used from a new application. SIEM correlation rules based on NHI behavioural baselines catch the use of compromised credentials even when the credentials themselves are valid.
Regulatory Context
NHI security is increasingly referenced explicitly in regulatory frameworks:
- DORA (EU 2022/2554). Article 9 requires ICT security policies covering "authentication and access rights management" without distinguishing between human and non-human access. The EBA and ESMA guidelines for DORA implementation explicitly reference service accounts and privileged access management in technical standards.
- NIS2 (EU 2022/2555). Article 21(2) minimum security measures include access control policies. The ENISA implementation guidance references "technical accounts" and service-to-service authentication explicitly.
- NCSC CAF. CAF Objective B2.c (Authentication) applies to all identities accessing in-scope systems — including non-human identities. CAF B2.b (Privileged Access) covers service accounts with elevated rights as high-priority remediation items.
- CIS Controls v8. Control 4 (Secure Configuration) and Control 5 (Account Management) both apply to NHIs. Safeguard 5.6 specifically addresses service accounts.
NHI Enumeration and Risk Assessment
IdentityFirstMRI enumerates the full non-human identity surface — service accounts, privileged NHIs, Kerberoastable accounts, stale credentials, and cloud workload identity configuration — from read-only access to your directory and cloud environment. The output maps each NHI to its risk level and the specific control that addresses it.
See IdentityFirstMRI Assessment