Top 10 NHI Risks

Non-human identities now carry most of the access in a modern estate, and most of the breaches we analyse at NHI Mgmt Group start or spread through one of them. This list sets out the ten NHI risks we see most often in incident evidence, aligned with the OWASP Non-Human Identities Top 10 (2025) but written from a practitioner's view: what the risk looks like in a real environment, which breach shows it, and the first control to put in place. It is for identity, cloud and platform security teams who need to prioritise. Secrets handling has its own detailed guides, linked rather than repeated.

The Top 10 at a glance

Each risk maps to one or more OWASP NHI Top 10 entries (NHI1 to NHI10). The order reflects how often the risk appears in the breach pages we maintain and how much damage it does when it does, not the OWASP numbering.

1. Leaked secrets in code, files and images

The risk: API keys, cloud access keys, tokens and private keys end up in Git history, .env files, container layers, tickets and chat. Attackers scan for them continuously (MITRE ATT&CK T1552.001 Credentials In Files).

The evidence: in the CISA Private-CISA GitHub leak, a contractor's public repository held administrative AWS GovCloud keys for about six months after push protection was turned off. In the 230 Million AWS Cloud Environments campaign, exposed .env files yielded 1,185 AWS access keys among more than 90,000 variables.

What to do first: enforce push protection that only a small delegated group can bypass, scan history and images, and revoke before you delete. The detail is in the Top 10 Secrets Management Mistakes and the Leaked Credential Response Playbook.

2. Long-lived credentials that never expire

The risk: keys and tokens issued with no expiry, or with multi-year lifetimes, turn a single leak into open-ended access. OWASP lists this as NHI7.

The evidence: a Home Depot employee's GitHub token was public from early 2024 until it was revoked in December 2025, with access to private repositories, cloud infrastructure and fulfilment systems (Home Depot token exposure). At Coupang, a lawmaker reported signing keys with validity periods of five to ten years.

What to do first: set a maximum lifetime per credential type, replace static keys with federated short-lived credentials where the platform supports it, and automate rotation for the rest using the Secrets Rotation Runbook Template.

3. Overprivileged NHIs

The risk: service accounts, tokens and agents get owner or admin rights "so it works", and nobody narrows them later (NHI5).

The evidence: in the PocketOS database deletion, an AI coding agent found an account-scoped Railway token that had been created only to manage custom domains and used it to delete the production database and its volume backups in one API call. In the AWS .env campaign, an IAM user able to create roles and attach policies let attackers create a role with AdministratorAccess.

What to do first: find NHIs with admin, owner or IAM-write permissions, right-size them from activity data and block self-escalation paths such as iam:CreateRole plus iam:AttachRolePolicy. See the Cloud PAM and CIEM Guide.

4. Machine credentials that survive offboarding

The risk: when a person leaves or a project ends, their human account is disabled but the keys, tokens and service accounts they created or could read stay valid (NHI1).

The evidence: in the Coupang breach, a former developer used a token signing key that had not been rotated after he left to forge customer access tokens. The government investigation counted 33.67 million exposed records.

What to do first: make leaver and project-closure workflows list every NHI the person owned or could access, then transfer ownership and rotate. See the NHI Offboarding and Decommissioning Guide.

5. Compromised third-party integrations

The risk: SaaS connected apps, OAuth integrations and IDE extensions hold tokens into your tenant. When the vendor is breached, the attacker inherits those tokens and MFA never applies (NHI3, ATT&CK T1199 Trusted Relationship and T1550.001 Application Access Token).

The evidence: in the Salesloft Drift breach, OAuth tokens stored in Drift's AWS environment were used to export Salesforce data, and Google said over 700 organisations were potentially affected. The attacker then searched support cases for AWS keys and Snowflake tokens.

What to do first: inventory connected apps and their scopes, remove unused ones, and have a plan to revoke every token from a vendor in one step. See the SaaS and OAuth App Governance Guide.

6. Static cloud secrets in CI/CD

The risk: pipelines hold cloud keys, registry passwords and signing keys as long-lived variables visible to every step, or use OIDC federation without tight subject conditions (NHI6).

