Your NHI Inventory Is Wrong. Here's How to Fix It

Most NHI inventory problems are not operational failures; they're architecture failures. The environment is already fragmented before anyone misses a record or forgets an update.

The problem starts with tool sprawl, distributed ownership, stale configuration management, and the reality that automation gets stood up far faster than governance processes can capture it.

Tool Sprawl Creates Identity Blindspots

No single platform sees all NHIs. Active Directory teams see Windows service accounts and computer objects. Cloud teams see IAM roles and managed identities. DevOps teams see CI/CD runners and workload credentials.

Security owns secrets tooling. IAM owns governance.

Every platform tells the truth about its own domain and hides everything outside it. That is how organizations end up with multiple “authoritative” inventories that disagree with each other.

Ownership is Distributed but Accountability is Not

Human identities usually have HR-backed ownership models. NHIs do not. Service accounts survive reorganizations. Cloud roles outlive the projects they were created for.

Tokens remain active long after the engineer who created them has left. Pipeline identities get labeled “platform owned,” which usually means nobody really owns them. When ownership is ambiguous, inventory quality collapses.

CMDBs Lag Reality

CMDBs are built for assets that change slowly. NHIs are not slow-moving assets. Cloud-native environments can create identities in minutes.

Pipelines generate ephemeral principals. Integrations appear during projects and never get retired. Temporary roles become permanent. By the time an identity reaches the CMDB, if it ever does, it may already be obsolete.

Shadow Automation is Everywhere

Some of the most privileged identities in the enterprise were never formally onboarded. They were created quickly to solve a problem: a sync script, a deployment credential, a vendor integration token, an emergency automation account.

Those shortcuts become production dependencies. Years later, no one remembers they exist, but they still work.

Run Discovery in Parallel, Not in Silos

If you want a real NHI inventory, stop auditing systems in isolation. Run a coordinated discovery exercise across Active Directory, cloud providers, your governance platform, and your secrets infrastructure simultaneously.

Each source reveals what another source misses. The delta between them is where the real exposure sits.

Start with Active Directory

Most enterprises still underestimate how many NHIs live in Active Directory. Even organizations that think of themselves as cloud-first still have decades of Windows-integrated workloads, scheduled tasks, IIS pools, middleware, file transfer processes, and line-of-business applications tied to AD-backed identities.

Pull user objects used as service accounts, gMSAs and sMSAs, computer objects acting as trust anchors or service identities, disabled accounts still referenced operationally, high-privilege accounts with SPNs, and accounts with non-expiring passwords.

Then cross-reference against Windows services, scheduled tasks, IIS application pools, SQL service logons, SPN assignments, Kerberos activity, last password set, and last logon data.

The directory object by itself does not tell you the truth. Runtime usage does. This is where you find accounts marked “unused” that still run payroll, provisioning, file transfer, or production middleware.

Interrogate the Cloud Control Planes Directly

Cloud NHIs proliferate faster than governance processes can track. In AWS, commonly missed identities include IAM roles never attached to EC2 but assumable by workloads, old access keys on service users, Lambda execution roles with broad privilege, OIDC federation roles for CI/CD systems, and cross-account trust roles nobody remembers creating.

In Azure, the misses tend to be system-assigned managed identities, reused user-assigned managed identities, service principals created for automation, enterprise applications with stale credentials, and runbook identities. In GCP, service accounts attached to workloads, forgotten locally created keys, default service accounts with broad rights, and cross-project impersonation paths are frequent blind spots.

Don't rely on summaries. Pull the actual control-plane objects and activity signals: IAM roles and trust policies, role assignments, app registrations, service principals, service accounts, keys, credential expirations, impersonation paths, AssumeRole activity, sign-in telemetry, and audit logs.

The common pattern across AWS, Azure, and GCP is simple: identities exist in the control plane long before they appear in governance tooling.

Use SailPoint or Saviynt as a Coverage Lens, Not the Full Truth

SailPoint and Saviynt are valuable sources of NHI data, but they only show what has been onboarded, modeled, correlated, and maintained. That isn't the same as what exists.

