Understanding Non-Human Identities: The hidden risks of Automated Access

Automated Access, hidden risk: Understanding Non-Human Identities

As modern infrastructures grow more complex, the notion of identity extends far beyond human users alone. Systems, applications, cloud services, and other software entities interact with and access critical resources. These non-human actors, referred to as non-human identities (NHIs), play an increasingly central role in the functioning of organizations.

During my time as a penetration tester, I leveraged multiple times exposed or mismanaged Non-Human Identities (NHIs) to gain initial access or deepen my foothold within the environments I was auditing.

Understanding their nature, associated risks, and best practices for their management has become imperative for robust cybersecurity.

What is a Non-Human Identity?

A non-human identity stands for any digital entity that requires authentication and authorization to access resources but is not a human user. This encompasses a vast category of elements, including:

• Service accounts: Used by applications and services to interact with the operating system, databases, or other applications.
• API keys: Allow applications to communicate with each other without human intervention.
• Secrets and certificates: Used for authentication and encryption.
• Cloud workloads: Virtual machine instances, containers, and serverless functions running in the cloud.
• Bots and automated scripts: Perform repetitive tasks and interact with other systems. (You may use one of those for sending messages on your Slack or Discord Channel)
• IoT (Internet of Things) devices: Sensors, cameras, and other connected devices that communicate and exchange data.

When discussing Non-Human Identities (NHI), the focus often shifts quickly to API keys and JWT tokens. They are common mechanisms widely used today by services and applications to authenticate and communicate securely but NHI can be of many forms, basic username and password credentials, certificates, etc.

It’s also important to remember that human users can act through NHIs. For example, when a person uses a web application that makes backend API calls, the actual interaction with the system is performed by a non-human identity (example: a service account or system token), even though the intent originates from a human.

And sometimes, simply because humans are human, they end up using service account credentials directly. It’s a familiar, convenient workaround that grants elevated privileges with minimal friction.

Why are NHIs a Major Security Concern?

The proliferation of NHIs significantly complicates the security landscape. Several factors contribute to this challenge:

• Volume and diversity: NHIs often outnumber human users by far, and they come in many forms (microservices, bots, scheduled jobs, cloud functions) making them difficult to inventory and govern consistently.
• Lack of visibility: Unlike user accounts, NHIs are often undocumented or hidden within infrastructure layers. Moreover, the absence of defined ownership and comprehensive lifecycle management introduces critical visibility gaps in security telemetry and incident response workflows.
• Complex access management: Assigning and revoking permissions for NHIs is challenging. Without strict governance, NHIs can accumulate excessive or outdated privileges, increasing the risk of lateral movement or privilege escalation.
• Default Privileges and Overprovisioning: NHIs are often created with default or inherited privileges, typically matching the permissions of the user or system that created them. For example, when generating a GitHub or GitLab personal access token, it may default to broad scopes unless explicitly restricted. Unfortunately, tooling to automatically reduce or right-size these permissions is limited, leading to persistent overexposure.
• Secrets rotation: NHI relies on credentials like API keys, tokens, and certificates. These are often hardcoded, poorly rotated, or forgotten entirely (again leaving systems vulnerable to long-term compromise.)
• Limited monitoring: Non-Human Identity (NHI) activity is often under-monitored, with limited real-time visibility or behavioral analysis. Unlike human users, NHIs may operate silently in the background. They are rarely triggering alerts or being scrutinized in security dashboards. This lack of oversight creates a dangerous blind spot, where misconfigurations or malicious behavior can persist undetected for extended periods of time.
• Privileged targets: Due to their broad and often privileged access, NHIs are attractive targets for attackers. Compromising an NHI can provide a stealthy and powerful foothold for lateral movement or data exfiltration. (Jackpot I have a key to execute request on Azure Graph API, yoo-hoo!)

Ironically, it’s often not until a penetration test or external audit is conducted that these issues surface. Suddenly revealing critical gaps to the CISO and security leadership. This reactive discovery underscores a systemic weakness: organizations are often unaware of how exposed their NHI landscape truly is until someone actively tries to break it. And even then, Security and IT teams are often left uncertain about how to respond effectively.

Let’s use some real-life statistics to visualize this even better. The following statistics are drawn from GitGuardian’s “The State of the Secret Sprawl 2025” report.

In 2024, GitGuardian detected a staggering 23.8 million secrets leaked in public GitHub repositories. An astonishing 25% increase from the previous year. Alarmingly, 4.6% of all public repositories and 35% of private ones held at least one exposed secret, with private repos often being treated with less caution due to a false sense of security. Even more concerning is the persistence of these leaks: 70% of secrets exposed in 2022 were still active in 2024, highlighting a major remediation gap. MongoDB credentials were the most commonly leaked in public repositories, accounting for 18.8% of cases, while AWS IAM keys appeared in 8% of private repositories. This is five times more than in public ones. This persistent problem is largely driven by the use of long-lived credentials, the absence of expiration policies, and a lack of automated workflows for secret rotation and revocation.

