The Critical Role of CISOs in Managing IAM - Including Non-Human Identities

Who should own IAM in the enterprise?

Identity and access management (IAM) started as an IT function, with the entire focus on giving human users the right access to the right systems. But today, identity has become the primary attack surface, with at least 80% of all modern breaches involving compromised or stolen identities from adversaries who exploit poor identity. This reality has moved the responsibility for risk onto the shoulders of the team tasked with protecting the organization from attacks, namely security. Which ultimately means the CISO. 

However, there’s a major blind spot in this conversation: non-human identities (NHIs). This is a critical oversight. We are witnessing non-human identities (NHIs) outnumber humans by a factor of at least 45-to-one in the enterprise, with some estimates as high as 100 to 1. As organizations accelerate to deliver more code and products faster than ever, the number of these machine identities, such as service accounts, APIs, and automated workloads, will continually increase this imbalance. LLMs and the rapid adoption of new coding assistants and AI productivity tools will only rapidly accelerate this trend.

If CISOs don’t come to terms with IAM strategies to cover NHIs, they’re leaving one of their largest attack surfaces undefended.

IAM Without NHI Governance is Incomplete

The traditional IAM model has long revolved around human identities: onboarding employees, granting them role-based access, monitoring for policy violations, and de-provisioning accounts when necessary. This human-centric approach has matured significantly, with robust governance frameworks, compliance mandates, and security controls like multi-factor authentication (MFA) and zero trust principles. The tooling market has kept pace with innovations from vendors like Okta, OneLogin, and Auth0.

But NHIs operate under very different assumptions:

• They don’t have passwords but rely on API keys, tokens, and cryptographic credentials to authenticate.
• They don’t follow traditional lifecycle processes—service accounts and machine identities often persist indefinitely, even after their original purpose is obsolete.
• They lack clear ownership, meaning their security is often neglected.

NHIs are also highly susceptible to abuse. Secrets sprawl, the uncontrolled proliferation of credentials, has become a major security risk. API keys and access tokens are frequently hardcoded into source code, embedded in configuration files, or exposed in logs.

Long-lived credentials, lacking any real governance or automation for rotation policies, are a prime target for attackers. By default, many older systems never expired, meaning some API keys in cloud environments haven’t been rotated in years.

On top of this, NHIs are commonly over-permissioned. Developers are often in a rush to get something working and may not be scoping secrets as tightly as needed per the principle of least privilege. The lack of clear governance frameworks adds to their confusion, leading to many machine identities being granted excessive permissions just to "get it working" rather than being secure. 

The result? A massive security gap that adversaries love to exploit.

If IAM strategy is truly about protecting access, it must include NHIs. Otherwise, enterprises are only solving half the problem.

Why CISOs Must Own NHI Governance

Given that IAM should now be a security function, it follows that NHIs—being the fastest-growing and most vulnerable category of identities—must be governed under the CISO’s purview. Here’s why.

NHIs are a Major Attack Vector

NHIs represent one of the largest and least monitored attack surfaces in the modern enterprise. Attackers increasingly target leaked API keys, compromised service accounts, and misconfigured machine identities to gain unauthorized access.

Just a few examples of high-profile breaches have demonstrated this risk:

• The U.S. Department of the Treasury was breached through a compromised API key, granting the attackers access to workstations and unclassified documents.
• Toyota publicly exposed a very long-lived access key to an internal data server, allowing unauthorized access to real customer data for 5 years. 
• The New York Times exposed a GitHub token, resulting in 5,600 of their repositories being leaked online. 

Compliance and Risk Management Demand It

Regulatory frameworks like PCI-DSS, GDPR, and ISO 27001, as well as recommendations from NIST, all include strict access control and least privilege requirements—but they often focus on human identities.

As regulators catch up to the reality that NHIs pose the same (or greater) risks, organizations will be held accountable for securing all identities. This means enforcing least privilege for NHIs—just as with human users. It also means tracking the full lifecycle of machine identities, from creation to decommissioning, as well as auditing and monitoring API keys, tokens, and service accounts with the same rigor as employee credentials.

Waiting for regulatory pressure after a breach is too late. CISOs must act proactively to get ahead of the curve on these coming changes.

Zero Trust Requires NHI Governance

Zero trust strategies focus on identity as the new perimeter, but if NHIs aren’t included, the majority of the identity perimeter remains wide open.

A zero trust approach to NHIs means:

• Continuous verification – NHIs must be continuously authenticated and authorized, not granted persistent access.
• Least privilege enforcement – NHIs should have minimal permissions and be regularly reviewed.
• Segmentation and isolation – NHIs should be restricted to the specific workloads they serve.

Zero trust is not complete unless NHIs are governed as rigorously as human identities.

Building a Comprehensive IAM Strategy

