OWASP Top 10 Non-Human Identity Risks for 2025: What You Need to Know

The Open Worldwide Application Security Project, OWASP, has just released its Top 10 Non-Human Identities Risks for 2025. While other OWASP resources broadly address application and API security, none focus specifically on the unique challenges of NHIs. This new document fills that gap, addressing risks that are often overlooked but have critical implications for organizational security. 

This release is a significant milestone in the cybersecurity landscape, as one of the most trusted security communities now recognizes the term Non-Human identities (NHIs) and that this is a significant issue that needs to be addressed by the enterprise. Given the growing number of breaches stemming from NHI credential leaks or misuse, this release is very timely.

Before we look closer at the contents of this new NHI-focused top 10 list, let's first reflect on the trends that got us here. 

Non-Human Identities Are a Growing Attack Surface

Non-Human identities, also commonly referred to as machine identities or workload identities, perform actions within a system, most commonly interacting exclusively with other non-human entities. We dive further into the definition and what this means in our article on NHI governance challenges if you want to read further. 

The last decade has seen an explosion of NHIs in the enterprise, driven by the rise in cloud computing, increasing reliance on third-party services via APIs, and the development of machine learning models and their agents. Existing Identity and Access Management (IAM) tools have traditionally focused on human users.  Many organizations struggle to apply the same rigor to NHIs, such as enforcing least privilege, managing credentials, or auditing access.  

Part of the issue driving the need for a better approach to NHIs is the lack of clear definitions of ownership for NHIs. If developers introduce a new service, are they ultimately responsible for it in production? What about the end of life for that NHI? Does the IAM team own these identities, or does IT or Security own them?

This general confusion about who is responsible cuts across all teams and departments in the modern enterprise. The lack of clear NHI governance policies, especially in a world where shadow IT accounts for over 50% of the total enterprise tech spend, according to Gartner estimates, means that we need to rethink our relationship with these non-human actors. This OWASP document marks a clear line in the sand on what needs to be done now.

With that in mind, let's take a closer look at the specifics in the OWASP's newest list.

A Closer Look at the Top 10 Non-Human Identities Risks for 2025

NHI1:2025 Improper Offboarding

NHIs, such as access keys or service accounts, more often than not, live longer than they should. While offboarding human access to our critical systems is very top of mind for IAM teams, decommissioning machine resources is often left up to "someone" in the future, likely someone other than the original team member who implemented it. 

All too often, only the calls to these NHIs are deprecated in code, but the underlying service is never deactivated when they’re no longer needed. Once forgotten about, these still-running and permissioned NHIs will most likely never be patched, which makes them a perfect target for exploitation.

Enterprises must implement automated lifecycle management for NHIs to detect and deactivate unused identities. At GitGuardian, we are working to help companies achieve this by discovering what NHIs exist and, importantly, where they are stored and what systems they are accessing.  Deprecated or unused identities can be quickly identified and safely deactivated. 

This should not be seen as a one-time exercise; enterprises need to continually scan and monitor for these "zombie NHIs." With development teams only ever releasing faster, the identities going out of service are happening more often and need to be addressed from a governance, tooling, and workflow perspective.

NHI2:2025 Secret Leakage

Any NHI in a secure application is necessarily going to have a credential, such as an API key, a certificate, or an authentication token. According to research from AKEYLESS, 80% of breaches are tied to identities, and 83% involve compromised credentials. Given the known state of secrets sprawl, this should not be a surprise here in 2025.

GitGuardian has always been focused on helping teams tackle this growing problem. We have introduced NHI Governance as the focus of our platform as we have witnessed NHIs outnumber human identities by 45 to 1 in 2022 and, by some estimates, over 100 to 1 in 2024. Taking on the issue of NHI governance means necessarily dealing with hardcoded credentials and plaintext secrets ending up in places where attackers can readily exploit them. We are going to continue innovating to help enterprises focus on solving this issue at scale, with automation and the lowest false positive rates of any detection tool.

