Notifications
Clear all
Topic starter
06/06/2026 1:57 am
TL;DR: Static NHI inventories are useful but incomplete: Oasis Security argues that discovery must include ownership, permissions, activity, location, and purpose so teams can manage risk across on-prem, cloud, SaaS, and automation workflows. A list of service principals is not governance; context is what turns discovery into control.
NHIMG editorial — based on content published by Oasis Security: NHI Discovery, Going Beyond Inventory
Questions worth separating out
Q: How should security teams go beyond NHI inventory lists?
A: They should enrich discovery with ownership, permissions, activity, deployment context, and business purpose.
Q: Why do static NHI inventories fail in practice?
A: Static inventories fail because they capture presence without meaning.
Q: What breaks when NHI discovery does not include business context?
A: Governance breaks first, because recertification and ownership checks have nothing to validate against.
Practitioner guidance
- Normalize discovery across identity systems Pull NHI records from cloud directories, SaaS applications, PAM, IGA, and infrastructure sources into one governed view so teams can compare identities using the same fields and naming logic.
- Attach an accountable owner to every NHI Require a named person or service owner for each service account, token, or certificate, and use that ownership record to drive review, rotation, and decommission decisions.
- Record business purpose and runtime context Capture why the identity exists, where it runs, and which workflows depend on it so security changes can be evaluated against operational impact before they are made.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- The Microsoft Entra ID service principal discovery example and script flow used to illustrate basic inventory collection
- The five identity context dimensions in full, including ownership, permissions, temporal use, deployment location, and purpose
- The step-by-step enrichment model for normalising NHI discovery across cloud, SaaS, IGA, PAM, and infrastructure systems
- The operational guidance on using discovery outputs to support rotation, decommissioning, and policy enforcement
👉 Read Oasis Security's blog on NHI discovery beyond inventory →
NHI discovery: what teams miss when they stop at inventory?
Explore further
06/06/2026 3:21 am
Static inventory is a visibility control, not an identity governance control. A list of NHIs can confirm that accounts exist, but it cannot prove accountability, necessity, or safe privilege boundaries. That makes inventory useful for enumeration and almost useless for governance unless it is enriched with ownership, usage, and purpose. Practitioners should treat basic discovery as a starting signal, not the control surface itself.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 91% of former employee tokens remain active after offboarding, showing how lifecycle failure persists even after the identity relationship should have ended.
A question worth separating out:
Q: How do organisations safely act on NHI discovery findings?
A: They should route every enriched identity into lifecycle decisions, then validate dependencies before changing access. That means tying discovery to review, rotation, and offboarding workflows, and checking service impact before decommissioning or tightening privileges. The objective is to reduce exposure without breaking critical systems.
👉 Read our full editorial: NHI discovery needs context beyond static inventory lists
