Non-Human Identities and IGA: New Capability or New Label?

NHI is the hottest acronym in identity security right now. Every IGA vendor has a slide deck about it. Every conference has a track dedicated to it. SailPoint launched Machine Identity Security. Saviynt is aligning to the OWASP NHI Top 10. OneIdentity hired a new CEO and pointed him directly at the NHI opportunity.

If you have been doing IGA work for any length of time, you are asking the same question everyone else is asking: what actually changed? We have been governing service accounts for years. The accounts live inside applications we already have connectors for. Is "NHI" just a new label on the same thing, repackaged to justify new licenses?

The answer is partly yes and partly no. The "no" part matters more than the vendors want to admit. It exposes a fundamental architectural limitation in how IGA has always worked.

What Non-Human Identities Actually Are

An NHI is any digital identity that is not a person. The category includes:

• Service accounts in Active Directory, databases, and applications
• API keys and tokens used for system-to-system authentication
• OAuth client credentials and service principals in cloud platforms
• Bot and RPA accounts that execute automated workflows
• CI/CD pipeline identities that deploy code and manage infrastructure
• Certificates and secrets stored in vaults or configuration files
• AI agents that autonomously access systems on behalf of users or processes

The scale is bigger than most people realize. Estimates from Oasis Security and others put the ratio of non-human to human identities at 45:1 or higher in a typical enterprise. With the growth of AI agents and cloud-native architectures, that ratio is accelerating.

If you work in IGA, you already manage some of these. Service accounts and bot accounts have been part of access certifications and lifecycle management for years. The question is whether the new NHI capabilities from vendors are meaningfully different from what you have been doing, or whether they renamed the feature and added a surcharge.

What IGA Vendors Are Actually Shipping

SailPoint launched two distinct add-ons to its Identity Security Cloud:

• Machine Identity Security handles discovery, classification, and governance of service accounts, bots, and RPA identities. It assigns human owners to machine accounts, manages their lifecycle, and includes them in access certifications. This shipped as a paid add-on to Atlas.
• Agent Identity Security extends governance to AI agents from platforms like Microsoft Copilot, Salesforce Agentforce, ServiceNow, Databricks, and others. This is genuinely new territory. SailPoint is treating AI agents as first-class identities that need discovery, ownership, and policy enforcement.

Saviynt has taken a converged platform approach. Rather than shipping NHI as a separate product, Saviynt positions its existing EIC platform as inherently capable of governing any identity type. It sponsored the Non-Human Identity Workshop at Identiverse 2025 and has been aligning to the OWASP Top 10 for NHI security. The pitch: convergence (IGA + PAM + application governance in one platform) makes NHI governance a natural extension rather than a bolt-on. If you already own Saviynt, the argument is that you do not need a separate NHI product.

OneIdentity brought in Smartsheet's former product leader as CEO and pointed him at the NHI opportunity. The company is positioning machine identity governance as a board-level priority, not a technical concern. Their messaging focuses on binding every automated decision to a distinct human owner and creating audit trails for AI-driven actions. The signal: OneIdentity sees NHI as its growth story for the next several years.

What Is Genuinely New vs. Repackaged

Here is the honest breakdown, based on what the products actually do today versus what the marketing suggests.

The repackaged capabilities are not worthless. Most organizations never properly governed their service accounts even when the tools supported it. If the NHI hype gets companies to actually assign owners to their 10,000 orphaned service accounts, that is a real security improvement regardless of whether the underlying capability is new.

But the genuinely new capabilities are where the real challenge lies. And that challenge exposes something the IGA vendors are less eager to discuss.

The Scheduled Collection Problem

Classic IGA works on a collection-and-review cycle. A connector reaches into a target system on a schedule (nightly, weekly), pulls back a list of accounts and entitlements, and stores that snapshot. Managers review the snapshot quarterly or annually. This model works for human identities because humans have relatively stable access patterns. An employee's role does not change every 30 seconds.

Non-human identities break this model in several ways:

Ephemeral credentials live and die between collection cycles. A CI/CD pipeline might generate a short-lived token that authenticates to a cloud service, performs a deployment, and expires in 15 minutes. If your IGA platform collects data nightly, that token never appears in any snapshot. It is invisible to governance.

