How should security teams govern infrastructure access for both people and workloads?

Why This Matters for Security Teams

Governance becomes difficult when the same infrastructure stack must serve human administrators, service accounts, automation jobs, and now autonomous software. The failure point is usually not authentication alone, but inconsistent policy across layers: cloud consoles, Kubernetes, CI/CD, secrets stores, and network controls. Current guidance increasingly points toward one model that treats every actor as an identity with scoped, observable access, rather than a special case. That matters because machine identities now outnumber human ones in many environments, and the operational burden is no longer theoretical.

NHIMG’s Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both frame the same core issue: once identities are not consistently inventoried, authenticated, and audited, teams lose the ability to answer basic questions about access provenance. That is especially risky in infrastructure because privilege is often inherited through tokens, roles, and automation chains that nobody revisits until an incident forces the review. In practice, many security teams encounter over-privileged access only after a configuration error, certificate failure, or automation blast radius has already affected production.

A useful benchmark is the 2026 Infrastructure Identity Survey, which found that 67% of organisations still rely heavily on static credentials despite the risks they pose to autonomous systems. That reinforces why identity governance must cover both people and workloads with the same discipline.

How It Works in Practice

Security teams should build a single access model that starts with discovery, then applies strong authentication, short-lived privilege, and complete audit trails. For people, that usually means federated login, MFA, role mapping, and just-in-time elevation through PAM. For workloads, the same goal is achieved through workload identity, short-lived certificates or tokens, and policy checks at request time rather than static entitlements granted months earlier. The practical difference is not whether access exists, but how narrowly it is issued, how fast it expires, and whether it can be traced to a specific task or operator action.

Implementation is easier when identity is separated from secrets. SPIFFE and SPIRE are useful reference points because they focus on cryptographic workload identity instead of shared credentials, and NHIMG’s Guide to SPIFFE and SPIRE explains why that model scales better for infrastructure than long-lived keys. In parallel, the control plane should log who requested access, what policy allowed it, which workload or person received it, and when the access expired. That makes audit possible without reconstructing intent from disconnected logs.

• Use RBAC for baseline access, then add JIT elevation for sensitive operations.
• Issue ephemeral secrets with explicit TTLs, not reusable static credentials.
• Bind workload access to attested identity, not to hostnames or IP addresses.
• Evaluate policy at runtime so access can reflect context, environment, and risk.

Where teams need a broader operating model, Top 10 NHI Issues is a practical companion because it maps the recurring failure modes that break shared identity governance. These controls tend to break down when legacy systems only support long-lived service accounts because the platform cannot issue, rotate, or revoke ephemeral access cleanly.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance speed against the cost of more frequent issuance, rotation, and review. That tradeoff is real in hybrid estates, mainframes, or vendor-managed platforms where JIT, SPIFFE-style identity, or fine-grained policy enforcement is not fully supported. In those environments, current guidance suggests using compensating controls such as vault-mediated secrets, stronger segmentation, and aggressive monitoring until the platform can support shorter-lived credentials natively.

There is no universal standard for how much autonomy to give automation identities, especially when agents can chain tools, call APIs, and make infrastructure changes without direct human approval. For that reason, intent-based authorisation is emerging rather than settled practice: the decision should be made at runtime based on what the workload is trying to do, not just on its static role. That aligns with NIST’s NIST Cybersecurity Framework 2.0, which emphasises governance, access control, and continuous monitoring across the identity lifecycle.

For teams dealing with mixed human and machine access, the most useful reference point is NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives, because auditability is where shared governance either proves itself or fails. The same is true for workloads under the SPIFFE workload identity specification, where identity proof matters more than inherited credentials. In practice, the hardest edge cases are highly dynamic platforms, where privileged automation and human admin actions converge inside the same control plane and static RBAC no longer describes actual risk.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern access from unmanaged endpoints?
• How should security teams govern non-human identities at scale?