Should organisations start NHI governance in the same way for production, development, and vendor access?

Why This Matters for Security Teams

Organisations that apply one nhi governance model across production, development, and vendor access usually create the wrong kind of control: heavy enough to slow delivery, but weak enough to miss the real risk. Production identities need tight blast-radius reduction, development identities need safe experimentation, and vendor access needs fast offboarding. That is why the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both push teams toward risk-based control selection rather than one-size-fits-all policy.

NHIMG research shows why that matters: only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, and lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations in The State of Non-Human Identity Security. That confidence gap usually reflects poor domain separation, not just weak tooling. In practice, many security teams encounter vendor sprawl, developer exceptions, or production overreach only after an access path has already been abused.

How It Works in Practice

A workable model starts by treating each domain as a distinct operating context. Production NHIs should be issued with the shortest practical TTL, tightly scoped permissions, and explicit revocation triggers. Development should keep secrets easy to use but hard to leak, which means secure storage, environment isolation, and guardrails that developers will actually adopt. Vendor access should be time-bound, heavily monitored, and designed for fast termination when the contract, project, or support window ends.

In practice, the governance stack should separate identity lifecycle controls from access intent:

• Production: prefer ephemeral credentials, workload identity, and policy checks at request time.
• Development: allow broader iteration, but enforce secret scanning, rotation, and non-production isolation.
• Vendor: require explicit sponsorship, periodic revalidation, and immediate disablement on offboarding.

This aligns with NHIMG guidance in the Lifecycle Processes for Managing NHIs and the risk themes in Top 10 NHI Issues. Current guidance suggests that vendors should never inherit standing production trust simply because they need access to a tool chain. The better pattern is to make access conditional on purpose, context, and expiry, with logs that can prove who had access, when, and why. These controls tend to break down in flat environments where development, testing, and production share the same identity namespace because revocation becomes ambiguous and audit evidence loses meaning.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations need to balance control depth against developer velocity and vendor responsiveness. That tradeoff is real, especially in smaller teams where the same service account may touch multiple environments or where vendors support both build pipelines and production operations.

Best practice is evolving, but there is no universal standard for how much isolation is enough. For example, some organisations accept shared development identities if they are non-production, heavily monitored, and excluded from sensitive data paths. Others require separate identities per environment to preserve clean audit boundaries. The key is not symmetry, but proportionality.

The highest-risk edge case is a vendor account that can reach both production and development systems with the same credentials. That pattern creates weak offboarding and broad lateral movement potential, which is exactly the kind of issue highlighted in 52 NHI Breaches Analysis. In these cases, current guidance favors separate identities, short-lived access, and explicit environment-level policy. If one control plane governs all three domains, it should still enforce different approval paths, different TTLs, and different revocation SLAs.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• How can organisations tell whether contextual access decisions are improving governance?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?