Why non-human identities (NHIs) require a change in mindset

Until the past couple of years, identity and access management (IAM) programs were built around employees, admins, joiners, movers, leavers, multi-factor authentication (MFA), and access reviews.

But today, the modern enterprise runs on identities that are not human at all.

These non-human identifies (NHIs) include service accounts, API keys, OAuth apps, certificates, automation accounts, CI/CD identities, bots, integrations, and increasingly AI agents.

NHIs have become prolific: Gartner reports that NHIs now outnumber human identities by slightly more than 80:1 in many enterprises, and the Cloud Security Alliance says at least 20% of organizations have already experienced NHI-related cybersecurity incidents.

Philip Shteyn, chief technology officer at Offroad, explained that the growing attacks underscore that many organizations today do not understand NHIs well enough to secure them.

Shteyn said organizations often do not know who owns an NHI, why it exists, what business processes depend on it, what permissions it has, whether those permissions are still needed, how it’s actually being used, and most important: what would break if it were restricted, rotated, or removed.

“Security teams need to move from managing identities as static records to managing identities as active participants in the business,” said Shteyn. “An NHI is not just a secret in a vault or a row in an IAM table. It’s often a working identity that can read customer data, change production systems, export reports, trigger workflows, access source code, or act across multiple applications.”

Roy Katmor, co-founder and CEO at Orchid Security, said to effectively manage the challenge from NHIs, security teams need a blend of identity, application, security, and operational expertise. Katmor said it’s not purely an IAM problem — and not an AppSec problem.

In practice, Katmor said the best teams are cross-functional: the knowledge often exists inside the company, but it’s siloed.

IAM and identity governance and administration (IGA) teams offer insight into access governance, lifecycle, certification, and policy, said Katmor, while AppSec and product security teams must recognize how applications authenticate and authorize users. 

Katmor added that security operations should interpret identity behavior from the logs and tools. In addition, platform and cloud teams need to stay savvy about service accounts, workload identities, secrets, CI/CD, and infrastructure access. And even application owners need to understand the business context and operational impact of their code.

“Forward-thinkers view the missing layer as essential connective tissue: a way to observe identity from the application perspective, correlate it to systems of record, and operationalize the findings across owners, workflows, and controls,” said Katmor.

Teams need to get real

The ratios that are bandied about in the industry around NHIs come from a world where machines weren't autonomous actors, said Ganesh Mallaya, distinguished architect and technical evangelist for AppViewX.

Mallaya said today we’ve got AI agents that spawn their own credentials, make decisions about what access they need, and operate in workflows that no human reviewed. The ratio isn't just growing: the category itself is collapsing.

“Security teams actually need to accept that they are no longer defending a perimeter they can map by hand,” said Mallaya. “The quarterly identity review governance model was built for a world where identity creation was a controlled event. When identities are being created faster than we can schedule meetings to discuss them, the old playbook just stops working.”

Mallaya said the teams he sees on top of this trend have stopped trying to govern every identity on a schedule and started treating identity as something to observe continuously. Instead of "review all service accounts quarterly," it’s: "surface the anomalies immediately."

So for example, Mallaya in this new world a certificate can show up on a host it's never touched. An API key that's been dormant for months is suddenly active at 2 a.m. And, a service principal somehow just escalated its own permissions.

“The signals exist,” said Mallaya. “But most teams just aren't instrumented to catch them. Today, the harder shift is cultural. Security teams have to let go of the idea that they control identity creation because they don't, and they can't. Developers are creating identities. Cloud platforms are creating identities. Now AI agents are creating identities. Security teams are not the gatekeeper anymore.”

Mallaya said today, the security team’s job is to make sure every identity, no matter who or what created it, is visible, policy-bound, and revocable when the company needs it that way.

“That's a completely different operating model than ‘nothing gets created without our approval,’” said Mallaya. “And most security organizations weren't built for that reality.”

Adam Ochayon, vice president of product strategy at Oasis Security, said to more effectively manage this NHI challenge, teams have to start by recognizing where all these NHIs actually come from because it’s different from a human identity.

Ochayon said humans mostly centralize everything: organizations funnel through one identity provider (IdP), maybe a couple at most.

In contrast, NHIs are scattered by definition: every SaaS platform has its own identity provider, with its own API keys, tokens, and service accounts, and none of it federates back to a center. Apps ship with credentials baked in. There's no single place to look.

Ochayon said teams should start with their systems of record, the obvious ones first — IdPs, clouds, major SaaS platforms — and work outward from there. Then enumerate within them. But enumeration is just the entry point: the real work is in understanding each account: what created it, where it's used, what it can reach, and whether it actually lines up with your policies.

Kevin Surace, chair at TokenCore, said teams can get this moving by deploying policy-based automation with clear exception paths.

Teams should automate creation, ownership assignment, permission review, rotation, expiration, and deprovisioning.

However, Surace said they should not automate trust blindly. The policy engine needs to understand context. He said a healthy lifecycle model looks like this:

“This is where biometric FIDO2 fits naturally,” said Surace. “The approval step does not have to be cumbersome. A biometric device can assure identity when the agent or automation is about to do something consequential. The point is not to put a human in every loop. The point is to put a verified human-in-the-loop only when the action has real business consequence.”

Moving forward, Marshall Heilman, chief executive officer at DTEX, said security teams must stop treating NHIs as infrastructure and start treating them as potential threat actors. Heilman said NHIs require the same level of monitoring, governance, and lifecycle management as human identities, but any action must be taken at machine speed and not after-the-fact.

“This shift involves a new SOC operating model capable of inferring intent, analyzing behavior, and comparing actions against peer baselines to contain threats before human intervention is possible,” said Heilman. “Organizations will have to answer basic, but overdue questions: Why was this AI agent created? What is it allowed to do? What data can it access? Who owns the outcome? Who is responsible when something goes wrong?”

Orchid Secuity’s Katmor offers a 7-step checklist for teams to more effectively manage NHIs:

Katmor said managing NHIs is no longer about finding a list a machine accounts, it's about understanding non-human actors in context: what they do, why they exist, what they can impact, and how the team should govern them.

“In the agentic AI era, that visibility becomes foundational,” said Katmor. “Teams that cannot see and govern NHIs will struggle to safely scale AI, compliance, and security operations across the enterprise.”