Understanding OWASP’s Top 10 list of non-human identity critical risks – Source: www.csoonline.com

There are some very good reasons why non-human identities (NHI) have landed among the most-discussed cybersecurity topics in the last few years — it’s estimated that for every 1,000 human users in an enterprise network, there are 10,000 non-human connections or credentials.

Some estimates peg that ratio even higher at 10 to 50 times the number of human identities in an organization. When we recognize that credentials remain the leading attack vector in security breaches, (as per Verizon’s Data Breach Investigations Report) we can see why this would be a problem.

That’s why it is great to see OWASP publish its first-ever Non-Human Identities Top 10 list of critical risks to raise awareness of NHI-related security challenges, provide actionable insights into key NHI risks, and help organizations prioritize accompanying best practices.

To highlight the security challenges posed by NHIs, OWASP points to several notable recent incidents, such as Microsoft’s Midnight Blizzard Breach (2024), Internet Archive’s Zendesk Support Platform Breach (2024), and the Okta Support System Breach (2023), all of which involved NHIs.

OWASP’s NHI risk No. 1: Improper offboarding

We all know the story of employees, contractors, and resources coming in, getting accounts and access, then changing roles or leaving the organization. In many cases, their accounts remain in the system indefinitely as orphaned accounts or credentials that live in environments.

This scenario also occurs with NHIs, and as mentioned above, 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 the implementation of 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, it is recommended that offboarding steps be automated where possible and active NHIs be regularly audited 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.

NHI risk No. 2: 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. There are many 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 in situations where secret leakage led to an incident.

Mitigation

Recommended steps for mitigating the risks of secret leakage include using ephemeral credentials, deploying 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, which is why secrets management tools and vendors who offer these capabilities are key.

NHI risk No. 3: Vulnerable third-party NHI

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 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.

Mitigation

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.

NHI risk No. 4: Insecure authentication

Here OWASP emphasizes developers’ integration with internal and external services, including SaaS applications and cloud environments. As it 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.

NHI risk No. 5: Overprivileged NHI

A fundamental issue that has plagued identity and access management since the earliest days of cybersecurity is a lack of least-permissive access control. Despite increasing 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 made 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 that 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 risks, such as improper offboarding of 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, thousands of identities and credentials, and more, doing this is anything but trivial and is precisely why it is a problem that has impacted cybersecurity since its inception.

NHI risk No. 6: Insecure cloud deployment configurations

It shouldn’t come as news to anyone who works in or around cloud environments that insecure configurations constitute a significant risk and have done for quite some time. This includes organizations such as Gartner, which stated that 99% of cloud security incidents are due to customer misconfigurations.

When we look at significant incidents in the cloud, this often proves to be accurate due to issues with storage, buckets, encryption, publicly exposed assets, and more.

OWASP’s approach to this is interesting since it is dubbed insecure cloud deployment configurations but focuses heavily on CI/CD pipelines. Nonetheless, it discusses 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. OWASP emphasize more secure options such as OIDC to allow CI/CD pipelines to obtain short-lived dynamically generated tokens for authentication instead of 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 and lastly, scanning repositories regularly for exposed credentials.

NHI risk No. 7: Long-lived secrets

NHIs often involve secret data such as 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 because they can be an enticing target for an attacker and 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.

NHI risk No. 8: Lack of environment isolation

Along with the implementation of zero-trust principles, environment isolation can mitigate the impact if and 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 those discussed above, including 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.

NHI risk No. 9: Reusing NHIs

Credential reuse has long been something practitioners have cautioned against but has nevertheless made its way into various compliance frameworks, best practices guides, and more. That is why it is unsurprising to see it listed here as a risk factor 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, authentication, and authorization.

Suppose organizations are reusing NHIs across several applications and services. In that case, the potential for impact is significant — it 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). 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.

NHI risk No. 10: Human use of NHI

NHIs, such as service accounts, API tokens, workload identities, and secrets, enable programmatic access to applications and services. That said, as OWASP discusses, it isn’t uncommon for developers or users to misuse NHIs for manual tasks rather than the original intent of automated activities and workflows.

This poses several risks because human activities could be perceived as 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 technical and cultural controls to limit the human use of NHIs and their associated risks.