Securing non-human identities: Part 2 Understanding the security risks of NHIs and mitigating them

Hardly a month ago, two AI Agents chatting up on their own took the internet by storm.

Developed by ElevenLabs, which is widely recognized as a leading speech synthesis startup, these two AI Agents engaged in a conversation regarding a hotel reservation. Upon discovering that they are both artificial agents, they transition to a faster audio communication method known as GGWave.

Have you ever wondered how software can quietly talk to other software without any human stepping in to type a password? That invisible but essential process revolves around non-human identities (NHIs)—digital credentials that enable applications, services, APIs, and machines to authenticate and communicate automatically. While these identities power efficiency and scalability, they also introduce unique security challenges that, if ignored, can compromise your entire infrastructure. 

In our previous blog, we explored how non-human identities (NHIs) enable seamless, automated operations across hybrid infrastructures: everything from container-to-container communication to IoT sensor authentication. By highlighting each category of NHI and its placement within on-premises and cloud environments, we laid the groundwork for understanding why they are so pivotal to modern IT ecosystems. 

Now, it’s time to move beyond identifying these NHIs to examining the security risks they face. In this follow-up post, we’ll dive into real-world breaches, explore the unique vulnerabilities tied to each type of non-human identity, and outline best practices for keeping these invisible workhorses safe.

The unique nature of NHI security risks

Non-user-centric exposure
Since NHIs function in the background, there isn’t a user actively logging in and out for every session. This lack of human oversight can make it harder to notice when something goes wrong, such as an attacker quietly gaining access to a system by exploiting a forgotten service credential.

Automation vulnerabilities
Automated processes often depend on static or rarely rotated credentials. When credentials aren’t updated or monitored regularly, they can become a major weak spot. PwC’s 2023 report on cloud security shows that the lifespan of many machine credentials is substantially longer than recommended, giving attackers a wider window to exploit them.

Distributed environments
In a hybrid model, NHIs have to operate across multiple clouds and on-premises data centers. Coordinating consistent security policies and monitoring can be challenging, especially when each environment uses different tools for identity and access management (IAM). This can create hidden pockets of risk that attackers love to exploit. With these broad considerations in mind, let’s dive into the specific threats faced by each NHI type.

Security risks associated with each NHI type

1. Application-to-application (A2A) identities

When two software applications need to talk to each other—say, your billing system calling an external payment service—they often rely on API tokens or OAuth credentials. These A2A identities are central to ensuring seamless automation, but they also pose significant risks if not safeguarded properly.

Risk overview
A key concern is unauthorized access. Hardcoded or improperly stored API tokens can be discovered by attackers, sometimes through publicly exposed repositories or scripts. Another major risk is privilege escalation. If the A2A identity has been granted broad permissions to make system-wide changes, a single compromised token can become an open gateway to your backend.

Specific threats
A classic example is token leakage via source code repositories, where a careless commit ends up exposing sensitive credentials. According to Deloitte, almost 30% of organizations have accidentally posted critical tokens or secrets to public platforms at least once. Inadequate token rotation is another offender. An attacker who gains hold of a long-lived token can use it indefinitely, quietly draining data or modifying settings until it’s too late. Having examined A2A identities in the cloud-native and SaaS contexts, we’ll now pivot to on-premises service accounts.

2. Service accounts in on-premises environments

Inside the walls of traditional data centers, service accounts keep things running smoothly—starting Windows services, operating databases, or automating batch jobs. Despite their crucial role, these accounts are often treated as an afterthought, bundled with excessive permissions or left unmanaged for years.

Risk overview
One of the biggest risks is overprivilege. Service accounts are frequently given broad, “just-in-case” permissions to ensure they don’t break any processes. This practice offers attackers plenty of room to move laterally if they compromise one. Lateral movement is the other nightmare scenario: once a single account is compromised, an attacker might escalate privileges within minutes, potentially reaching sensitive data or critical infrastructure services.

Specific threats
Default or weak passwords for service accounts still exist, especially in legacy systems that haven’t been updated in a decade. EY recently noted that 43% of breaches in legacy environments began with the compromise of a service account. Limited monitoring compounds the problem, since many older platforms don’t even log service account activities. As we shift our focus beyond on-premise to the wider world of public clouds, let’s explore cloud-based API keys and tokens.

3. Cloud-based API keys and tokens

Cloud platforms like AWS, Azure, and Google Cloud rely extensively on tokens and API keys for authentication. These credentials unlock access to everything from object storage to virtual machines and serverless functions. If they get into the wrong hands, the consequences can be devastating.