A modern IAM strategy must begin with comprehensive discovery and mapping of all identities across the enterprise. This includes understanding not just where the associated secrets are stored but also their origins, permissions, and relationships with other systems. Organizations need to implement robust secrets management platforms that can serve as a single source of truth, ensuring all credentials are encrypted and monitored.

The lifecycle management of NHIs requires particular attention. Unlike human identities, which follow predictable patterns of employment and human lifestyles, machine identities require automated processes for creation, rotation, and decommissioning. Security teams must implement systems that can track when secrets were created, who created them, and, most importantly, when they should be rotated or retired.

How to Extend IAM to Include NHIs

Extending IAM to NHIs requires an adapted governance framework that accounts for their unique challenges. Here are the recommended next steps to align your machine identity governance with your security posture goals

Discover All NHIs

Without knowing identities already exist in your organization, it is impossible to secure them. Hopefully, this has been well documented as they came into existence, but most likely, this is not going to be the case, especially across multiple applications, teams, and entire divisions of your enterprise.

Fortunately, the world of NHI mapping is rapidly evolving, and GitGuardian is here to support you. Our secrets detection platform has always been able to find the associated NHI secrets in code, Jira, Slack, and other platforms around the SLDC. With the announcement of GitGuardian's NHI Security we can now also help you map all the secrets that exist inside your vaults, no matter how many vault instances have been deployed across the organization. 

Any mapping you do needs to account for, at a minimum, where NHI secrets are stored, when they were created, and by whom. You should also be able to see when they were created, rotates, and very importantly, if they are still in use. 

Centralize NHI Management

In our research with CyberArk, we uncovered that, on average, organizations maintain an average of 6 distinct secrets manager instances. This vault sprawl means a lack of visibility throughout the enterprise, even if an individual department, DevOps, or application team has this view into their team's secrets. What is needed is a way to make sure any secret is stored and managed from the single most appropriate place. 

Vault sprawl also means a likelihood of duplication of keys throughout systems. This adds complexity to the rotation process, especially in the middle of an incident. The security teams need to have a path to make sure when a secret is rotated, it is globally enforced. 

Once you do have a clear view across vaults, which GitGuardian can help you achieve, you can enforce that any secrets found outside the vault are placed in the correct enterprise secrets manager, like HashiCorp Vault, AWS Secrets Manager, CyberArk Conjur, and then properly rotated automatically, at scale.

Enforce Least Privilege & Rotation Policies

Getting all the possible combinations of permissions assigned correctly to grant an application just enough privilege to get the work done is time-consuming and tricky. It is highly likely that at least some of your NHIs have more access than they need, including the ability to write or delete objects or other data. Without understanding what permissions your NHIs have, it is impossible to audit them to remove excessive permissions.

This should not be a one-off exercise, as every credential rotation introduces the chance that new unneeded privileges will be introduced. What is needed is continual scanning to re-check that any changes to NHIs have adhered to the principle of least privilege. Once all NHI privileges are understood, organizations can implement better-automated rotation and NHI governance policy at scale, ensuring the new secret follows the governance model you have established. 

Integrate NHIs into Zero Trust

No NHI should be allowed to act without the right authentication. NHIs currently rely, for the most part, on long-lived credentials. By default, most API keys, passwords, and other authentication tokens live forever. In an ideal world, you would be able to deliver just-in-time authentication that lives just for the life of the workload request or robust identity frameworks like SPIFFE/SPIRE. 

Most organizations are barred from implementing these approaches for existing applications and infrastructure due to the lack of insight into their existing NHI inventory and the technical hurdle of reworking the code to adopt a new methodology. But by moving your NHI secrets into a centralized enterprise secrets management, you can move towards this goal much faster. While this is just a part of a zero trust strategy, as defined by NIST, it is impossible to achieve without the ability to ensure that any credentials are only being used by the expected entity. Mapping those NHIs is a mandatory step. 

A Unified IAM Strategy for Humans and Machines

IAM is no longer just about human users. It must evolve to govern non-human identities with the same level of security, oversight, and control. This goes beyond the scope of any single part of your IT or DevOps organization, especially as security is ultimately on the hook for the risks when a breach occurs. 

For CISOs, owning IAM means owning all identities, both human and non-human. Anything less leaves a massive security gap. By integrating NHIs into IAM strategy, enterprises can:

• Reduce the attack surface from secrets sprawl
• Enforce least privilege across human and machine identities
• Improve compliance posture before regulations catch up
• Build a zero trust architecture that accounts for all identities

The modern enterprise cannot afford fragmented identity governance. It’s time for CISOs to take full ownership—before attackers do. GitGuardian is here to help, no matter where you are on your journey to secure your machine identities, no matter who owns IAM in your enterprise.

We would love to talk to you about how we can help. Let's secure all your identities, together.