NHI3:2025 Vulnerable Third-Party NHI

Modern applications are almost entirely dependent on connecting to third-party services. It is rare that an application can exist entirely independently without needing to get data from another party or communicate with another service. While we can implement governance policies for our own custom code and tools, we have to be extremely vigilant that our technology partners and vendors are also exercising the same security practices. 

But with so many services integrated into our product and applications, how can we keep track of what is being called by which process? One perspective is to map your system from the viewpoint of how these machine identities securely communicate, which relies on secrets. Once you clearly understand which services are actively being called, it becomes much easier to ensure that regular updates are being delivered, especially for third-party systems interacting with mission-critical data.

The new GitGuardian Secret Analyzer can also help ensure that the principle of least privilege is being followed. For example, if you discover a third party is given write access to your customer data, maybe that is something that needs to be addressed. 

NHI4:2025 Insecure Authentication

Not all authentication methods are created equally secure. Some methods that were once considered the gold standard, such as SHA1, are now easily crackable and should be avoided at almost any cost. All encryption and authentication methods need to be periodically reviewed as technology evolves.  This is only possible if you clearly understand what systems are in play, which is where GitGuardian can help. Understanding that a service is still using a long-lived API Key when other, better options are available is the first step toward building more secure and robust systems.

NHI5:2025 Overprivileged NHI

One of the challenges every developer faces when introducing a new NHI into their application is how to scope the granted permissions properly. It cannot do the work if you don't give this new identity enough access. Giving an NHI too much authority increases your risks if an attacker gets their hands on it. While this worry is true for the initial developer, it is also a concern when it comes time to rotate that secret.

Enterprises need to regularly review and enforce least-privilege policies. This is commonly done for human identities, with mature tooling automating the review process, but this is a challenge the NHI space is only now coming to deal with at scale across all industries.

This is exactly where GitGuardian has been focused, helping companies not only find all of their secrets, and therefore NHIs, while quickly exposing the permissions granted. This can greatly speed up the rotation process, leading to faster remediations while helping teams implement better authorization strategies over the long term. 

NHI6:2025 Insecure Cloud Deployment Configurations

In order for an NHI to use a credential throughout a CI/CD pipeline, that credential must be stored somewhere. From a pure development perspective, one of the easiest (laziest) ways to store these is to hardcode those secrets in the configuration files as part of the application's repo. This is obviously an insecure path, but given the number of .env files we find in our public monitoring research and the fact that 50% of them contain a secret, this is an all too common approach many developers are still implementing. Attackers are counting on this.

GitGuardian can accurately detect and validate any secrets associated with your CI/CD tools. Once you are aware of these credentials and the context of how they are used you can update how you are storing these secrets to use a proper Secrets Management platform, such as CyberArk's Conjur or Vault by HashiCorp or platform-specific tooling. You can also leverage the contextual insights GitGuardian provides to ensure that you are not using stale, long-lived credentials, rotating them regularly. 

NHI7:2025 Long-Lived Secrets

There is nothing an adversary loves more than finding a key that has no expiration date. If a leaked key is valid for years, as was the case with the Toyota leak, then the attacker can simply walk in and out of your systems as often as they want, whenever they want. On the other hand, if a bad actor gets their hands on an old secret that has already been rotated, meaning invalidated and replaced, then there is not much they can do with it. 

The best secrets are the ones that do not exist. The next best are secrets that have a very short lifetime, maybe being used only once and issued at run time. The shorter the window the secret is active, the smaller the attack window where a breach can occur. One of the goals of GitGuardian's NHI Security is to expose the lifecycle of your machine identities, making it easy to understand when the secret was created, when it went out of use, and when it was last rotated. It can give teams the insight they need to eliminate long-lived credentials wherever they exist and for every NHI in the organization. 

NHI8:2025 Environment Isolation

