How is a non-human identity different from a service account?

A service account is one type of non-human identity. NHI is the broader category that also includes API keys, OAuth tokens, machine identities, ephemeral workload credentials, and AI agent credentials. Treating service accounts as the only NHI category is a common gap, because the controls that work for service accounts do not always cover newer credential patterns.

Why are non-human identities a security risk?

NHIs use valid credentials to make valid-looking requests, which makes compromised NHIs hard to detect. They are often long-lived, broadly scoped, and exposed in code repositories or chat tools. When a threat actor obtains an NHI credential, they can move laterally through systems without triggering controls built for human-account compromise.

How many non-human identities does a typical organization have?

NHIs often outnumber human identities in modern organizations. Most security teams underestimate the count until they run a discovery pass across code repositories, chat tools, cloud platforms, and SaaS applications.

What is non-human identity lifecycle management?

NHI lifecycle management is the standardized practice of creating, controlling, rotating, monitoring, and decommissioning non-human identities. It typically separates creation (often owned by engineering) from governance (centralized under security), and it includes rotation cycles, scope reviews, and continuous monitoring for exposed credentials.

How do you discover non-human identities you do not know about?

Discovery starts with continuous scanning of code repositories, chat tools, shared drives, and configuration files for exposed secrets. It also includes pulling credential inventories from cloud providers, SaaS platforms, and identity systems. Most organizations find more exposed credentials than expected on the first pass.

What is the difference between non-human identity governance and privileged access management?

Privileged access management (PAM) focuses on human accounts with elevated permissions, such as administrators. NHI governance focuses on non-human credentials, which have different lifecycles, different failure modes, and different detection challenges. Mature programs treat them as related but distinct disciplines.

AI Security

Non-human identities are already a CISO problem

Chris Anderson

October 08, 2026 7 minute read

A non-human identity is any digital identity that authenticates without direct human interaction. Service accounts, API keys, OAuth tokens, machine identities, and AI agent credentials all fall under this category. They authenticate to systems, request data, and trigger actions, and they outnumber human identities in most modern organizations by a wide margin.

Scale is the problem here. Most identity programs were built around the assumption that a human is on the other end of every login. Non-human identities (NHIs) break that assumption, and the controls that work for human accounts do not translate cleanly. The CISOs who are ahead on this are not waiting for a vendor to solve it. They are treating NHI hygiene as a distinct discipline, with its own controls, its own lifecycle, and its own failure modes.

I recently had the opportunity to sit down with three top CISOs featured in Cisco Duo's new CISO Perspectives 2026 survey report. Last week, I covered our conversations on lifecycle management and the JML problem. Today let’s unpack the security leaders’ perspectives on what working NHI governance looks like in their organizations, and what they are doing about it.

Why NHIs are different from human identities

Human identity programs are built around moments of friction. A user logs in, multi-factor authentication (MFA) verifies them, and adaptive policies decide whether the request looks normal. Behavior analytics flag anomalies. Help desks reset credentials when something goes wrong.

NHIs do not generate those moments. A service account does not get phished, but its key gets committed to a public repository. An API token does not fail an MFA challenge, but it gets reused for months past its intended lifespan.

"API keys and access tokens are the new passwords. There's a reason threat actors are focusing on them, because they're everywhere."
— Mandy Andress, Chief Information Security Officer, Elastic

Mandy made that point early in our conversation, and it stuck with me. Detection is harder for NHIs, too. When an attacker uses a stolen API key, they are using a valid credential to make valid-looking requests. Detections do not alert. The activity blends into normal traffic. That is a structural problem, not a tooling gap, and it is why NHI hygiene has to start somewhere other than detection.

The visibility problem

Most organizations have far more NHIs than they think they do. Mandy described how Elastic identified NHIs as the company's top risk four years ago. If a threat actor got into an employee's account, the secrets and API keys scattered across Slack channels, Google Drive, and GitHub would let them move laterally through the environment without tripping any alarm.

Frank Aiello, Chief Information Security Officer at Maximus, described a similar pattern from the other direction. Penetration testers compromising service accounts during routine engagements is what drove his team toward more standardized management. The accounts were not malicious or hidden. They were simply unmanaged, and that was enough.

I have heard this story from a lot of CISOs. Visibility is the first step. Organizations are consistently surprised by how many secrets and non-human identities they find throughout their environment that they did not realize were there. You cannot rotate, govern, or decommission what you cannot see.

Hygiene practices that work