These platforms are useful for finding managed technical accounts, certification status, owner metadata, uncorrelated accounts, and privileged accounts already connected to integrated systems.

They're much less reliable as a complete source for cloud-native roles, managed identities, ephemeral pipeline identities, secrets-backed principals, and local application credentials that were never onboarded.

Export non-person accounts by type, accounts without owners, privileged technical accounts, uncorrelated accounts, accounts tied to disabled or deprecated applications, and stale certification data. Then compare those exports to the identities you collected from AD, cloud providers, and secrets systems.

If your cloud team can enumerate two thousand workload identities and your governance platform knows about only three hundred, the problem is not reporting. The problem is coverage.

Mine Your Secrets Vaults for Identities Nobody Registered

Secrets systems often surface NHIs that exist nowhere else. This is one of the most productive parts of the exercise because secrets vaults reveal the credential layer rather than the governance layer.

HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault frequently contain database usernames, API tokens, service principal secrets, SSH keys, legacy integration credentials, and automation accounts that are absent from both the CMDB and the governance platform.

Look at secret paths, mounts, leases, auth methods, rotation configuration, expiration data, access policies, consuming applications, and last-accessed metadata where available. Then ask the question most teams avoid: what identity does this credential represent, and who owns it?

A surprising number of organizations can rotate secrets on a schedule but cannot answer that question reliably. That's not maturity. That's a control gap hiding behind an operational process.

What You Will Find That was Never in the CMDB

Every serious NHI discovery exercise surfaces categories of surprise that were invisible to formal inventory processes. You will find forgotten automation scripts still running under privileged credentials. You will find CI/CD identities, build runners, deployment bots, artifact pull accounts, repo tokens, and OIDC federation paths.

You will find legacy integration tokens connected to HR, ERP, finance, and vendors that no current team fully understands. You will find orphaned cloud roles with broad permissions but no ticket, no owner, and no documented business purpose.

You will also find shared service accounts used by multiple applications because “that is how it has always worked,” zombie secrets rotating faithfully for systems nobody uses anymore, and human accounts quietly repurposed as machine identities years ago. None of these are edge cases. They are standard operating conditions in large enterprises.

Build an Ownership Model that Holds Over Time

Discovery without ownership just creates a better spreadsheet. Every NHI needs accountable human ownership, even if multiple teams interact with it.

The cleanest model is to assign both a business owner and a technical owner. The business owner is accountable for why the identity should exist at all.

The technical owner is accountable for validating permissions, rotating credentials, responding to issues, and decommissioning the identity when it is no longer needed. This distinction matters.

Shared service accounts cannot just belong to “Infrastructure.” Assign the platform team as the technical owner and the consuming service owner or application owner as the accountable stakeholder.

Pipeline and automation identities should be tied to the platform service and its owning team, not to the individual engineer who first created the credential. That is how you avoid ownership evaporating when people move on.

For new NHIs, require ownership metadata at creation time: owner, business purpose, environment, privilege classification, credential type, and next review date. No metadata, no identity.

Then enforce quarterly hygiene checks to confirm the owner still exists, still sits in the right team, still understands the identity, and still agrees the access is justified. Ownership is not a field. It is a lifecycle process.

The Goal is Not the List; It's Control

A perfect inventory is not the objective. The objective is to know what exists, who owns it, what it can access, how it authenticates, whether it is still needed, and whether the risk around it is improving or getting worse.

Inventory is only the foundation. Without it, every control layered above it is weaker than the organization thinks it is.

Don't Wait for a Cleaner Moment

There will never be a clean quarter to do this. There will always be a migration, a platform refresh, a budget cycle, a staffing gap, or another initiative competing for attention.

Meanwhile, the NHI population keeps growing in the background. Start the discovery exercise now.

Pull the AD technical identities. Export cloud workload identities and roles. Pull your SailPoint or Saviynt non-person accounts.

Enumerate secrets tied to machine access. Reconcile duplicates and unknowns. Assign owners to the highest-risk identities first.

That first pass will expose more real risk than another quarter of policy discussions. Your NHI inventory is wrong today. The only question is whether you fix it before an attacker maps it for you.

Need a team who can advise on and implement these solutions for you? Reach out to our team today.