NHI discovery: a methodology that finds what you do not know about

The two numbers

Before any tooling decision, establish a baseline you can measure against. Take your existing known set, however partial, and run discovery against it.

• Recall against known. What percentage of identities you already knew about did the method find? Below about 95% the method has a systematic blind spot worth diagnosing before proceeding.
• Net new. How many did it find that were not in your list? This is the number that justifies the programme and it is the one to take to a budget conversation. It is also the honest test of any vendor POC: coverage of the known set is table stakes, and net new is the product.

Record both with a date and the method used, because you will be asked how the population was produced, by an auditor under SOC 2, and by anyone challenging the programme's scope.

Eleven sources, in priority order

Ordered by yield per hour of effort. The first four typically account for most of the estate.

1. Cloud IAM. Users with access keys, roles and their trust policies, and, critically, key age. Key age alone identifies the worst tail in minutes and is the single cheapest finding available.
2. The authorization server. Registered OAuth clients, especially ones created for a proof of concept that outlived it. Also the best source for unregistered agents.
3. CI/CD. Repository and organisation secrets, deploy keys, self-hosted runner credentials. Include archived repositories: the credential is still valid.
4. SaaS admin consoles. Third-party OAuth grants, created by business users through consent screens and almost never in a security inventory. This is the Salesloft/Drift surface.
5. Directory services. Service accounts, including the ones whose naming convention predates your current one.
6. Kubernetes. Service accounts, bound roles, and any long-lived token secrets predating projected tokens.
7. Secrets stores. Split what is stored statically from what is issued dynamically. The static half is the problem.
8. Certificate inventory. Public and private PKI, with algorithm and key size recorded. See post-quantum migration.
9. Source code and configuration. Hardcoded credentials, including full commit history rather than current HEAD.
10. API gateway consumers. Callers that map to no known application.
11. Network egress and billing. Outbound connections to model and SaaS endpoints, and the invoices for them. Finance frequently knows about integrations security does not.

What has no API

Roughly 10 to 20% of a typical estate sits behind something you cannot query: network appliances, embedded and OT devices, vendor-managed software, legacy middleware, hardware security modules. These will not appear in automated discovery and are disproportionately likely to hold long-lived credentials.

Four techniques that work:

• Work backwards from the target. You may not be able to enumerate an appliance's credentials, but you can enumerate what authenticates to the systems it talks to.
• Network observation. Authenticated sessions from sources with no matching inventory entry.
• Contract and procurement review. Vendor agreements frequently describe the access granted, even where no technical record exists.
• Structured interviews, last. Useful only once you have the automated picture, so you are asking about specific gaps rather than asking people to remember.

Record these as a known-incomplete segment with a named owner rather than leaving them out. An inventory that states its own coverage boundary is far more credible than one that implies completeness it does not have.

Deduplication and identity resolution

Raw enumeration produces duplicates: one identity appears as a cloud role, a Kubernetes service account, and an OAuth client. Counting these separately inflates the number and fragments ownership, so the same credential gets three different owners and none of them acts.

Resolve on three signals, in order: credential material (the same key or client ID appearing in two places is the same identity), the resource it authenticates to, and the workload consuming it from deployment metadata. Where resolution is uncertain, keep both records linked rather than merging, a wrong merge is harder to detect and unwind than a duplicate.

Keeping it true

An inventory decays from the day it is produced. Three practices keep it honest:

• Re-run discovery on a schedule and report the delta, not the total. "Fourteen thousand identities" tells a governance forum nothing. "Two hundred new, sixty retired, forty found outside the registry" is decision-grade.
• Reconcile in both directions. Identities discovered that are not registered, and registered identities that have not authenticated in ninety days. Both are findings.
• Instrument creation, not just discovery. The long-term answer is that new identities enter the inventory at creation because the issuance path requires it. Discovery then becomes a check on the paved road rather than the primary mechanism. See the platform engineering guide.

Frequently asked questions

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

Enumerate by issuer rather than by surveying teams, because the credentials people forget are the risky ones. In priority order: cloud IAM including key age, the authorization server's registered OAuth clients, CI/CD secrets including archived repositories, SaaS admin console third-party grants, directory service accounts, Kubernetes service accounts and token secrets, secrets stores split static versus dynamic, certificate inventory, source code and commit history, API gateway consumers, and network egress plus billing records.

What are the two numbers that matter in NHI discovery?

Recall against your known set, meaning what percentage of identities you already knew about the method found, and net new, meaning how many it found that were not on your list. Below about 95% recall the method has a systematic blind spot worth diagnosing. Net new is the number that justifies the programme and is the honest test of a vendor proof of concept, since coverage of the known set is table stakes.

How much larger is the real NHI count than the tracked count?

Typically two to five times, though the multiple varies with how mature the existing inventory is. Plan licensing and the remediation backlog for the real number rather than the estimate, because per-identity commercial models scale with what discovery finds and the true-up arrives after switching costs are real.

How do you find non-human identities in systems with no API?

Four techniques. Work backwards from the target by enumerating what authenticates to the systems the appliance talks to. Observe the network for authenticated sessions from sources with no inventory entry. Review vendor contracts and procurement records, which often describe granted access where no technical record exists. And run structured interviews last, once you have the automated picture, so you are asking about specific gaps rather than asking people to remember.

Why is billing a useful discovery source?

Because every paid integration and model API leaves a financial trail, and it is the only enumeration source that is complete by construction for anything with a cost. Procurement or finance can usually produce it in an afternoon, and it routinely surfaces integrations that appear in no technical inventory because they were purchased by a business team rather than provisioned by engineering.

How often should NHI discovery be re-run?

At least quarterly, monthly where identities can reach production data, and report the delta rather than the total. Reconcile in both directions: identities discovered that are not registered, and registered identities that have not authenticated in ninety days. The long-term goal is that new identities enter the inventory at creation because the issuance path requires it, which turns discovery into a check on the paved road rather than the primary mechanism.