What happens when organisations try to use zero trust without changing access control first?

They usually preserve the old perimeter model and only rename it, which leaves the underlying risk unchanged. The article argues that zero trust starts with access control, so if teams do not redesign how access is granted, they keep implicit trust in place. In that state, the organisation may add monitoring or policy layers, but the core trust decision still remains weak.

Why Zero Trust Fails When Access Control Stays Implicit

Zero trust is not a monitoring overlay for the old perimeter model. If access decisions still depend on broad network location, inherited group membership, or long-lived standing privileges, the organisation has preserved the same trust assumptions under a new label. That creates a false sense of progress: tools may become more visible, but the decision logic that grants access still assumes the requester is safe enough by default.

NIST SP 800-207 Zero Trust Architecture treats zero trust as a shift in authorisation model, not just a boundary control. NHIMG’s Ultimate Guide to NHIs is also relevant because the same pattern often appears in service accounts, API keys, and other machine access paths: if the grant model is unchanged, the control plane remains permissive even when the architecture is rebranded. In practice, many teams discover the mismatch only after an access review exposes that “zero trust” still means broad trust for too many identities.

What Changes in Practice When Access Decisions Are Redesigned

Real zero trust starts by narrowing how trust is established, evaluated, and refreshed. Access should be based on explicit identity, device or workload posture, context, and policy, rather than on the assumption that anything inside a network segment or enterprise toolchain deserves broad reach. That means replacing static allow rules with shorter-lived, more specific decisions that can be re-evaluated as conditions change.

For human users, this usually means tighter authentication, stronger conditional access, and reduced standing privilege. For workloads and agents, it means workload identity, short-lived credentials, and scoping access to the minimum action set needed for the current task. Without that shift, teams often add policy engines or logging around a fundamentally permissive grant model, which improves observability but not the actual trust boundary.

The practical test is whether the access path still works if you remove network location as a factor. If the answer is yes because a user, app, or automation can still inherit broad access from legacy roles, then zero trust has not changed the core control. The more modern pattern is to treat every request as needing a fresh decision, with privilege bound to purpose, time, and context.

Replace durable access with time-bounded grants where the use case allows it.
Remove implicit trust inherited from flat networks, VPN presence, or legacy roles.
Treat machine and agent credentials as constrained identities, not shared infrastructure secrets.
Require policy checks that are specific enough to deny unnecessary actions, not just detect them later.

NHIMG data shows why this matters operationally: only 5.7% of organisations have full visibility into their service accounts, which makes any zero-trust programme that ignores machine access especially brittle. These controls tend to break down when legacy directories, SaaS entitlements, and automated workloads all keep separate permission models that no one has fully reconciled.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, so organisations have to balance assurance against friction. That tradeoff is especially visible in legacy environments, where some systems cannot support short-lived credentials, real-time policy checks, or fine-grained authorisation without redesign.

Best practice is evolving, but current guidance suggests treating those exceptions as technical debt to reduce rather than as proof that zero trust is impossible. Mixed estates often need a staged approach: first identify where access is still implicitly trusted, then isolate the highest-risk paths, then progressively replace broad entitlements with narrower decisions. The most common mistake is to focus on network segmentation alone and call the result zero trust, even though the access model itself has not changed.

For machine-heavy environments, the edge case is not whether a service account can authenticate, but whether it can do too much once authenticated. That is where zero trust either becomes real or stays cosmetic.

Risk and Threat Considerations

The material risk is privilege persistence under a new architecture label. When access control is not redesigned, attackers and insiders can still exploit standing trust, inherited permissions, and overly broad entitlements to move through systems that are supposed to be tightly constrained.

Failure mechanism: Legacy role membership, network trust, or shared machine credentials continue to grant access even after zero-trust tooling is introduced, so the defender adds inspection without removing the underlying privilege path.

Impact: Compromise of one account, token, or workload can still expose multiple systems, and the organisation loses the main benefit zero trust is supposed to provide: reduced blast radius.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	Zero trust depends on reducing implicit access and enforcing explicit decisions.
Recommendation — Redesign access grants so every request is explicitly authorised and bounded.
NIST Zero Trust (SP 800-207)	3.4 — Policy Enforcement Point and Decision Process	The question is about changing access control, which is central to zero trust architecture.
Recommendation — Implement continuous policy decisions instead of relying on network location or legacy trust.
CIS Controls v8	6 — Access Control Management	Stale roles and broad entitlements are the failure mode when zero trust is layered on top.
Recommendation — Review and remove standing access that is not needed for current business use.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	Machine and service identities often preserve the old access model in zero-trust projects.
Recommendation — Inventory machine identities so you can replace implicit access with accountable ownership.
OWASP Agentic AI Top 10	A1 — Agent Identity and Access	Autonomous agents need explicit, bounded access rather than inherited trust.
Recommendation — Bind agent actions to explicit identity and least-privilege access decisions.

Practitioner Guidance

What to prioritise: Start by identifying where access is still granted because a requester is “inside” the environment, not because the request was explicitly evaluated. That includes legacy VPN trust, broad group membership, and service accounts with durable privileges.

What to verify: Confirm that the critical access paths actually depend on fresh policy decisions and not on inherited access from old role structures. If access remains valid after removing the network boundary assumption, the programme is still operating on perimeter logic.

Decision rule: If a workload, user, or agent can reach sensitive resources without short-lived, purpose-bound authorisation, treat the design as incomplete zero trust rather than as a monitoring problem.

Practitioner takeaway: Zero trust is measured by what it refuses by default, not by how much telemetry it adds around the same old permissions model.