Securing non-human identities: Part 1: Understanding the types of NHIs and placement

API keys and service accounts: what’s the difference?

At first glance, it might be hard to see any real disparity between these two types of credentials. Both are used behind the scenes to allow apps or services to talk to each other, both operate without human input, and both can unlock significant pieces of your organization’s digital environment. 

However, API keys are generally used to grant access to external or internal APIs – think about letting a payment gateway interact with your e-commerce site – while service accounts typically act as system-level IDs inside your own networks, such as Windows service accounts or managed service identities in the cloud. Both are crucial for automation, but each serves a slightly different purpose and poses unique risks. 

Understanding these nuances becomes even more important when you realize how many different kinds of digital IDs exist for software and machines in a modern enterprise. That brings us to the broader concept of non-human identities (NHIs).

Securing non-human identities (NHIs) in hybrid environments: Understanding their types and placement

Organizations today rely heavily on hybrid infrastructures – part on-premises, part cloud, and sometimes multiple clouds all at once. In these complex environments, it’s not just people who need login details; it’s also programs, scripts, containerized applications, and even IoT devices at the edge. According to Gartner’s 2023 Market Guide for Machine Identity Management, the number of machine identities (which include all sorts of non-human credentials) has surged by nearly 45% over the past two years. That’s great for automation because it keeps your services humming along without manual interventions, but it also means more potential “invisible” entry points for attackers to exploit. Now that you have the bigger picture, let’s walk through the most common NHIs, where they reside, and why they matter.

What are non-human identities (NHIs)?

Non-human identities are digital credentials that represent software entities rather than actual individuals. This can include application-to-application (A2A) credentials, service accounts, API keys, container identities, CI/CD pipeline tokens, and even IoT device IDs. These credentials are the glue that holds automated systems together in microservices, DevOps, cloud-native apps, and IoT ecosystems. They exist to ensure secure, uninterrupted machine-to-machine communications so that your key processes can run 24/7 without waiting on a person to type in a password.

Deloitte’s 2023 Global Security Report notes that mismanagement of these machine credentials is quickly becoming one of the top causes of unauthorized access in hybrid cloud infrastructures. The problem often starts with organizations not realizing how many of these identities they have, or where in the environment those credentials are stored. This lack of visibility can lead to serious vulnerabilities. Now that we’ve defined what NHIs are and why they’re so important, let’s take a closer look at the many shapes they can take.

‍

1. Application-to-Application (A2A) identities

A2A identities are the credentials that let different pieces of software talk to each other without human intervention. They often revolve around secure tokens or OAuth credentials, which help confirm that one service is allowed to access another. These credentials are extremely common in microservices architectures, where multiple smaller services need to coordinate behind the scenes. They’re also used in cloud integrations, such as AWS Lambda calling external APIs, and in any third-party connectors that link your applications with external platforms, including payment gateways or marketing automation tools.

A key pitfall is the possibility of hardcoded credentials. A developer might, for example, embed an API key directly into the source code and then mistakenly commit that code to a public repository. PwC’s 2023 report revealed that 60% of organizations experienced at least one incident where leaked or misconfigured A2A credentials were exploited by attackers. With that in mind, remember that safeguarding these tokens and rotating them frequently can prevent serious breaches. Having covered how A2A identities keep various software components talking to each other, let’s now explore how service accounts function in more traditional environments.

‍

2. Service accounts in on-premises environments

Service accounts typically live in internal infrastructures and are vital for automated tasks performed by legacy applications, databases, or background processes. They often tie in with systems like Active Directory (AD) or LDAP, serving as a kind of behind-the-scenes user ID that can start services, run scheduled jobs, or interact with enterprise software like HR, ERP, or CRM platforms. These accounts are essential for business continuity since they handle routine processes you probably don’t want to do by hand.

However, organizations frequently grant service accounts broad permissions or let multiple people and teams share them for convenience. This means that if a service account is compromised, attackers could move laterally throughout the network. According to Deloitte’s 2024 Global Cyber Executive Briefing, overprivileged service accounts account for nearly 40% of lateral movement in on-prem breaches. As we leave the realm of purely on-prem accounts, it’s only natural to examine the rise of API keys and tokens used in the cloud.

‍

3. Cloud-based API keys and tokens

API keys, OAuth tokens, and other short-lived credentials are the workhorses that unlock cloud services – be it SaaS platforms, IaaS environments, or cloud-native applications. You’ll encounter them in AWS IAM roles, Azure AD applications, or Google Cloud service accounts, as well as in serverless architectures like AWS Lambda or Azure Functions. They authenticate your requests to various cloud resources, ensuring that only authorized processes can spin up a new virtual machine or access sensitive data in storage buckets.

The danger is that a single cloud-based API key can open the door to crucial assets if it’s misplaced or stolen. Gartner predicts that by 2025, 75% of cloud security failures will stem from poorly managed machine identities and keys. That staggering figure underlines why you should treat these credentials with extreme caution and implement strong management practices like automatic rotation and central secret vaulting. Next, let’s pivot from clouds to the granular world of containerized applications and microservices.

