OWASP NHI Top 10
Juggling Non-Human Identity (NHI) Risks
If you’ve paid any attention to industry trends over the past 18-24 months, you’ve inevitably heard the term Non-Human Identities (NHI). This category of tools and vendors has quickly become one of the most discussed terms, and for good reason.
It is estimated that for every 1,000 human users, companies have 10,000 non-human connections/credentials, or even 10-50x the number of human identities in the organization.
When we recognize that credentials remain the leading attack vector in security breaches, as per Verizon’s DBIR, we can see why this would be a problem. Organizations have already historically struggled to secure human credentials, and an exponential 10-50x expansion of the attack surface with NHIs is only exacerbating longstanding challenges.
That’s why it is great to see OWASP publish the first-ever “Non-Human Identities Top 10,” which we will examine in this article.
For those new to the term or topic of NHIs, I recommend starting with some previous articles I’ve written on the topic:
Interested in sponsoring an issue of Resilient Cyber?
This includes reaching over 8,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives
Reach out below!
OWASP Non-Human Identities Top 10
Why and How?
Before diving into the Top 10, let’s examine why and how this was built. OWASP points out several notable recent incidents, such as Microsoft’s Midnight Blizzard Breach (2024), Internet Archive’s Zendesk Support Platform Breach (2024), and Okta Support System Breach (2023), all of which involved NHIs as part of the incident.
They publish this particular Top 10 to raise awareness of NHI-related security challenges, provide actionable insights into key NHI risks, and help organizations prioritize accompanying best practices.
NHI: 2025 Improper Offboarding
We all know the story of employees, contractors, and resources who come in, get accounts and access, change roles, or leave the organization, and their accounts go on to exist indefinitely as orphaned accounts/credentials that live in environments.
This scenario occurs with NHIs as well, and as mentioned in the introduction, at a scale that significantly exceeds that of their human counterparts. In this case, the credentials are often tied to applications, services, automated workflows, and systems that are given NHI credentials to facilitate activities but then never cleaned up as the associated applications, services, and entities get spun down or the specific credentials are no longer needed.
OWASP provides examples such as orphaned Kubernetes service accounts and ex-employees targeting un-revoked credentialed or leftover apps being used for privilege escalation and lateral movement.
Mitigations
To mitigate risks tied to improper offboarding, OWASP recommends implementing a standardized offboarding process to review all NHIs associated with a departing employee, application, service, etc., which may no longer be needed.
To ensure these activities occur, they recommend automating offboarding steps where possible and regularly auditing active NHIs to identify their usage and block potential misuse. This is also helpful because you can start to determine a baseline of use and adjust credentials and their associated permissions based on known activity.
NHI2:2025 Secret Leakage
Second on the list is Secret Leakage. Secrets are often used to describe entities such as API keys, tokens, encryption keys, and more. In 2022, I published an article on CSO Online titled “Keeping secrets in a DevSecOps cloud-native world.”
In that article, I discussed highly visible incidents tied to secret leakage, such as those impacting Codecov, Samsung, and several others, as well as sources of secret leakage, such as code repositories, Infrastructure-as-Code (IaC) manifests, and CI/CD systems.
Secret leakage is still a major problem in 2025, as evidenced by its second-place ranking on the OWASP list.
OWASP cites examples such as the Azure SAS Token Leakage and the Delinea Admin API key as situations in which secret leakage led to an incident.
Mitigation
Recommended steps for mitigating the risks of secret leakage they cite include examples such as using ephemeral credentials, using secret management tools, automating secret detection, and rotating secrets regularly. Given the expansive number of secrets in modern cloud-native development environments, organizations simply can’t do these activities manually, and that is why secrets management tools and vendors who offer these capabilities are key.
NHI3: 2025 Vulnerable Third-Party NHI
Ah, everyone’s favorite topic, third parties and supply chains!
Third on the list are third-party NHIs and their role in integrating with IDEs, extensions, third-party SaaS applications, and more. In 2024, security researchers discovered that the Visual Studio Code marketplace had been used to infect millions of installations through thousands of malicious VSCode extensions.
As OWASP points out, these extensions often require significant access to the developer’s machine and, by extension, the resources and systems they interact with. Examples of external systems and services they cite include version control systems, databases, VMs, and cloud environments.
Due to this, third parties are often provided with API keys, access tokens, and SSH keys. These credentials can be used maliciously to impact environments, move laterally, introduce compromised code into the SDLC, and more.
This is a topic I tried to emphasize quite a bit in my book “Software Transparency Supply Chain Security in an Era of a Software-Driven Society” in 2023, and this attack vector has only seen increased activity and creativity from malicious actors going into 2025.
Mitigations
To mitigate the risks of third-party NHIs, OWASP recommends activities such as vetting and limiting third-party integrations, monitoring and detecting third-party behavior, and using ephemeral credentials or at least rotating them.
That said, I will say this is easier said than done in large, complex environments with thousands of developers, endpoints, extensions, SaaS applications, and more. As I have written in articles such as “The why and how of SaaS Governance,” organizations often use hundreds or even thousands of SaaS apps, with little to no visibility or inventory by the security and governance teams.
NHI4: 2025 Insecure Authentication
Again, we emphasize developers and their integration with internal and external services, including SaaS applications and cloud environments. As OWASP points out, these various internal and external services support and utilize various authentication methods, some of which may be obsolete, vulnerable, or insecure. OWASP recommends that developers utilize standardized protocols such as OAuth 2.1 and OpenID Connect (OIDC) instead.
OWASP then provides example attack scenarios involving the risk of insecure authentication, such as deprecated OAuth flows, app passwords bypassing MFA, and legacy authentication protocols that don’t use modern security standards, such as OAuth.
Mitigations
OWASP recommends mitigations to prevent risks from insecure authentication, such as adopting modern authentication standards (e.g., OAuth 2.1 and OIDC), leveraging credential-less methods, standardizing OAuth implementations, and conducting regular security audits of the authentication methods in use to phase out deprecated or insecure implementations and configurations.
NHI5: 2025 Overprivileged NHI
A fundamental issue that has plagued identity and access management literally since the earliest days of cybersecurity is a lack of least-permissive access control. Despite getting increased attention lately due to trends such as Zero Trust and in sources such as NIST’s 800-207, least-permissive access has been a longstanding cybersecurity best practice.
However, technology trends such as cloud computing have seemed to make the problem worse rather than better. An analysis of hundreds of thousands of identities across tens of thousands of cloud environments and hundreds of organizations found that 99% of cloud identities are too permissive.
Given we’ve historically struggled with this challenge, it is no surprise to see it on the OWASP NHI Top 10, and the exponential number of NHIs compared to human identities makes the problem even more severe.
As OWASP states, right-sizing privileges for NHIs is difficult and time-consuming. Thus, it is unlikely that organizations can constantly keep these permissions in check, especially without sufficient tooling and capabilities to assist them in doing so.
Ask yourself: If we combine several of the risks, such as improper offboarding long-lived NHIs, which are overly permissive and ripe for the taking by malicious actors, how will that work out for organizations?
Not well.
This creates a situation in which the compromise of these NHIs can have an outsized impact on blast radius, lateral movement, access to sensitive data, and more.
OWASP provides example attack scenarios, including overprivileged web server users, VMs, OAuth applications, and service accounts with excessive permissions.
Mitigations
Mitigations OWASP recommends include enforcing the principle of least privilege, regularly auditing and reviewing permissions, establishing preventative guardrails, and leveraging Just-in-Time (JIT) access.
The deceptive part of this is how simple “enforcing the principle of least privilege” seems on the surface, but as any practitioner knows, when you’re in a large complex environment with several Identity Providers (IdP), thousands of identities/credentials, and more, doing this is anything but trivial and is exactly why it is a problem that has impacted cybersecurity since its inception.
NHI6:2025 Insecure Cloud Deployment Configurations
It shouldn’t come as news to anyone who works in or around cloud environments that insecure configurations are a major risk and have been for quite some time. This includes organizations such as Gartner, stating that 99% of cloud security incidents are due to customer misconfigurations. When we look at major incidents in the cloud, this often proves to be true due to issues with storage, buckets, encryption, publicly exposed assets, and more.
OWASP’s approach to this one is a bit interesting since it is dubbed insecure cloud deployment configurations but focuses heavily on CI/CD pipelines. Nonetheless, they discuss how credentials tied to code repositories, logs, or configuration files and stored/transmitted through CI/CD environments can be compromised and abused to bypass MFA, move laterally, and more. They emphasize more secure options such as OIDC to allow CI/CD pipelines to obtain short-lived dynamically generated tokens for authentication as opposed to static long-lived credentials.
Mitigations
Recommended mitigations include using OIDC for secure authentication, moving away from static credentials to dynamically generated tokens via OIDC, enforcing least-privilege permissions for CI/CD pipelines, restricting trust relationships in IAM roles, avoiding hard-coded credentials, and using tools such as AWS Secrets Manager and Azure Key Fault instead. Lastly, scanning repositories regularly for exposed credentials.
NHI7:2025 Long-Lived Secrets
As mentioned, NHIs often involve API keys, tokens, encryption keys, and certificates. Long-lived secrets are those without expiration dates or overly extended expiration dates. OWASP mentions that these secrets facilitate application authentication and integration for services and resources within organizations.
Long-lived credentials of any kind are problematic for attackers because they can be an enticing target. Secrets are no different. They can lead to privileged escalation via stale and stolen access tokens and session hijacking via stolen long-lived cookies, and they present yet another target lying in wait for compromise and abuse.
Mitigations
OWASP recommends enabling automated key rotation, implementing short-lived credentials, adopting zero-trust principles, and enforcing the principle of least privilege. This combination of mitigations makes secrets more ephemeral and dynamic and bolsters the architecture to limit the blast radius if a secret is compromised.
NHI8: 2025 Environment Isolation
Much like the previous Top 10 item involving implementing zero trust principles, environment isolation can mitigate the impact if/when incidents do occur involving NHIs.
Environment isolation is a commonly cited practice in secure software development and cybersecurity, and it is also mentioned in other sources, such as the NIST Secure Software Development Framework (SSDF).
While environments may differ among organizations and development teams (e.g., Dev, Test, Prod, etc.), the fundamental principles of environment isolation are universally relevant.
OWASP recommends using separate NHIs for each environment, applying the least-privilege principle, implementing environment-specific access controls, and regularly auditing and monitoring NHIs for unauthorized access attempts. Following these principles limits the potential of a compromise or incident in one environment impacting others.
Mitigations
OWASP recommends specific mitigations in addition to what I discussed above. These include strict environment isolation for NHIs, applying the principle of least privilege, enforcing environment-specific access controls, and segregating infrastructure for sensitive resources. Again, the theme here is mitigating systemic impacts and limiting them to specific environments through these mitigating controls and measures.
NHI9:2025 NHI Reuse
Much like some of the other Top 10 we have discussed, credential reuse has long been something practitioners have cautioned against and has made its way into various compliance frameworks, best practices guides, and more. That is why it is unsurprising to see it listed here for NHIs.
As the table above mentions, tailoring granular permissions for each NHI can be complicated, so organizations may default to reusing NHIs with broad permissions. This makes them compelling targets for exploitation with widespread ramifications for impact if compromised.
OWASP discusses how NHIs such as service accounts, API keys, and machine credentials are fundamental to modern applications, services, and authentication and authorization.
If organizations are reusing NHIs across several applications and services, the potential for impact is significant and can lead to vulnerability/attack chaining and widespread impact for an organization if one of the NHIs that is reused is compromised, especially if it is overprivileged (NHI5) and there is a lack of environment isolation (NHI8).
OWASP provides examples such as reusing Kubernetes service accounts, sharing API keys between applications, and reusing cloud credentials such as AWS IAM Roles across different services and resources.
Mitigations
To mitigate these risks, OWASP recommends assigning unique NHIs to each application or service and the environment, enforcing the principle of least privilege, and auditing and reviewing the use of NHIs.
NHI10:2025 Human Use of NHI
Last but not least on the list is human use of NHIs.
The entire purpose of NHIs, such as service accounts, API tokens, workload identities, and secrets, is to enable programmatic access to applications and services. That said, as OWASP discusses, it isn’t uncommon for developers or uses to misuse the NHIs for manual tasks as opposed to the original intent of automated activities and workflows.
This poses several risks because human activities could be perceived as being programmatic, limiting auditing and monitoring, covering up activities by benign insiders, or even insider threats, and, most notably, potential attackers.
OWASP cites example scenarios such as administrators using service account credentials, developers executing commands with NHIs, sharing API tokens among team members, and even attackers leveraging NHIs for persistence.
Mitigations
The final set of mitigations for the least risk in the OWASP NHI Top 10 involves using dedicated identities, auditing and monitoring NHI activity (one we’ve seen several times), using context-aware access controls, and educating developers and administrators on the risk of human use of NHIs. These measures provide both technical and cultural controls to limit the human use of NHIs and the associated risks that they present.
Closing Thoughts
This concludes an overview of the newly published OWASP NHI Top 10 Risks. If you’re an experienced practitioner, many of the risks may not look “new” in terms of fundamental best practices and recommendations that we’re familiar with.
The challenge is the 30-50x scale of NHIs compared to human users and credentials in environments. Complex cloud, hybrid cloud, multi-cloud, CI/CD, and containerized environments are increasingly leveraging NHIs to facilitate programmatic access and activities in modern digital environments.
While many of the mitigations and recommendations aren’t “complex”, trying to do them in large-scale enterprise environments with legacy tooling is nearly impossible, and that is why we continue to see innovative solutions entering the market and getting traction with security leaders and organizations trying to tackle this challenge.