When should organisations treat on-prem access as a zero-trust problem?

Why This Matters for Security Teams

On-prem access becomes a zero-trust problem as soon as an environment still depends on persistent service account secrets, shared admin groups, or sessions that outlive the task they were meant to support. At that point, trust is no longer anchored in network location or legacy segmentation. It has to be earned continuously, with every request, every token, and every privilege grant. That is exactly the discipline described in NIST SP 800-207 Zero Trust Architecture.

The practical problem is that many on-prem estates still assume internal equals safe. That assumption breaks when service accounts are over-permissioned, secrets are copied into scripts, or operators reuse standing admin access for convenience. In NHI terms, the issue is not just identity sprawl but control drift. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a direct indicator that broad trust boundaries are still being used where zero trust should apply.

Security teams often get this wrong by focusing on perimeter tooling while leaving the real trust model unchanged. In practice, many security teams encounter credential abuse only after a “trusted” internal account has already been used to move laterally or access systems no one expected it to reach.

How It Works in Practice

Treating on-prem access as zero trust means replacing implicit trust with explicit, runtime decisions. The access request must be evaluated in context: who or what is requesting access, what resource is being requested, whether the request is consistent with the declared task, and whether the credential should exist at all. That aligns with the OWASP Non-Human Identity Top 10, which frames weak lifecycle control and excessive privilege as primary risk drivers.

For on-prem workloads, the control pattern usually includes three moves: first, issue short-lived credentials instead of static ones; second, bind those credentials to a workload identity rather than a human-shared account; third, enforce revocation and re-authentication when task scope changes. In mature environments, this often means combining PAM with JIT access, certificate-based workload identity, and policy-as-code enforcement at the point of use. The Ultimate Guide to NHIs — Standards and Guide to SPIFFE and SPIRE are useful references for understanding how cryptographic workload identity and secret rotation support that model.

• Replace long-lived shared secrets with JIT, task-bound credentials.
• Use workload identity to prove what the service is, not who last touched it.
• Evaluate access at request time, not only at login time.
• Revoke access automatically when a session, job, or pipeline step ends.

Where this becomes especially important is in hybrid environments where on-prem systems still feed CI/CD, automation, or remote admin tooling. The 90% of IT leaders who say properly managing NHIs is essential for successful zero trust are pointing to that exact operational dependency, and the research in 52 NHI Breaches Analysis shows how quickly those dependencies turn into breach paths when secrets and privilege are left standing. These controls tend to break down when legacy applications cannot issue short-lived tokens or enforce session-level revocation because the application itself was never built for runtime authorization.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, so organisations have to balance reduction in standing privilege against the effort of modernising legacy applications. That tradeoff is real, especially when mainframes, OT-connected systems, or vendor-managed appliances cannot natively support ephemeral credentials.

Current guidance suggests treating those systems as exceptions that need compensating controls, not as reasons to abandon zero trust. In practice, that can mean wrapping legacy access in PAM, limiting the blast radius through segmented jump hosts, and monitoring for behaviour that deviates from the approved task. Best practice is evolving here, but there is no universal standard for every legacy pattern yet. The general direction from Ultimate Guide to NHIs — Key Challenges and Risks and NIST SP 800-207 Zero Trust Architecture is clear: if a system cannot prove identity continuously, it should not be granted broad internal trust.

Another edge case is when organisations mistake network microsegmentation for zero trust. Segmentation helps contain impact, but it does not solve over-permissioned identities, stale secrets, or unclear session ownership. That is why on-prem access should be treated as a zero-trust problem whenever the control plane cannot answer a simple question: is this access still valid right now, for this workload, for this purpose?

Related resources from NHI Mgmt Group

• What is the difference between JIT access and Zero Trust for NHIs?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?