Should organisations treat NHI access control separately from user access control?

Why This Matters for Security Teams

Human access and NHI access may sit in the same IAM toolchain, but they do not behave the same way. Human identities are usually governed by employment status, approvals, and periodic reviews. NHIs are tied to applications, automations, pipelines, and secrets that can persist long after the original owner changes. That is why NHI governance needs separate inventory, ownership, and rotation logic, as reflected in NHIMG guidance on the Ultimate Guide to NHIs.

The risk is not theoretical. Entro Security reports that 91% of former employee tokens remain active after offboarding, which shows how quickly machine access can outlive human process assumptions. When teams apply user-centric controls to service accounts, API keys, and workload tokens, they often miss where the real exposure sits: in static secrets, overused identities, and application-to-application trust paths. OWASP’s Non-Human Identity Top 10 treats these as distinct failure modes, not a side issue of user IAM.

In practice, many security teams encounter NHI sprawl only after an offboarding gap, a leaked token, or an unexpected lateral movement event has already occurred, rather than through intentional lifecycle control.

How It Works in Practice

Organisations should separate NHI access control from user access control at the policy and lifecycle layers, while still aligning both to a shared governance model. The practical difference is that user access follows a person, but NHI access follows a workload, automation, or integration. That changes how access is granted, reviewed, and revoked. For users, HR-driven events and manager approvals are common. For NHIs, application ownership, deployment state, secret rotation, and runtime behaviour are the relevant triggers.

A workable model usually includes four pieces:

• Distinct inventories for human identities, service accounts, API keys, certificates, and workload identities.
• Separate approval paths for NHI creation, privilege grants, and exception handling.
• Short-lived credentials or token exchange where possible, instead of long-lived shared secrets.
• Periodic review of application ownership and secret usage, not just human role recertification.

This is especially important because NHI risk is often invisible in conventional access reviews. NHIMG research shows that 62% of secrets are duplicated and stored in multiple locations, which makes user-style recertification incomplete. The better pattern is to manage NHIs as system-managed subjects with explicit context, as described in the 2025 State of NHIs and Secrets in Cybersecurity. For payment environments, PCI DSS v4.0 reinforces the expectation that access to sensitive systems be controlled, reviewed, and limited to what is necessary.

These controls tend to break down when one application owns hundreds of shared secrets across CI/CD, cloud, and SaaS integrations because no single team can reliably attest to who is using which credential at runtime.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance stronger containment against more complex administration. That tradeoff is real, especially in smaller environments where the same team manages both application delivery and identity operations. Current guidance suggests that the goal is not to build two unrelated IAM programs, but to use different control rules for different identity subjects.

Some organisations keep NHI access inside the same platform as user access, but with separate policies, owners, and review cadences. That can work if the platform can distinguish workload identities from people and enforce different lifecycle logic. Best practice is evolving around workload identity, ephemeral credentials, and policy-as-code, but there is no universal standard for every stack yet. The key is to avoid treating a service account like an employee account with a different label.

Two common edge cases matter. First, shared technical accounts used by multiple applications create attribution problems and should be broken apart where possible. Second, legacy systems may not support short-lived tokens or strong workload identity, so compensating controls such as vaulting, tighter rotation, and network scoping become necessary. NHIMG’s Top 10 NHI Issues and breach analysis resources show why these gaps often persist until a compromise forces cleanup. In mature environments, the distinction is clear: user access is governed for people, while NHI access is governed for systems that never stop running.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• What do organisations get wrong about access control compliance?
• How should organisations align IT governance with access control in practice?
• How should organisations connect change management to access control?