Security comes down to trust. In DevOps and in our applications, it really is a question of "should this entity be allowed to do that action?" In an earlier time in IT, we could assume that if something was inside a trusted perimeter, be it in our private network or on a specific machine, then we could assume entities were trustworthy and naturally should be able to access resources and data. However, as applications became more complex, spanning not just machines but also different data centers and continents, and reliance on third-party services via APIs became the norm, we could no longer rely on trusted perimeters. 

We replaced the trusted perimeter with a model based on "never trust, always verify" and "the principle of least privilege." We have come to call that model of security "zero trust," and the type of infrastructure we create using this principle "zero trust architecture." 

Much of the focus in zero trust discussions centers on human identities, which do need to be considered, but the challenges around securing non-human identities (NHI), should be addressed. The full scope of the NHI trust issue becomes very concerning when you consider the sheer volume involved. According to research from CyberArk, in 2022 the number of NHIs outnumbered human identities at an enterprise by a factor of 45 to 1. Some estimates put this as high as 100 to 1 in 2024 and are predicted to keep increasing well into the future. Implementing security for all our identities and leaning into zero trust has never been more important.

Fortunately, you are not alone in this fight to make your applications more secure and adopt a zero trust posture. One governing body that has put out a lot of guidance on this issue is the National Institute of Standards and Technology (NIST). In this article, we will take a closer look at achieving zero trust architecture for hour NHIs based on NIST's advice.

Defining zero trust architecture and NHIs

Starting with an agreed-upon definition is always a good idea when contemplating any new approach or term. NIST Special Publication 800-207 gives us a formal definition of zero trust:

"Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan."

Non-human identities are machine-based credentials that allow API integrations and automated workflows, which require machine-to-machine communication. These include API keys, service accounts, certificates, tokens, and roles, which collectively enable the scalability and efficiency required in modern cloud-native and hybrid environments. However, their mismanagement introduces significant security risks, making them an important component of any robust zero trust strategy.  

What can go wrong?

Poorly managed NHIs pose significant security challenges. Secrets sprawl, leaking hardcoded API keys and tokens, often exposes sensitive credentials in codebases or logs, creating an easy target for attackers. Given the staggering number of hardcoded credentials added to public repos on GitHub alone, over 12.7 million in 2023, the majority of which were for machine identities, the full scope of this problem starts to come into focus.  

Adding to the issue is over-permissioned NHIs, which utilize only a fraction of their granted access, greatly expand the attack surface and heighten the risk of privilege escalation. When an attacker does find a leaked secret, they are often able to use it to laterally move throughout your systems and escalate privileges. 

Inadequate lifecycle management leaves stale credentials like unused service accounts and outdated certificates vulnerable. This is how the problem of "zombie leaks," when a secret is exposed but not revoked, happens in so many codebases, project management systems, and communication platforms. For example, a commit author may believe that deleting the commit or repository is sufficient, overlooking the crucial revocation step and, therefore not completing the needed end-of-life step for managing an NHI.

What NIST has to say about securing NHIs 

NIST publishes many documents with guidance on properly securing credentials, but most of their publications focus on human identities, such as user accounts. They use the term non-person entities (NPE) in some of their work, but across the current enterprise landscape, these are much more commonly called NHI. We will stick with that current naming convention for this article. 

Non-human identities security consists of multiple strategies. The following points should be seen as a partial list of recommendations.

Eliminate long-lived credentials 

NIST SP 800-207: Zero Trust Architecture covers ZTA policies and emphasizes the equal treatment of NHIs and human users when it comes to authentication, authorization, and access control. One of the significant recommendations is the elimination of all long-lived credentials. By automatically expiring after a short duration, short-lived credentials reduce the risk of unauthorized access and force regular re-authentication. This ensures that any stolen or exposed credential has limited utility for attackers.

Keep an eye out for anomalous activity