The evidence: in the Codecov breach, an attacker modified the Bash Uploader so that it sent each CI job's environment variables to an attacker server from 31 January to 1 April 2021, exposing whatever secrets those jobs held, including HashiCorp's GPG signing key.

What to do first: move cloud access to OIDC federation, where the token is valid for a single job, and bind trust to the sub claim (repository plus environment, for example repo:org/repo:environment:prod), never to the organisation alone. See the Workload Identity Federation Guide and the CI/CD Pipeline Identity Security Guide.

7. Weak or shared-key authentication

The risk: services authenticate with deprecated methods, shared static keys or vendor-embedded secrets that are the same in every installation (NHI4).

The evidence: in Gladinet CentreStack and Triofox (CVE-2025-14611), every installation used the same AES key and IV for access tickets, so attackers forged tickets, read web.config and used the ASP.NET machine keys for code execution. CISA added it to the KEV catalogue on 15 December 2025.

What to do first: prefer mutual TLS, signed assertions and workload identity over shared secrets, require unique per-installation keys from vendors, and rotate keys after patching because a patch does not invalidate a stolen key. See the NHI Authentication Guide.

8. Test and production not isolated

The risk: the same identities, or identities with cross-environment trust, span development, staging and production (NHI8). Test environments get weaker controls, then become the way in.

The evidence: in the Microsoft Midnight Blizzard breach, a password spray hit a legacy test tenant account without MFA, and a legacy test OAuth app with elevated access to the corporate environment was used to reach senior leadership mailboxes. At PocketOS, a token used in staging could delete production.

What to do first: issue separate identities per environment, block any non-production identity from production resources, and bring test tenants and their app registrations into the same inventory and review cycle.

9. One identity reused across many workloads

The risk: a single service account or API key is shared by many applications, pipelines or agents (NHI9). Logs cannot attribute actions, rotation breaks everything at once, and one leak exposes every consumer.

The evidence: reuse is rarely named in disclosures, but it drives blast radius. Codecov shows the pattern: when general CI tooling can see the same secrets as deployment and signing steps, one compromised component exposes them all.

What to do first: one identity per workload and environment, with a named owner, recorded in an inventory such as the Service Account Inventory Template. See the Service Account Security Guide.

10. Humans holding and using machine credentials

The risk: engineers log in as service accounts, keep production keys in personal vaults or run production changes on their own long-lived sessions (NHI10). The credential inherits every weakness of the person's laptop and the audit trail no longer shows who acted.

The evidence: in the LastPass breach, AWS and backup decryption keys sat in a senior DevOps engineer's vault, which was opened after a keylogger on his home computer captured the master password. In the Bybit hack, a Safe{Wallet} developer's active AWS sessions were hijacked to change front-end code in S3.

What to do first: remove interactive logon for service accounts, alert on human-pattern use of NHI credentials, and give engineers just-in-time elevation instead of standing keys. See the Human vs Non-Human Identity page.

Mapping to OWASP

Our order differs from OWASP's because we rank by incident frequency and damage in the breach evidence. The OWASP text remains authoritative for the NHI1 to NHI10 definitions. AI agents add their own risks on top of these; see the Top 10 Agentic AI Identity Issues.

Where to start

If you can only do three things this quarter, do these in order:

1. Stop new leaks and shorten lifetimes (risks 1, 2, 6): turn on push protection everywhere, set expiry on every new key and token, and move your top pipelines to OIDC. The Secrets Management Guide covers the programme and the Secrets Management Buyer's Guide covers tooling.
2. Find and own your privileged NHIs (risks 3, 4, 9): list every NHI with admin or IAM-write rights, give each a named owner, and add NHIs to leaver workflows.
3. Prepare for the vendor breach (risk 5): know which integrations hold tokens into your crown-jewel systems and rehearse revoking them in one step.

Track progress with four numbers: static secrets older than 90 days, NHIs without an owner, NHIs with admin rights, and median time from leak report to revocation. Assess your overall position with the NHI Governance Maturity Model.

Related NHI Mgmt Group resources: Secrets Management Guide · Top 10 Secrets Management Mistakes · Secrets Management Maturity Model · Board Briefing: NHI Risk · NHI Security Platform Buyer's Guide