Environment isolation refers to a long-understood idea in DevOps that every system needs to be dedicated to its phase in the software development lifecycle (SDLC). For instance, production data should never be accessible from the development or staging environments. Test environment credentials should never allow access to the production servers. However, in the world of NHIs, especially considering third-party services and their licensing costs, developers all too often reuse the same NHIs across all parts of the pipeline and throughout the SDLC.

GitGuardian believes the first step in enforcing a one-to-one policy of dedicated NHIs for the proper environment is to understand what NHIs are in play. The context we are able to discover and provide to teams can quickly help them see where and how a secret is being used. This centralized view of your NHIs is essential to establishing and maintaining good machine identity governance.

NHI9:2025 NHI Reuse

The idea of using NHIs between entirely different applications is highly related to environment isolation. While the previous list entry is focused on the same NHI used throughout the SDLC, an alarming trend we have seen is using the same identity and permissions across multiple platforms that can expose all the data to an attacker. Imagine an attacker finding out the key they have unlocks doors across multiple projects; it would be a good day for them and a bad day for your incident response team, especially as revoking that secret might bring down multiple parts of the business.

As with environment isolation, understanding the context for how these secrets are being used is the first step to solving this concern. This is why we are proud of our new vault integrations, helping enterprises audit all their secrets, not just detect the ones in plaintext in code and productivity tools. Once you have a holistic mapping of your NHIs, teams can build and enforce policies for 1-to-1 NHI-to-application use. 

NHI10:2025 Human Use of NHI

If an unknown person showed up on your doorstep and had a key to your house, would you automatically let them in? What if it wasn't even a person, but instead, a non-human? While that is scary to ponder, the reality is that for the majority of our machine identities, they do not care who is using the key, they just grant the entity access based on possessing the credential.

Being able to identify when a key is used by an NHI on an approved "allow list" is key to detecting and reacting to breaches. Anomalous use of a key should be something every organization strives for in their monitoring. 

But if you don't know what keys you have, it is impossible to know what to look for. GitGuardian can help your organization understand how these secrets should be used and make it much easier to write access policies and enforce them. In the longer term, being able to map all of your NHIs and how they access services is the first step toward more robust identity access for everyone, with frameworks like SPIFF, for example.

Strategic Recommendations for Mitigating NHI Risks

While the new Top 10 Non-Human Identities Risks spell out the concerns, it is up to every organization to take action to meet these challenges. We would love to partner with you to achieve the following: 

• Implement Centralized NHI Management - Use tools and platforms to centralize the management, monitoring, and rotation of NHIs.
• Adopt Automation - Automate key processes like secret rotation, offboarding, and access control reviews to reduce human error and improve scalability.
• Educate Development Teams - Train developers on secure practices for managing NHIs, including avoiding hardcoded secrets and adhering to least privilege principles.
• Integrate into DevSecOps Pipelines - Incorporate NHI scanning and security validation into CI/CD pipelines to catch vulnerabilities early.
• Monitor Continuously - Contstaly scan to detect improper usage, leaked secrets, or potential abuse of NHIs in real-time.

A New Year For NHI Security

OWASP and its Top 10 projects are widely regarded as authoritative, providing actionable frameworks for organizations of all sizes. With the release of this new NHI-focused Top 10, enterprises will hopefully take action to identify and prioritize risks associated with this growing and largely ungoverned attack surface.

This release marks a pivotal moment for enterprise security and IAM overall. It elevates the importance of NHIs, providing a dedicated framework to help teams tackle the unique challenges mounting in every enterprise. As organizations increasingly rely on automation and machine-to-machine communication, this document ensures that the industry can address these risks with clarity and consistency, paving the way for a more secure digital ecosystem.

GitGuardian is here to help you navigate the challenges of implementing NHI security and meeting the challenges laid out by OWASP and others beyond just this abbreviated list of concerns. We would love to help you discover all your machine identities, understand the context around these identities, and improve your overall security posture. We would love to talk about these challenges and map a path forward with you.