Zero Trust audits fail when access controls remain inconsistent

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Forescout's research: ZTNA alone does not make an environment Zero Trust compliant because audit success depends on consistent enforcement, continuous verification, and least privilege across every access path.

Why it matters: IAM, NHI, and security teams need audit evidence that policy, session control, and segmentation apply everywhere, including privileged users, workloads, and internal connections.

Context

Zero Trust is an architecture, not a product category. It depends on continuous verification, least privilege, and limiting blast radius, so switching remote access technology without proving those outcomes leaves an audit gap rather than closing one.

That gap is often architectural: different user groups, workloads, and internal systems may still follow separate trust paths. Where a ZTNA deployment does not govern the full access estate, the control can be functioning as configured and still fail an audit.

For identity teams, the important question is whether the access model covers human users, privileged admins, service accounts, and internal workloads with the same policy logic. Partial coverage creates inconsistent enforcement that auditors can see even when operations teams view the rollout as complete.

Key questions

Q: How should security teams replace VPN trust with zero trust access controls?

A: Start by defining access around the resource and the task, not the network location. Enforce continuous checks for identity, device posture, and policy compliance, then limit each session to the smallest set of actions needed. The goal is to make every access decision temporary, contextual, and revocable.

Q: Why does ZTNA still fail when internal systems keep direct connections?

A: ZTNA still fails when internal systems keep direct connections because policy is bypassed once a device, user, or workload can reach internal resources without passing the enforcement point. ZTNA depends on per-session verification, least-privilege access, and brokered connections. Flat network routes, broad VPN reach, and unmanaged service accounts undermine that control.

Q: What is the difference between ZTNA and Zero Trust architecture?

A: ZTNA is a way to broker access to applications without exposing the full network. Zero Trust architecture is the broader model that continuously verifies identity, device state, policy, and permissions. In practice, ZTNA handles access paths, while Zero Trust also requires governance over what identities can do after access is granted.

Q: How do security teams know if their verification controls are actually working?

A: They work if high-risk requests cannot be completed through a single channel and if helpdesk or approval attempts leave a clear audit trail. Look for reductions in informal overrides, fewer password resets completed without corroboration, and lower success rates for phishing simulations that use synthetic audio or video.

Technical breakdown

Why ZTNA does not equal full Zero Trust enforcement

ZTNA is a policy enforcement mechanism for specific access flows, not a complete security architecture. It can broker user-to-application access while other routes, such as direct on-prem connections, privileged administration paths, or workload-to-workload traffic, remain outside the policy plane. That leaves an environment with mixed trust behavior: some requests are evaluated centrally, while others are not. An auditor sees the inconsistency, even if each individual component is working as designed. See the Zero Trust Identity Guide.

Practical implication: Map every access route to an enforcement point and close any path that bypasses centralized policy.

Continuous verification depends on live risk signals

Zero Trust assumes trust must be re-evaluated as conditions change. A successful login at the start of a session does not satisfy that requirement if the device later becomes risky and the access decision is not updated. ZTNA deployments only deliver continuous verification when they consume posture, telemetry, and threat signals quickly enough to change the active session, not just the next login. That difference separates static authentication from risk-responsive access control. See the Remote Access Identity Guide.

Practical implication: Wire endpoint and identity risk signals into session control so a compromised device can lose access before the session times out.

East-west segmentation is separate from remote-access control

Controlling the first hop into an application is not the same as controlling what that application can reach afterwards. Many Zero Trust gaps emerge when application servers, databases, and domain controllers can still talk freely once the user is in. In that pattern, ZTNA validates the entry request, but lateral movement remains possible inside the environment. True segmentation requires policy on internal dependencies, not only on remote entry. See the Core Security Principles Guide.

Practical implication: Apply policy to internal application dependencies, not just to the initial user connection.

Threat narrative

Attacker objective: Maintain usable access long enough to move from the initial foothold into additional internal systems that sit outside the ZTNA policy boundary.

1. Entry occurs through a legitimate remote access session that is allowed because the initial identity and device checks pass.
2. Escalation happens when the compromised device retains access after its risk posture changes and the active session is not revoked.
3. Lateral movement becomes possible when the connected application can reach internal dependencies that are not covered by the same enforcement policy.
4. Impact is audit failure and a wider blast radius, because the environment cannot demonstrate consistent Zero Trust enforcement across all paths.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust audit failure is usually a control-consistency problem, not a tooling problem. Forescout's analysis shows that a ZTNA rollout can still leave auditors unconvinced when some access paths remain direct, some sessions are not revoked on new risk, and some internal routes bypass segmentation. The field mistake is treating Zero Trust as a procurement outcome instead of an architectural proof problem. Practitioners need evidence that every path is governed by the same decision logic.