Across the conversations I had, the CISOs converged on a set of practices that hold up at scale. None of these practices required new categories of tooling; they required commitment.

Centralize the control structure, even when creation stays distributed. Engineering teams will continue to create NHIs as part of building software. That is fine. What changes is who owns the controls. At Elastic, Mandy described a model where engineering owns creation but central security owns rotation, monitoring, and lifecycle governance. This separation is what makes governance feasible at scale.

Establish standard rotation cycles. Long-lived credentials are the most dangerous. Mandy described a multi-year program at Elastic to remove keys that had been active but unused, rotate keys that had not been rotated in too long, and put every new key on a defined rotation cadence.

Move toward ephemeral credentials. The clearest North Star Mandy described is that no human ever knows the secret. Short sessions, ephemeral keys, automated issuance and revocation. Even if a credential is leaked, it is only useful for a very short period. Most organizations cannot get there overnight, but every new NHI created with ephemeral credentials is one fewer long-lived secret to manage later.

Continuously scan for exposed secrets. Slack, Google Drive, GitHub, internal wikis, and code repositories all collect credentials over time. Continuous scanning is not optional. It is part of the operating model.

Standardize lifecycle management. Frank's team at Maximus standardized how NHIs are created, locked down, restricted in scope, and decommissioned. This came partly from penetration test results and partly from the operational reality he described to me: decommission an application, delete the service account, and another application dies because it was sharing the same identity. Standardized management is what prevents that.

Types of NHIs and the controls that fit them

NHIs are not one thing, meaning the controls that work for one type may not work for another. A useful starting point is to map the categories you have, the lifecycle weakness each one introduces, and the control that fits.

NHI type	Lifecycle weakness	Recommended control
Service accounts	Shared across applications and rarely rotated	Standardized creation, rotation cycles, clear ownership
API keys	Static tokens leaked in code or chat tools	Continuous secret scanning and automated rotation
OAuth tokens	Over-scoped permissions and long expirations	Regular scope review and shorter token lifetimes
Machine identities	Manual issuance creates inconsistent renewal	Automated certificate issuance and renewal
Ephemeral runtime credentials	Misconfigured trust boundaries between workloads	Workload identity federation across cloud platforms
AI agent credentials	Inherited and over-broad delegated permissions	Scoped credentials, short sessions, agent-specific controls

However, the point of the table is not to be exhaustive. An NHI program needs to account for several credential patterns, and the controls have to match each pattern.

What to do first

If you are reframing NHI governance in your organization, the practices my guests and I discussed offer a path to develop a comprehensive program:

Inventory your NHIs. Start with visibility. Scan code repositories, chat tools, and shared drives for exposed secrets. Pull credential inventories from your major cloud and SaaS platforms. Expect the number to be larger than you think.
Prioritize by blast radius. Not every NHI is equal. Focus first on the credentials that have the broadest access, the longest lifetimes, or the highest-value data exposure.
Centralize the control structure. Let engineering keep creation. Move rotation, monitoring, and lifecycle governance to a central team.
Move new NHIs to ephemeral credentials immediately. Stop adding to the long-lived credential pile. Every new key created with a short lifetime is one less long-lived secret to remediate later.
Continuously scan for exposed secrets. Make it part of the operating model, not a quarterly project.

This is not a one-quarter program. Mandy's team at Elastic has been working on it for four years and is still working toward the North Star. The work is incremental, and the wins compound.

Hear the full conversations

What I shared here only scratches the surface of what Mandy, Frank, and the other CISOs had to say. We also covered the joiner-mover-leaver lifecycle, agentic AI risk, the future of passwords, and the fundamentals that still hold up in 2026. To watch the full conversations on demand, visit CISO Perspectives and download the 2026 survey of 28 security leaders.

For the platform side of this work, Cisco Identity Intelligence is where the practitioner conversation for NHI visibility continues.

About the author Chris Anderson is Product CTO at Cisco Duo, where he helps drive Cisco's work in identity and access management (IAM) and identity security. He works at the frontier of where identity is going next: passwordless and phishing-resistant authentication, identity governance, and the new wave of non-human and agent identities that are reshaping how organizations think about access.

Chris hosts the CISO Perspectives series, sitting down with global security leaders to talk through identity sprawl, agentic AI, zero trust, and the practices that hold up at scale. He believes the next wave of identity is not just about who gets access. It is about what gets access, on whose behalf, and under what constraints.

Hear the full CISO Perspectives conversations at duo.com/ciso. Connect with Chris on LinkedIn.