‍

4. Container and microservices identities

Containers are lightweight, standalone software units that run reliably across different computing environments. In microservices-based architectures, each container or service may need its own identity to authenticate itself, often through orchestrators like Kubernetes or Docker. These identities can be short-lived, which means they might only exist for as long as the container is running – sometimes mere minutes.

The fleeting nature of containers makes managing their credentials both essential and tricky. PwC’s Cloud Security Outlook 2023 notes that misconfigured container environments can lead to elevated risks of lateral movement, primarily because ephemeral identities aren’t always monitored as carefully as static ones. A robust approach to securing these ever-changing identities includes limiting permissions, applying Role-Based Access Control (RBAC) in Kubernetes, and regularly rotating tokens. As we leave the container world, let’s turn our attention to the credentials that power your continuous integration and continuous delivery pipelines.

‍

5. CI/CD pipeline credentials

CI/CD credentials are found in the DevOps tools that automate your software development lifecycle. They might show up in Jenkins, GitHub Actions, GitLab CI/CD, or Azure DevOps as stored secrets or tokens that let these platforms fetch code repositories, run tests, and deploy software to production environments. They can also appear in Infrastructure as Code tools like Terraform or Ansible, which use credentials to provision and configure servers, databases, or entire cloud environments.

One of the greatest risks tied to CI/CD credentials is the potential for supply chain attacks. If an attacker gains access to these credentials, they could sneak malicious code into your release pipeline, compromising your software before it even reaches your end users. EY’s 2023 DevSecOps Report found that 70% of new code releases include at least one external dependency, which magnifies the potential fallout if hackers hijack the pipeline. With the software layer covered, let’s finish our tour by looking at the physical edge – the world of IoT and industrial devices.

‍

6. IoT and edge device identities

IoT and edge devices need their own machine identities to authenticate and securely communicate with core systems, often from remote or resource-constrained locations. Think industrial sensors on a manufacturing line or small devices in a smart city environment. These devices typically process data in real-time and then relay that information back to central control systems or cloud analytics platforms. Without secure identities, the data pipelines could be hijacked or manipulated.

Because IoT devices are frequently deployed in large numbers and may not receive frequent updates, they can be a security blind spot. A 2024 PwC IoT Security Survey revealed that 35% of organizations reported at least one attack targeting IoT devices in the past year, many involving compromised device credentials. This shows the importance of strong identity management and firmware security for all devices, no matter how small or remote they are. Now that we’ve mapped out the range of NHIs, it’s time to tie it all together by discussing broader architectural considerations.

‍

Architectural considerations for NHI placement

In a hybrid environment, where on-premises systems merge with multiple clouds, it’s crucial to ensure that all of your NHIs are granted only the permissions they absolutely need. This “least privilege” approach is a foundational security principle. Using role-based access control (RBAC) further refines these permissions into roles that closely match an application’s or a device’s intended function rather than assigning a one-size-fits-all admin status.

Credentials also shouldn’t live forever – short-lived tokens and frequent rotations reduce the window of opportunity for attackers. Finally, a centralized identity governance system or a dedicated secrets management tool like CyberArk or HashiCorp Vault can help you track and uniformly apply policies to every machine identity in your network. Now let’s bring these concepts to life with a few real-world examples of what happens when NHIs aren’t properly secured.

‍

Case examples and real-world implementations

One company in the financial services sector experienced a full-blown cloud breach after developers accidentally committed AWS API keys to a public GitHub repository. Attackers found these keys almost immediately and used them to access sensitive customer data stored in S3. While code scanning tools like GitGuardian or GitHub Advanced Security could have flagged these exposed credentials, they weren’t in place at the time.

In a separate incident, a healthcare provider discovered that its Kubernetes environment was misconfigured so that multiple microservices were sharing the same service account with overly broad permissions. When one microservice was compromised, attackers were able to pivot within the environment and gain access to patient data. Deloitte advises implementing strict role-based access control (RBAC) in Kubernetes and regularly rotating service account credentials to avoid such scenarios. These cautionary tales reinforce the high stakes of proper NHI management.

‍

Building a secure foundation for NHIs

NHIs may not be human, but they certainly need the same level of attention, if not more, when it comes to identity security. They are woven into nearly every aspect of modern digital infrastructures, from cloud to on-premises to edge devices, and their proliferation shows no signs of slowing down. With automated processes set to grow even further, now is the time to implement strong governance, least privilege, and continuous monitoring across all non-human credentials.

In our next installment, we’ll dive deeper into the specific security risks associated with each type of NHI and share practical strategies for mitigation. At Unosecur, we specialize in securing every corner of your identity landscape, whether human or machine, in both hybrid and multi-cloud settings. Don’t wait until an attacker finds that one overlooked key. Stay ahead of threats by building a robust, future-proof approach to NHI security, starting today.

‍