Least privilege becomes meaningless when it applies only to the front door. If remote users are filtered but privileged admins, internal workloads, and service accounts keep broader routes, the environment still permits access that Zero Trust is supposed to constrain. That is why identity scope matters as much as network scope. The relevant shift is from controlling entry to controlling every trust decision across the access estate.

Continuous verification is the named concept auditors are really testing. The article's core failure mode is a verification gap: an initial good decision is allowed to stand after the underlying risk changes. That gap is visible in environments where endpoint telemetry, policy enforcement, and access revocation do not move together. Security leaders should measure whether session control reacts to new context, not whether login worked at 9 a.m.

Universal access models matter because heterogeneous environments defeat partial Zero Trust designs. Brownfield networks, OT, legacy applications, and internal workloads rarely fit a single access pattern. Forescout's framing is useful here because it shows why partial coverage produces audit drift even when individual controls are technically correct. The practitioner conclusion is straightforward: if the architecture cannot express one policy model across all paths, the audit story will stay fragmented.

NHI and workload access must be part of the same Zero Trust evidence set as human access. Service accounts and internal workloads are often the least visible trust paths, yet they can bypass the very policy enforcement auditors expect to see. That makes least privilege techniques and workload-scoped access controls central to Zero Trust assurance, not optional extras. Identity governance is strongest when it covers every principal, not only interactive users.

From our research library:

• More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to Gartner.
• Read next: Least Privilege Techniques Guide

What this signals

Continuous verification gap: The biggest operational risk is not login failure, but the gap between a valid session and the moment risk changes. When telemetry, endpoint response, and access enforcement are not tightly coupled, compromise can persist inside an apparently successful access flow.

A zero trust programme should therefore be measured by how quickly it converts new context into a new access decision. If posture drift, privileged access, and internal connectivity are managed on different clocks, the audit story will remain inconsistent even when individual controls are in place.

Service and workload access deserve the same scrutiny as human access because excessive privilege compounds the impact of a bypassed policy path. According to the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

For practitioners

• Map every access path to a policy enforcement point Inventory remote, on-premises, privileged, workload, and internal application routes, then identify which ones do not pass through centralized Zero Trust policy enforcement. See the Core Security Principles Guide.
• Revoke sessions on risk change, not just at login Feed endpoint and identity telemetry into the access layer so posture changes can terminate active sessions before the current token or connection expires.
• Extend segmentation to east-west traffic Apply internal access policy to application servers, databases, domain controllers, and other dependent systems so the first allowed connection does not become a lateral movement path.
• Treat service accounts as Zero Trust principals Bring service accounts, privileged admins, and workloads under the same identity verification and least privilege model used for users, with explicit evidence for each.
• Document audit evidence for every control decision Record who accessed what, from which device, under which policy, and why the decision changed, so compliance reviews can validate enforcement consistency rather than intention. Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.

Key takeaways

• Zero Trust compliance depends on consistent enforcement across every access path, not on whether remote access has been moved from VPN to ZTNA.
• A deployment can function as designed and still fail an audit if sessions are not revoked when risk changes or if internal dependencies remain outside policy control.
• The most defensible control story combines continuous verification, least privilege, and east-west segmentation with evidence that each principal and path is covered.

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Core Security Principles Guide · Least Privilege Techniques Guide · Zero Trust for AI Agents

Key terms

• Zero Trust Architecture (ZTA): Zero Trust Architecture is a security model that assumes no user, device, workload, or network path should be trusted by default. It continuously verifies identity, context, and policy before allowing access, using least privilege, strong authentication, and segmentation to reduce blast radius and limit lateral movement.
• Zero-Trust Network Access: Zero-Trust Network Access is a way to give users secure access to specific applications without placing them on the internal network. Access is granted only after identity, device posture, and policy checks, then limited to the requested resource. ZTNA reduces lateral movement by replacing broad network trust with per-session authorization.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
• East-west traffic: East-west traffic is communication that moves between systems inside an environment rather than entering or leaving it. In microsegmentation programmes, it is the traffic most likely to expose hidden trust assumptions and is therefore the main target for workload-level policy.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps practitioners connect identity controls to the wider security architecture that Zero Trust depends on.