The volume overwhelms scheduled reviews. If you have 45 machine identities for every human, and you are already struggling to get managers to complete their quarterly human access reviews, adding a 45x multiplier to the certification queue is not realistic. Rubber-stamping was already the default behavior. This makes it worse.

There is no natural lifecycle owner. Human identities have a joiner/mover/leaver lifecycle tied to HR events. When someone leaves the company, their accounts get disabled. Machine identities have no equivalent trigger. The application that created them might get decommissioned, but nobody sends an HR termination event for a service principal.

Credentials rotate on their own schedule. API keys and certificates expire, rotate, or get replaced through automated processes that have nothing to do with IGA workflows. The IGA platform might show a service account as "active" while the actual credential it uses has been rotated three times since the last collection.

This is not a feature gap. It is an architectural gap. The entire IGA model assumes periodic snapshots of relatively stable identity data. NHIs, especially the cloud-native and ephemeral varieties, operate on a fundamentally different timescale.

So Is It Just a New Classification of Accounts?

Your instinct is partially right. Many NHIs live inside applications that IGA already connects to. An Active Directory service account is still an AD account. A service principal in Azure is still an Entra ID object. The IGA connector can see them. You can include them in certifications. You can assign owners.

But the governance model that works for those accounts breaks down for three reasons:

1. No self-service. Human governance assumes the identity holder can participate. They can request access, approve reviews, acknowledge policies. A service account cannot attend an access review meeting.

2. No manager chain. Human governance relies on a management hierarchy for approvals and certifications. Machine identities report to... an application team? A platform team? The developer who created them three years ago and has since left the company?

3. No lifecycle events. The IGA engine triggers on HR events. There is no equivalent event source for "this microservice was deprecated" or "this API integration was replaced by a different vendor."

For traditional service accounts in well-managed environments, treating NHI as a new classification within existing IGA works fine. The tools support it. The gaps are operational, not technical.

For cloud-native NHIs, ephemeral credentials, and AI agents, classification is not enough. You need a different architectural pattern: real-time identity graphs instead of periodic snapshots, policy-as-code instead of manual certifications, and integration with runtime systems that authorize and revoke access based on actual behavior rather than quarterly reviews.

This is where purpose-built NHIM vendors like Oasis Security and Astrix Security have a genuine advantage. They built for the real-time, cloud-native model from the start. The parallel to a decade ago is obvious: cloud-native IGA platforms had the same structural advantage over legacy on-premises IGA tools. The incumbents eventually caught up, but the gap was real.

Where This Leaves You as a Practitioner

If you work in IGA today, here is what this means for your career:

Your existing skills transfer directly for traditional NHIs. Service account governance, ownership assignment, lifecycle management, access certifications. All of this applies. The tools you know already handle it. The challenge is operational discipline, not new technology.

The new skills are in cloud-native identity and secrets management. If you want to work on the genuinely new NHI problems, learn cloud IAM (AWS IAM, Azure Entra workload identities, GCP service accounts), secrets management platforms (HashiCorp Vault, cloud-native secret stores), and policy-as-code frameworks (Open Policy Agent, Cedar). These are not traditional IGA skills. They are where the market is heading.

AI agent governance is early but moving fast. SailPoint's Agent Identity Security, the Oasis Agentic Access Management product, and similar offerings are just the beginning. Organizations are deploying AI agents faster than they are building governance around them. If you get ahead of this, you will be in demand.

Watch for the licensing play. Some vendors are packaging existing service account governance as "NHI" and charging new license fees. If a vendor's NHI solution only does what their platform already did for service accounts with a new dashboard skin, be skeptical about the additional cost. Ask specifically: what discovery, real-time enforcement, or secrets integration capabilities are included that were not available before? If the answer is "a new dashboard and some reports," you are paying for a label.

The NHI trend is real. The security gap is real. The 45:1 ratio is real. But not everything being sold as "NHI governance" is new. The practitioners who understand the difference between repackaged service account management and genuinely new machine identity governance will make better technology decisions and better career decisions.

That distinction starts with understanding what your current IGA platform can actually do today, without any new licenses, and what genuinely requires a different architectural approach.