OWASP Non-Human Identities (NHI) Top 10 Risks
A gist of the latest OWASP Non-Human Identities (NHI) Top 10 risks.
In the just released Threat Horizons Report, Google Cloud made an astonishing (and alarming) point - overprivileged service accounts now result in nearly half of observed security alerts! While weak credentials have always been a problem in cloud environments, the rapid increase in threat actor exploitation activity (e.g. Microsoft, Okta, Zendesk among others) clearly highlights the urgency of the situation. My own conversations with customers also match this reality - either organisations do not fully understand the importance of and the power wielded by service accounts (and similar non-human identities), or do not have the resources necessary to remediate the problem. In this post, I'll dive deeper into the concept of non-human identities (NHI for short) using OWASP's recently released NHI Top 10 list for 2025.
What are Non-Human Identities (NHI)?
According to the OWASP website, "Non-human identities (NHIs) are used to provide authorisation to software entities such as applications, APIs, bots, and automated systems to access secured resources". In other words, these are independent, digital, non-interactive identities associated with applications, services, and machines. They include service accounts, API keys, access tokens, and other forms of credentials that allow for authentication, authorisation, and communication, and are often managed separately from human identities.

However, NHIs pose a significant security challenge, outnumbering human identities by 17 to 1 in typical organisations. As observed in the Google Cloud report, mismanagement of NHIs frequently results in data security incidents including unauthorised access, accidental leakage, and external breaches. It also leaves cloud infrastructure vulnerable to attacks and resource abuse like crypto mining. While organisations generally have robust systems and processes for managing human identities, their NHI controls usually fall behind. Software Analyst's excellent guide to the growing impact of NHIs expands further on this growing security gap. Recognising this critical need, OWASP has developed a taxonomy of key NHI risks and practical mitigation strategies.
OWASP NHI Top 10 for 2025
Based on real-world incidents, surveys, CVE databases, and industry input, OWASP identified the following Top 10 risks for NHIs:
1. NHI1:2025 Improper Offboarding
This refers to inadequate deactivation or removal of NHIs when they are no longer in use. Unused or orphaned NHIs, especially with elevated privileges, can pose significant security risks. According to the CSA NHI report, 51% of organisations do not have a formal process to off-board or revoke long lived API keys. To address this issue, organisations must adopt a proactive approach to NHI management - this includes a comprehensive discovery of NHIs, their usage, status, and ownership, and a robust process for reviewing and revoking access permissions.
This refers to the accidental leakage of NHIs throughout the software development and deployment life cycle. Secret leakage is also #2 on the OWASP Top 10:2021 list of application security weaknesses (A02 Cryptographic Failures
, previously called Sensitive Data Exposure
). No matter how the secrets are exposed - hard-coded in source code, stored in configuration files, or other means - once they are leaked, threat actors can gain unauthorised access to sensitive systems and data. Here are some things you can do to avoid it:
- Follow principles of least privilege and create/assign secrets only when needed
- Replace static secrets with ephemeral, on-demand generated, short-lived ones
- Use secrets management tools like Secret Manager, HashiCorp Vault, Infisical
- Integrate secret scanning tools like TruffleHog into your CI/CD pipelines
- Automate secret rotation, and create a process to handle compromised secrets
3. NHI3:2025 Vulnerable Third-Party NHI
This refers to sensitive NHIs like access tokens, API keys, or SSH keys used by 3rd party systems like integrated development environments (IDEs), especially Cloud IDEs, open source tools, and software-as-a-service (SaaS) service providers. If these 3rd parties get compromised, the NHIs can be used via software supply chain attacks to gain unauthorised access to your sensitive systems and resources. While it may be difficult to fully implement, organisations should attempt vet and limit 3rd party integrations, scan for vulnerabilities or malicious behaviour, use short-lived credentials where possible, and continuously monitor for anomalies.
4. NHI4:2025 Insecure Authentication
This refers to the obsolete or potentially insecure authentication schemes used by 3rd party services integrated into your systems. You'll see this when systems use deprecated OAuth 1.0 or 2.0 flows, implement non-standard behaviours, and use long-lived credentials or app-specific passwords that bypass multi-factor authentication (MFA). The industry has already developed standardised protocols like OAuth 2.1 and OpenID Connect (OIDC) - using anything else greatly increases the risk of vulnerability exploits and consequent data breaches.
5. NHI5:2025 Overprivileged NHI
This refers to the assignment of excess privileges to NHIs, far beyond their actual requirements or usage, thereby increasing the blast radius in case of compromise. This risk is not unique to NHIs though, and is frequently seen with human identities too. Common examples here include web server service accounts with excessive permissions, overprivileged OAuth applications, SSH keys tied to users with admin privileges etc. Organisations should follow the principles of least privilege, create short-lived, just-in-time credentials instead of static secrets, and regularly audit the NHIs and the granted permissions.
6. NHI6:2025 Insecure Cloud Deployment Configurations
This refers to the authentication processes used in Continuous Integration / Continuous Deployment (CI/CD) pipelines. Instead of using dedicated service accounts with static credentials, CI/CD applications should use short-lived, dynamically generated tokens using OIDC. In addition, they should also validate the identity tokens, and ensure there are strict conditions on token claims (e.g. sub
claims). Legacy or self-hosted, open-source CI/CD tools do not generally support OIDC-based authentication, but newer, cloud-native offerings now do. Given that, hopefully, this risk will not show up in the Top 10 list for long.
7. NHI7:2025 Long-Lived Secrets
This refers to the use of sensitive NHIs like API keys, tokens, encryption keys, certificates, or session cookies that have long expiration dates or don't expire at all. According to the Datadog State of the Cloud 2024 report, 46% of AWS org users use long-lived console credentials. Using short-lived, just-in-time credentials instead of static secrets, automating secret rotation, and requiring periodic re-authentication for NHIs are a few things organisations can do to mitigate this risk.
8. NHI8:2025 Environment Isolation
This refers to the scenario when NHIs are reused across multiple environments - development, testing, staging and production - leading to significant security risks. Whether out of ignorance or simply convenience, developers tend to reuse NHIs across environments, which often do not have the security controls commensurate with the importance of those environments. To mitigate any resulting risks, organisations should use separate NHIs for each environment, implement environment-specific perimeter and access controls to prevent NHI reuse, and continuously monitor for anomalies.
This is a related risk, and refers to the reuse of NHIs across applications, services, or components, especially when each has different security threat models. An NHI compromised in one area can lead to unauthorised access to another area if reused, and can also complicate breach mitigation due to difficulty in attribution. This is frequently seen in Kubernetes clusters where multiple pods share the same Kubernetes service account, or when API keys are shared between applications.
10. NHI10:2025 Human Use of NHI
This refers to the use of NHIs by human identities (i.e. impersonation), either during application development and deployment, or in production environments for troubleshooting purposes. This leads to several issues, namely assuming privileges not directly granted to the human identity, lack of attribution and accountability, and bypassing of security controls. Attackers love this scenario, as they move laterally across an environment, or persist stealthily for long periods. Using dedicated human identities for troubleshooting purposes, coupled with just-in-time elevated access and proper change management, can alleviate this risk.