How can organisations tell whether non-human access is actually governed?

Why This Matters for Security Teams

Governance is not proven by the existence of a service account, secret vault, or access review spreadsheet. It is proven when every non-human action can be traced to a distinct workload identity, policy decision, and revocation path. That matters because Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which means most teams are operating with partial evidence at best. Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 points toward continuous control, not periodic assumption.

The common failure is mistaking secret storage for governance. A vault can reduce exposure, but it does not answer who or what used the credential, whether the permission was justified, or whether the access could have been revoked selectively. In practice, many security teams encounter uncontrolled non-human access only after an incident has already demonstrated that “managed” is not the same as “governed.”

How It Works in Practice

To tell whether non-human access is actually governed, look for three things at request time: unique workload identity, policy enforcement that evaluates context, and logs that preserve attribution end to end. For mature environments, that usually means a workload authenticates with a cryptographic identity such as SPIFFE or OIDC, receives only the permissions needed for a specific task, and is denied by default unless policy says otherwise. This is the practical difference between static entitlement management and real governance.

That approach aligns with the direction set by Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives, where lifecycle control and auditability are treated as operational requirements, not optional hygiene. In implementation terms, teams should check for:

• Distinct identities per workload, not shared service accounts across applications or environments.
• Policy-as-code or equivalent request-level decisions that consider actor, task, time, and destination.
• Short-lived secrets or tokens with selective revocation, rather than long-lived credentials that stay valid until manually changed.
• Logs that link each call, token use, or tool invocation to a specific actor and approval path.

If a workload can authenticate but not be individually revoked, if its permissions are inherited from a broad role, or if its actions cannot be attributed without manual reconstruction, governance is incomplete. These controls tend to break down when shared secrets are embedded in CI/CD pipelines because the same credential is reused across systems and the resulting activity becomes operationally invisible.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance stronger assurance against deployment friction and application complexity. That tradeoff is real, especially in legacy estates where shared service identities, static API keys, and coarse RBAC are already deeply embedded. Best practice is evolving here, and there is no universal standard for every stack, but the direction is clear: governance should be demonstrable, not inferred.

Edge cases often appear in machine-to-machine integrations, batch jobs, and third-party automation. These environments may still use a limited number of shared identities temporarily, but that should be treated as an exception with compensating controls, not as a default design. The relevant question is whether the organisation can still answer who accessed what, under which policy, for how long, and with what revocation path. If not, the access model is only administratively managed.

NHIMG research shows why that distinction matters: the 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce that visibility, rotation, and offboarding are where governance succeeds or fails. In short, if the organisation cannot selectively revoke a single workload without disrupting unrelated systems, it is still relying on convenience over control.

Related resources from NHI Mgmt Group

• How can organisations tell whether MCP access is actually being governed?
• How can organisations tell whether governed data access is actually working?
• How can organisations measure whether agent orchestration is actually governed?
• How can teams tell whether access controls are actually working for frontline users?