Cybercriminals aren’t breaking into accounts exactly the way they used to. Instead of exclusively phishing users or brute-forcing passwords, they’re also hunting for underprotected API keys, forgotten service accounts, and misconfigured workloads.
Non-human identities (NHIs) – software workloads, AI agents, and service accounts – and their associated credentials significantly outnumber human identities in most environments, yet security programs still focus primarily on users.
While attackers still exploit human identity gaps, at least there are rules in place – accountability, governance, enforcement. The same cannot always be said for NHIs.
For example, when a developer leaves a company, their access is revoked. But when an old API key is left behind in a repository, it often remains valid indefinitely. Service accounts frequently hold far more privilege than necessary, and automated workloads often authenticate with static secrets that never expire.
To address this growing threat, OWASP has released the first-ever Top 10 for Non-Human Identities – an awareness document for identifying and mitigating the biggest risks associated with NHIs.
Here’s how these risks are ranked:
- Exploitability: How easily can an attacker take advantage of the issue?
- Prevalence: How common is this weakness across organizations?
- Detectability: Can security teams detect when an attacker exploits this?
- Technical Impact: What level of damage can be done?
Let’s break down each threat, based on Aembit Principal Solutions Architect Andrew McCormick’s talk at NHIcon 2025, with real-world breach examples and solutions to mitigate the risk.
OWASP NHI Top 10: A Breakdown
1) Improper Offboarding – Forgotten Credentials That Never Expire
When workloads and services are retired, their associated credentials often remain active. Attackers look for these orphaned API keys and abandoned service accounts because they provide access without triggering alerts.
Example: Attackers gained access to the Internet Archive’s systems after an access token, exposed in a GitLab repository for 22 months, was exploited. They exfiltrated 7 terabytes of data, including long-lived Zendesk credentials that were later used for further compromise.
How to Mitigate It:
✔ Automate identity lifecycle management: Ensure that NHIs are properly offboarded when no longer in use.
✔ Use ephemeral credentials: Replace long-lived secrets with short-lived tokens that automatically expire.
✔ Regularly audit non-human identities: Identify and remove unused NHIs before attackers find them.
2) Secrets Leakage – API Keys and Credentials in the Wrong Hands
Unlike user passwords, API keys and service account credentials don’t have MFA. If they leak, attackers can use them immediately. Secrets often end up in public repositories, logs, or internal documentation, making them easy to steal.
Example: The New York Times breach started when a GitHub token was leaked publicly. Attackers used it to access repositories containing hundreds of secrets and user data.
How to Mitigate It:
✔ Replace static credentials with identity-based authentication: Use workload identity federation instead of API keys.
✔ Automate secret scanning: Regularly scan repositories and infrastructure for exposed secrets.
✔ Enforce least privilege access: Scope API keys and service accounts to only what they need.
3) Vulnerable Third-Party NHIs – The Supply Chain Weak Link
Third-party integrations are everywhere – connecting developer tools, cloud services, and SaaS platforms. If a vendor is breached, their service account credentials and tokens can be stolen and used to access your systems.
Example: The Cloudflare breach was triggered by an earlier Okta compromise, where attackers stole service account credentials. Cloudflare rotated 5,000 credentials but missed four, which allowed further compromise.
How to Mitigate It:
✔ Replace static API keys with identity-based authentication: Move away from long-lived credentials to reduce risk.
✔ Continuously monitor third-party access: Detect anomalies in vendor behavior before they become breaches.
✔ Limit third-party permissions: Grant only necessary access and remove it when no longer required.
4) Insecure Authentication – Weak or Nonexistent Safeguards
Many APIs still rely on static API keys and non-standard authentication methods, making them easy for attackers to exploit.
Example: The Hugging Face breach exposed organization-wide long-lived API tokens, allowing attackers to escalate privileges and access sensitive systems.
How to Mitigate It:
✔ Adopt modern authentication standards: Use OAuth, OIDC, and mutual TLS instead of static API keys.
✔ Deprecate weak authentication methods: Remove long-lived tokens and enforce secure authentication flows.
✔ Audit API authentication: Regularly review API security configurations.
5) Insecure Cloud Configurations – Overprivileged Pipelines
CI/CD pipelines and cloud workloads require privileged access, but misconfigurations can expose excessive permissions, making them a prime target.
Example: The Sisense breach occurred when attackers accessed GitLab repositories containing hardcoded AWS access keys. These credentials allowed exfiltration of customer data, including sensitive access tokens.
How to Mitigate It:
✔ Implement least privilege policies: Restrict pipeline permissions to the minimum necessary.
✔ Remove hardcoded credentials from infrastructure code: Use identity-based authentication instead.
✔ Monitor and log CI/CD workflow activity: Detect unauthorized access before it becomes a breach.
6) Long-Lived Secrets – Credentials That Never Rotate
Static credentials remain valid indefinitely, creating security risks. Even when organizations rotate credentials, attackers can still exploit them before rotation occurs.
Example: The U.S. Treasury Department breach stemmed from a BeyondTrust API key compromise. Attackers used it to steal sensitive documents from employee workstations.
How to Mitigate It:
✔ Use ephemeral credentials: Replace long-lived secrets with short-lived tokens that automatically expire.
✔ Automate credential rotation: Reduce the risk of compromise by rotating secrets frequently.
✔ Store credentials securely: Use dedicated vaults instead of embedding credentials in code.
7) Environment Isolation Failures – Attackers Move from Dev to Prod
Many organizations reuse credentials across development, testing, and production environments. If attackers breach a lower-security environment, they can escalate to production.
Example: The Midnight Blizzard attack on Microsoft started with a password-spraying attack on Azure test environments. Attackers then escalated privileges via a legacy OAuth application.
How to Mitigate It:
✔ Use environment-specific identities: Separate credentials for dev, test, and production.
✔ Apply fine-grained access controls: Restrict access to sensitive resources.
✔ Audit identities regularly: Identify and remove credentials that are shared across environments.
8) NHI Reuse Across Systems – Breaking Least Privilege
Service accounts and API keys should be unique to each application. When NHIs are shared across multiple systems, it becomes impossible to enforce least privilege.
Example: The Imperva Cloud WAF Breach occurred when a production database snapshot was used in a test environment, exposing sensitive customer data.
How to Mitigate It:
✔ Assign unique NHIs per application: Reduce the impact of a breach.
✔ Limit permissions based on function: Enforce strict scoping of service accounts.
✔ Audit NHIs for overuse: Identify credentials being used in multiple environments.
9) Human Use of NHIs – Admins Using Service Accounts as Shortcuts
IT teams sometimes use service accounts for convenience, bypassing security controls. This practice eliminates accountability and increases the risk of compromise.
Example: The CircleCI breach began when malware on an engineer’s laptop stole session cookies. These cookies were used to generate production workload credentials, leading to data exfiltration.
How to Mitigate It:
✔ Enforce separation between human and non-human identities: Require developers and administrators to use their own credentials, not shared service accounts.
✔ Analyze non-human identity usage patterns: Identify anomalous behavior that suggests human misuse of workload credentials.
✔ Educate engineering and security teams: Ensure teams understand the risks of using service accounts for human access.
10) Weak Workload Identification – No Way to Verify Workloads
Many workloads lack strong identity validation, making it easy for attackers to impersonate trusted machines.
Example: Retail edge environments often run unprotected devices without a centralized identity provider, making it easy to spoof legitimate workloads.
How to Mitigate It:
✔ Use cryptographic workload attestation: Ensure only trusted workloads can access sensitive resources.
✔ Implement zero trust for workloads: Authenticate every request, even within internal environments.
✔ Enforce strict identity validation: Require identity-based authentication for all workloads.
OWASP NHI Top 10: A Security Framework for Compliance and Risk Reduction
The OWASP NHI Top 10 underscores a common oversight in security – non-human identities are often treated as fixed credentials rather than identities that require management and validation.
Attackers exploit this gap because traditional IAM solutions are designed for human authentication and access control, often leaving identities that connect applications and services with weaker protections.
And beyond security risks, regulatory and industry mandates like PCI DSS and NIST have increasingly prescriptive requirements for non-human identity governance. Many of the security failures outlined in the NHI Top 10 – such as long-lived secrets, improper offboarding, and overprivileged service accounts – map directly to these newfound compliance requirements.
For example: Starting next month, PCI DSS 4.0 requires organizations to manage and monitor all accounts, including non-human identities, enforce least privilege, and periodically review access. The NHI Top 10 provides a framework to address these requirements, particularly around secrets leakage and service account sprawl.
The OWASP NHI Top 10 provides a structured way to stymie threats while ensuring alignment with incoming requirements. Organizations that implement these best practices will be better positioned to prevent breaches, pass audits, and reduce overall business risk.
For more information on how Aembit can help, visit aembit.io.
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