Risk overview
Credential exposure stands out as the biggest threat. A single posted API key can allow unauthorized individuals to spin up large compute instances (racking up colossal bills) or, worse, extract sensitive data. Additionally, token misuse can come from insiders who inadvertently or maliciously share these keys, or from attackers who discover them in unsecured logs.

Specific threats
Accidental publication of credentials on public platforms like GitHub remains one of the most reported security mishaps. According to GitHub’s own data, hundreds of thousands of leaked API keys and secrets are detected each year, a number that keeps climbing. Inadequate lifecycle management also rears its head when keys are never rotated or are left active even after the associated services have been decommissioned. Let’s now move to container and microservices identities, which are essential in modern DevOps pipelines.

4. Container and microservices identities

Microservices running in containers like Docker or orchestrated by Kubernetes need their own internal credentials to talk to each other. These identities can be short-lived and ephemeral, matching the transient nature of container instances, which might spin up and down dozens of times a day.

Risk overview
Ephemeral credential management can be tricky. Keeping track of every instance in a large Kubernetes cluster quickly becomes challenging. Dynamic environments with fast scaling or frequent rollouts make it difficult to ensure that each container has the correct identity with just the right level of access.

Specific threats
A standout threat is misconfigured container service accounts. A container might unintentionally run with elevated privileges if the default service account isn’t locked down. Another challenge arises when IAM solutions aren’t well integrated with orchestration tools, leaving gaps where credentials aren’t properly rotated or audited. Having addressed container-based workflows, let’s focus on the pipelines that build, test, and deploy them.

5. CI/CD pipeline credentials

Credentials in your CI/CD pipeline grant DevOps tools the ability to fetch repositories, run tests, and deploy new code to various environments. These tokens or service connections are often set and forgotten, even as they possess significant power.

Risk overview
Supply chain attacks are a central concern here. A compromised Jenkins or GitHub Actions token can let attackers inject malicious code that gets pushed to production, potentially reaching thousands or millions of end users. Automation exploitation is similarly problematic, as stolen CI/CD credentials often allow direct access to both development and production resources.

Specific threats
This risk grows when configuration files store credentials in plain text or get checked into version control. Inadequate isolation between development, testing, and production also increases the blast radius of a breach. Gartner cautions that by 2026, 75% of DevOps teams will be directly targeted with supply chain attacks, making CI/CD security more critical than ever. Finally, let’s address an often-overlooked category: IoT and edge devices.

6. IoT and edge device identities

IoT sensors, smart devices, and edge computing nodes operate in remote or hostile environments where physical tampering is more feasible. These devices often lack the computational power or updated firmware necessary for strong encryption and secure identity management.

Risk overview
Physical and remote exploitation stands out because attackers could potentially interfere with the device itself. Meanwhile, weak security controls, like default passwords and outdated encryption, are widespread in the IoT world, often due to limitations in processing power or cost constraints.

Specific threats
Many devices still use default or easily guessable credentials, making them an easy target for botnets or data theft. Insecure communication channels (e.g., unencrypted MQTT or HTTP) expose sensitive data to interception. The 2024 PwC IoT Security Survey notes that 35% of companies reported an IoT-related intrusion in the past year, a sobering statistic that underscores the severity of this risk. Now that we’ve explored the specific threats, let’s look at some cross-cutting challenges and overarching considerations.

Architectural and operational risk factors

Cross-cutting challenges

One universal problem is visibility and monitoring. The sheer diversity of NHIs—ranging from containers in Kubernetes to a sensor in a remote oil field—can overwhelm traditional security information and event management (SIEM) tools. Credential lifecycle management further complicates matters, as short-lived container tokens, static service accounts, and ephemeral CI/CD credentials may each follow different rotation and revocation policies.

Finally, policy inconsistency often arises when different teams or business units apply their own standards for security controls. Cloud teams might adopt robust key vaults and rotation strategies, while on-prem teams rely on static credentials for years. Such mismatched policies create blind spots that attackers can exploit.

Mitigation considerations

A few broad measures can help reduce these risks significantly. Robust logging and anomaly detection—tuned specifically for machine-generated traffic—allows for quicker detection of credential misuse. Strict credential management practices such as enforced rotation, onboarding workflows, and locked-down permissions should become mandatory. Integrated identity governance that spans cloud, on-prem, and edge environments offers end-to-end visibility, bridging the gap between distributed systems.

Non-human identities might operate in the background, but their security implications should be front and center in any enterprise that relies on automation, especially in a hybrid environment. Understanding the myriad ways these credentials can be exploited is the first step toward building an effective defense strategy.

With the right combination of governance, visibility, and technology solutions, you can harness the power of automated systems while keeping your business protected from end to end. In our next post, we’ll move from identifying risks to detailing practical security controls and strategies that can help you proactively avert these threats.

‍