Table of contents

According to an analysis by the Orca Research Pod, non-human identities (NHIs) outnumber their human counterparts by an average of 50:1. With a rise in automated processes and AI services in the cloud, the number of NHIs continues to rapidly increase. NHIs play a crucial role in cloud computing, powering critical applications and efficient operations by enabling digital identities to gain the cloud access and permissions they need. 

Yet NHIs also present an attractive target for attackers. A study last year by the Enterprise Strategy Group found that 66% of organizations experienced a security incident caused by a compromised NHI. These identities present enormous challenges for security teams by often maintaining elevated privileges, broad access to a variety of systems, and weak access controls. Once configured, NHIs often become forgotten, expanding the attack surface and offering threat actors an attractive target for exploitation.

The prevalence of NHIs, and the risks they present, highlights why OWASP recently launched its latest project: OWASP Non-Human Identities Top 10. To spearhead the project, OWASP solicited the help of Orca Security and several other leading security vendors.

In this article, we explore the OWASP Non-Human Identities Top 10 project in detail, revealing how it applies to cloud security and key findings from the Orca Research Pod. We also present best practices that can help your organization protect against the top NHI risks of 2025. 

What is the OWASP Non-Human Identities Top 10 Project?

The OWASP Non-Human Identities Top 10 list provides a ranking of the most critical NHI risks, providing practical guidance for security and development teams. The list leverages the OWASP Risk Rating Methodology and contributions from top cybersecurity experts and organizations, including members of the Orca Research Pod. 

Below is a look at the OWASP NHI Top 10 list for 2025: 

A deep dive into the NHI Top 10

The following section analyzes each of the OWASP NHI Top 10 risks in detail. Included in the analysis are key research findings discovered by the Orca Research Pod based on billions of scans performed by Orca Security during the past 30 days.

1. NHI1:2025 – Improper Offboarding

The top NHI risk of 2025, improper offboarding occurs when organizations fail to properly remove NHIs or deactivate them when they are no longer needed. This oversight can leave outdated services unmonitored and susceptible to exploitation, allowing attackers to gain unauthorized access to sensitive data and systems.  

Based on our analysis, improper offboarding remains a prevalent risk in cloud environments. Nearly half (47%) of organizations using AWS have at least one IAM Role connected to a third-party integration that was not used during the past 90 days.

2. NHI2:2025 – Secret Leakage

Secret leakage occurs when sensitive NHIs—including API keys, tokens, encryption keys, and certificates—are unintentionally exposed to unsanctioned data stores in the software development lifecycle (SDLC). This often happens when secrets are hard-coded into source code, stored in plain text configuration files, or shared via unsecured communication channels. Such practices increase the risk of secrets being discovered and exploited by malicious actors. 

In the past several years, secret leakage has caused several high profile security incidents, including the breaches of Uber in 2022 or Mercedes in 2023. 

According to our findings, Secret Leakage continues to be a highly prevalent risk among organizations. We found that 70% of organizations have plaintext secrets embedded in their source code repositories. Of this number, 2% of exposed secrets are active and stored in the current main branch, while 50% are saved in Git history with 4% of those secrets still valid. 

Yet the risk of secret leakage also applies to publicly exposed assets. Our analysis found that 22% of organizations have at least one publicly exposed asset with a long-term, validated vendor secret, such as a cloud service provider access key. By exploiting one of these assets, attackers can steal a valid key and use it to facilitate an account takeover. 

3. NHI3:2025 – Vulnerable Third-Party NHI

Third-party NHIs are extensively integrated into the development workflow, through the use of integrated development environments (IDEs), IDE extensions, and third-party SaaS. If a third-party extension is compromised—whether through a security vulnerability or a malicious update—attackers can exploit it to harvest credentials or misuse granted permissions; hence, the risk of vulnerable third-party NHIs.

Several high-profile incidents arising from this risk include the JetBrains malicious plugin event, where third party access keys were leaked, or the CircleCI incident, where a breach of CI/CD vendor exposed customer secrets.

Our analysis found that organizations use an average of four third-party integrations with NHIs, illustrating their prevalence and the potential risk that vulnerable NHIs present.

4. NHI4:2025 – Insecure Authentication

Developers often integrate third-party services into their applications, which require authentication credentials to access system resources. Yet some of these authentication methods present significant risks, including those vulnerable to known attacks, reliant on outdated security practices, or deprecated. Utilizing insecure or obsolete authentication mechanisms can put organizations at greater risk of potential exploitation. 

5. NHI5:2025 – Overprivileged NHI

During application development and maintenance, users may grant NHIs more privileges than necessary. If an over-privileged NHI is compromised—through application vulnerabilities, malware, or other methods—attackers can exploit these excessive permissions.

Cloud non-human identities can become overprivileged in several ways. 

The first is granting privileged access to roles. According to our analysis, 13% of all cloud roles are privileged, with 53% of organizations granting privileged access to more than 10% of their roles. 

The second is assigning roles excessive permissions that exceed their actual requirements. Our findings reveal that among AWS IAM roles used in the past 30 days, only 55% of their policy permissions were utilized. This means that these policies could be reduced without compromising functionality. 

6. NHI6:2025 – Insecure Cloud Deployment Configurations

Continuous Integration and Continuous Deployment (CI/CD) applications streamline developer workflows, enabling them to automate the building, testing, and deploying of code to production environments. These tools often require authentication with cloud services using static credentials or OpenID Connect (OIDC). 

