Should teams prioritise discovery or policy first for NHI governance?

They should start both in parallel, but discovery usually comes first when shadow AI is already present. Policy without visibility cannot govern what the team has not found. Discovery without policy only inventories the problem, so the programme needs both to identify identities and then constrain them.

Why This Matters for Security Teams

Discovery and policy are often treated like sequential work streams, but NHI governance fails when teams wait for perfect inventory before setting constraints. The real risk is hidden credentials, unmanaged service accounts, and SaaS connections that already have access. Current research shows 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means policy cannot meaningfully govern a population the team cannot yet see. That is why guidance in the State of Non-Human Identity Security and the Top 10 NHI Issues both point to visibility as the prerequisite for control design, not a replacement for it.

Policy-first programmes usually look neat on paper, but they tend to define rules around identities that have not been discovered, classified, or assigned an owner. Discovery-first programmes can also stall if they stop at inventory and never define what “approved” means. Security leaders should therefore run both tracks together, with discovery feeding scope and policy defining the enforcement model. That parallel approach is consistent with NIST Cybersecurity Framework 2.0, which expects organisations to understand assets and then apply governance and protection controls. In practice, many security teams encounter shadow access only after an incident review, rather than through intentional governance.

How It Works in Practice

For most teams, the right order is not “discovery then policy” or “policy then discovery” as separate projects. It is discovery-led policy design with continuous feedback. First, identify where NHIs exist: cloud workloads, CI/CD pipelines, SaaS OAuth grants, APIs, bots, and machine credentials. Then classify them by owner, function, privilege level, and whether they use static secrets, rotated secrets, or short-lived credentials. That gives policy something real to govern.

From there, define policy around the controls that can actually be enforced: approval paths, lifecycle processes for managing NHIs, secret rotation cadence, entitlement review, and revocation triggers. NHI governance is stronger when policies are written to answer practical questions such as who can create an identity, who can use it, how long it may live, and what telemetry proves it is still legitimate. Where teams need a deeper map of identity types and failure modes, Ultimate Guide to NHIs remains the best starting point.

• Use discovery to build the authoritative inventory, then tag each NHI by system, owner, and privilege.
• Use policy to define minimum standards for JIT access, secret rotation, and approval workflows.
• Use enforcement to block new high-risk identities until they are classified and assigned.
• Feed findings back into policy so exceptions become documented decisions, not permanent gaps.

One useful benchmark is that 1 in 4 organisations are already investing in dedicated NHI security capabilities, with another 60% planning to do so within 12 months, which shows the market is moving from ad hoc visibility toward formal governance. These controls tend to break down when cloud and SaaS teams can create identities faster than central security can inventory them, because ownership becomes fragmented and enforcement loses context.

Common Variations and Edge Cases

Tighter policy often increases operational overhead, so organisations have to balance speed against control maturity. That tradeoff is especially visible in engineering-heavy environments where teams deploy ephemeral workloads, rotate secrets frequently, or use managed integrations that change every release. In those cases, current guidance suggests policy should be expressed as guardrails rather than rigid approvals for every identity event.

There is no universal standard for this yet, but a practical pattern is to reserve hard policy for the highest-risk cases: privileged service accounts, externally exposed OAuth apps, production secrets, and identities with write access to critical systems. Lower-risk NHIs can move through lighter-touch reviews if discovery and logging remain strong. For audit and governance framing, the Regulatory and Audit Perspectives section shows why evidence matters as much as policy text. Teams that want an incident-driven perspective should also review the Cisco DevHub NHI breach and the broader 52 NHI Breaches Analysis, both of which show how hidden access and weak governance compound each other.

Where the model shifts again is in highly automated environments with agents or orchestrators. In those settings, discovery must include behavioural context, not just static inventory, because the identity may be legitimate while the action is not. That is where policy moves toward runtime decision-making, and where discovery and policy become a closed loop rather than separate phases.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams use IAST and RASP in NHI governance?
• Should organisations prioritise external exposure or internal credential governance first?
• What makes agentic AI an NHI governance issue?