Risks Associated with Non-Human Identities (OWASP Top 10 NHI)

The OWASP (Open Web Application Security Project) recently published a Top 10 list of risks related to non-human identities, highlighting their growing importance in the field of security:

1. Inadequate Inventory and Management of NHIs: Lack of visibility and control over existing NHIs.
2. Hardcoded Secrets: Inclusion of API keys, passwords, or certificates directly in code or configuration files.
3. Compromised Secrets Management: Insecure storage or insufficient rotation of secrets.
4. Excessive Permissions: Granting NHIs broader access rights than necessary for their functions.
5. Lack of Strong Authentication and Authorization: Use of weak authentication methods or absence of robust authorization policies.
6. Insufficient Monitoring and Auditing: Lack of tracking of NHI activity to detect anomalous behavior.
7. Insecure Provisioning and Deprovisioning: Inadequate processes for creating and deleting NHIs, potentially leaving orphaned access.
8. Malicious Use of NHIs: Compromise of NHIs by attackers to carry out illegitimate activities.
9. Vulnerabilities in NHI Management Platforms: Security weaknesses in the tools used to manage NHIs themselves.
10. Lack of NHI Lifecycle Management: Absence of clear policies for the creation, use, revocation, and deletion of NHIs.

I personally encourage anyone interested in the subject to read it as a starting point and all other linked articles on OWASP website.

Best Practices for Managing Non-Human Identities

To effectively manage the growing security risks associated with NHIs, organizations must adopt a proactive, structured, and lifecycle-based approach. This means embedding NHI governance into the core of identity and access management (IAM) practices.

Awareness and training

First thing that comes to my mind when I am asked about securing NHI is to educate teams on the importance of NHI security and best practices. If you can create some CTF like challenge which imply abuse of NHI (Hello terraform project repository)

Comprehensive discovery and inventory:

As for human users privileges the first step is to identify/discover all NHIs across your infrastructure and evaluate their associated privileges. Tools like (find example) can help automate the discovery of service accounts, tokens, and machine identities across cloud and on-prem environments.

Centralized secrets management:

Use secure vaults such as Wallix Bastion or OpenBAO Vault to manage API keys, tokens, and certificates. These platforms provide encryption, access control, and audit logging for all secrets.

Principle of least privilege:

Ensure NHIs are granted only the permissions they need, kind of obvious but always good to mention and implement robust authentication mechanisms and granular authorization policies.

1. Regular secrets rotation: Platforms like OpenBAO and WALLIX Vault support automated secrets rotation policies, ensuring that credentials are regularly refreshed without manual intervention (reducing the risk of long-lived secrets).
2. Continuous monitoring and auditing: Implement tools to monitor NHI activity and detect anomalies.
3. Automation of provisioning and deprovisioning: Use automated processes for creating and deleting NHIs to avoid unmanaged access most CI/CD can support NHI lifecycle automation through interconnection to a vault, functions, plugins, or imagination.
4. Adoption of an NHI lifecycle: Define and enforce policies for the full lifecycle of NHIs from creation to termination. Add a clear article in your IT Security Policy shared with all employees. Often vaults solution provides lifecycle hooks and metadata tagging to track ownership, purpose, and expiration.
5. Regular NHI-Specific Security Assessments: Do not focus solely on individual applications or overall company security security when conducting Security assessments. Conduct targeted audits and penetration tests focused on NHIs. For example, test the scope of GitLab or GitHub tokens created by developer, often these are over-permissioned by default and rarely rotated.

Hardware security

For Non-Human Identities (NHIs), using hardware-based security like TPM 2.0 is a best practice to ensure trust and integrity. TPM 2.0 securely stores cryptographic keys, supports secure boot, and enables device attestation, helping verify that only trusted NHIs can access sensitive systems or data. This strengthens identity binding and protects against tampering at the hardware level. Strong authentication and authorization.

Conclusion

Non-Human Identities (NHIs) have become foundational to modern digital ecosystems, powering automation, scalability, and integration across platforms.

However, with their growing presence comes a parallel rise in risk. And we haven’t even touched on the explosive combo of NHIs and AI (like when your AI assistant in VS Code suddenly has access to your entire source code full of NHI…)

Securely managing NHIs is no longer optional; it’s a strategic imperative for protecting critical systems and data and yet another thing to add on the critical security roadmap.

By recognizing the unique challenges NHIs present and implementing robust governance, organizations can transform a potential vulnerability into a strength. Proactive discovery, least-privilege access, lifecycle management, and continuous monitoring are not just best practices, they are essential defenses in today’s threat landscape.

Investing in NHI security today is an investment in the resilience, trust, and safety of tomorrow’s digital infrastructure.