However, static credentials risk exposure through configuration files, code repositories, or logs, potentially granting attackers persistent, privileged access to production environments. While OIDC provides a more secure alternative, improperly validated identity tokens or weak token claim conditions can still be exploited by unauthorized users.

7. NHI7:2025 – Long-Lived Secrets

Long-lived secrets are sensitive NHIs—such as API keys, tokens, encryption keys, and certificates—that have distant expiration dates or no expiration at all. When such secrets are compromised, attackers can exploit them indefinitely and gain access to sensitive services.

Secrets governance is a complex task to perform at scale. That explains why cloud vendors suggest automating this process with secret storing services like AWS Secrets Manager, Azure Key Vault, and GCP Secrets Manager. 

These services also offer secret rotation to adhere to security best practices. While beneficial, our analysis shows that few organizations use them. For example, only 0.5% of the secrets on GCP Secrets Manager use a defined automatic rotation date. For AWS Secrets Manager, that number rises to only 1.5%.

8. NHI8:2025 – Environment Isolation

Environment isolation is a foundational requirement of secure cloud application deployment, involving separate environments for development, testing, staging, and production. While NHIs play a critical role throughout the application lifecycle, reusing the same NHIs across multiple environments—particularly between testing and production—can create significant security vulnerabilities.

9. NHI9:2025 – NHI Reuse

Reusing the same NHI across multiple applications, services, or components—even when deployed together—presents significant security risks. If an NHI is compromised, attackers can leverage it to access other systems sharing the same credentials.

In cloud environments, role reuse is particularly common. Our analysis shows that 13% of organizations have at least one privileged Instance Profile serving more than 50 different EC2 instances, with 11% of these profiles containing administrative privileges.

10. NHI10:2025 – Human Use of NHI

During application development and maintenance, developers or administrators may improperly use NHIs for manual tasks that human users—with the appropriate privileges—should perform. This practice creates security risks, including elevated privileges for NHIs.  

How can you protect against NHI risks?

To protect against the OWASP NHI Top 10 risks, we recommend implementing the following best practices: 

  1. Locate your secrets: Create an inventory of your secrets, and ensure they are not exposed to the Internet or appear in plaintext.
  2. Follow the Principle of Least Privilege (PoLP): Limit permissions to the minimum that a NHI needs to perform their job, which reduces the risk of lateral movement or escalating privileges. 
  3. Use Just-In-Time (JIT) permissions: JIT allows you to grant temporary access to specific cloud resources for a limited time, allowing you to enforce PoLP and minimize the risks associated with over-permissioning in the cloud. 
  4. Rotate your secrets: Make sure you regularly rotate your secrets to limit your risk exposure in the event of a leak or compromise.
  5. Map your third party integrations: Inventory all your integrations, map their permissions, and implement an offboarding process.
  6. Remove unused and neglected roles: Deactivate or remove any role that has been unused in the last 90 days or longer, ensuring you minimize your attack surface.

How can Orca help?

The Orca Cloud Security Platform is a unified, comprehensive cloud security platform that identifies, prioritizes, and remediates security risks and compliance issues across AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, and Kubernetes. The Orca Platform offers a deeply integrated Cloud Infrastructure Entitlement Management (CIEM) solution, which provides granular, contextual visibility into all identities, configurations, access policies, entitlements, permissions, and activities in your cloud. 

A screenshot of the Orca Platform providing full visibility into your cloud identity and entitlement risks
The Orca Platform provides full visibility into your cloud identity and entitlement risks

With the Orca Platform, you gain a complete inventory of NHIs in your cloud, including any service identities associated with vendors for immediate insight into your supply-chain risks. 

For each identity, Orca shows its attached IAM policy, a detailed access map showing effective permissions to and from the cloud identity to other cloud assets, risks associated with the identity, its impact on compliance, and other metadata. Orca also provides PoLP policy recommendations to rightsize permissions when applicable. 

An example of Orca providing deep visibility into each NHI, including its associated risks, effective permissions, and more
Orca provides deep visibility into each NHI, including its associated risks, effective permissions, and more

Learn More

Interested in discovering the benefits of the Orca Platform and its CIEM capabilities? Schedule a personalized 1:1 demo, and we’ll demonstrate how Orca can effectively secure your identities and entitlements.

Appendix – Methodologies

Ratio of NHI comparing to human identities was made by comparing the count of these human identities: ("Azure User" OR "AWS User" OR "GCP User") to these non human identities: ("GCP IAM Role" OR "AWS IAM Role" OR "Azure Service Principal" OR "GCP IAM  Service Account")

NHI1:2025 – Improper Off boarding – The query contained all third party applications detected in the cloud account (as per Orca’s scan of the account), that has an AWS IAM role assigned for this integration, and last used more than 90 days ago.

 NHI2:2025 – Secret Leakage – The query is based on API keys found by Orca Shift Left CLI scan on code repositories. The second query is using the detection of AWS config files containing both access key ID and the secret access key and Orca detection for publicly accessible VMs.

NHI3:2025 – The query is based on roles that are assumed by Third Party integrations covered by Orca.

NH5:2025 – Overprivileged NHI – The privileges calculation is based on the aggregate of all policies and permissions granted to an NHI. To find out how this aggregation is performed in AWS, you can visit our IAM APE Open Source tool. The second query is an analysis made by Orca by analyzing the granted permissions compared to the cloud providers reports of recently used services per entity.

NHI7:2025 – For GCP we queried the fields “rotation” and “nextRotationTime”. For AWS we queried the field “RotationEnabled”

NHI9:2025 – Is based on aggregations of Instance Profiles ARNs

Table of contents