SP 800-207 also calls for continuous monitoring of NHI Activities. Teams should strive to collect and analyze logs to detect unusual or unauthorized behavior around API calls, service account usage, or token operations. According to NIST, ZTA is especially critical in highly automated environments, such as DevOps pipelines and cloud-native architectures, where machine-to-machine interactions outnumber human actions by an increasing factor. 

Don't trust for very long 

NIST SP 800-207A: "A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments" gives even more pointed advice. When discussing service authentication, it says, "Each service should present a short-lived cryptographically verifiable identity credential to other services that are authenticated per connection and reauthenticated regularly."Mature teams can also consider routes for replacing credentials with automatically rotated certificates.

Teams already embracing service meshes can easily adopt systems like SPIFFE/SPIRE. For teams that have not already looked at PKI for machine identities, there are a lot of benefits in investigating this route.

Least Privilege for NHI 

SP 800-207A  also encourages embracing the "principle of least privilege." This ensures that NHIs operate with only the permissions necessary for their specific tasks. By minimizing access scope, organizations can significantly reduce the attack surface, limiting potential damage if an account is compromised. This requires regular audits of permissions to identify unused or excessive privileges and a continuous effort to enforce access restrictions in alignment with actual operational needs. Least privilege is particularly critical for service accounts, which often have elevated permissions by default, creating unnecessary risks in automated environments.

Centralized Secrets Management

Referred to in both NIST publications is a clear call for managing secrets in a centralized secrets management platform. Enterprise secret management tools such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault offer secure storage, rotation, and access control for sensitive credentials. These platforms ensure secrets are encrypted, accessed only by authorized entities, and logged for auditing purposes. By centralizing secrets management, organizations reduce the risks of secrets sprawl and mismanagement while enabling streamlined rotation policies that maintain system integrity.

GitGuardian can help you meet NIST recommendations

Just as NIST is there to provide high-level guidance for securing NHIs, GitGuardian is here to help ensure compliance and strengthen your security posture. By addressing critical aspects such as credential management, secrets detection, and lifecycle monitoring, GitGuardian helps organizations effectively implement NIST-recommended practices.

Detecting and managing secrets sprawl

NIST emphasizes the dangers of hardcoded secrets; this is the key vulnerability the GitGuardian Secrets Detection Platform is designed to combat. GitGuardian scans repositories, including private and public GitHub repos, for exposed API keys, tokens, certificates, and other sensitive credentials. This aligns with NIST SP 800-207’s recommendation to eliminate long-lived credentials and enforce strict policies for credential management. With real-time alerts for leaked secrets, GitGuardian ensures quick remediation, minimizing the risk of unauthorized access.

Ensuring centralized secrets management 

While GitGuardian is not a secrets management tool itself, it integrates seamlessly with leading platforms such as HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault. This enables organizations to centralize their secrets storage and management, fulfilling another critical NIST requirement. GitGuardian’s integration can ensure that secrets found during scans are securely managed and rotated through approved workflows, reducing the risks of secrets sprawl and stale credentials.

Enhancing DevOps security

NIST highlights the importance of securing highly automated environments, particularly DevOps pipelines, where NHIs dominate interactions. GitGuardian brings security into the development lifecycle by embedding secret detection directly into CI/CD pipelines. This not only protects NHIs in real-time but also enforces security best practices among developers, aligning with NIST’s principle of continuous improvement.

Securing NHIs together

NIST has provided invaluable guidance for organizations striving to adopt a zero trust architecture and secure NHIs. Their meticulous research and recommendations, such as eliminating long-lived credentials, enforcing least privilege, and advocating for centralized secrets management, have set a strong foundation for tackling the growing complexities of securing NHIs in modern infrastructures.

At GitGuardian, we deeply appreciate NIST's contributions to advancing cybersecurity. We are committed to helping you operationalize these principles and rise to the challenges posed by evolving threats. Whether it's detecting hardcoded secrets, monitoring credential usage, or integrating with secrets management platforms, GitGuardian is here to ensure your systems remain secure and compliant. 

Together, we can strengthen your defenses and secure your future.