How should security teams implement zero trust when users, devices, and applications are no longer trusted by default?

Security teams should combine least privilege, multi factor authentication, continuous monitoring, and data visibility so access is granted only when needed and only to the right content. In practice, zero trust works best when identity controls are paired with sensitivity classification and ongoing anomaly detection. That reduces credential theft risk, limits lateral movement, and helps teams verify access decisions continuously.

Zero trust moves the trust decision to the request, not the network

zero trust is not a single product or a one-time network redesign. It is an access model that assumes each request may be hostile until the request context is checked against policy, identity, device state, workload posture, and data sensitivity. That matters because legacy perimeter thinking often grants broad implicit trust once a user or application is “inside,” which creates unnecessary exposure when credentials, endpoints, or services are compromised. The NIST model for zero trust architecture is useful here because it formalises the shift away from default trust and toward continuous, policy-driven verification. NIST SP 800-207 Zero Trust Architecture

For security teams, the practical change is that identity alone is not enough and network location alone is not enough. Access decisions should reflect who is asking, what device or workload is asking, what resource is being requested, and whether the request still fits policy at the moment it is made. In practice, many security teams first discover where their implicit trust remains only after a privileged session, SaaS token, or internal application path has already been abused.

How to operationalise zero trust across people, endpoints, and workloads

Implementing zero trust means treating authentication, authorisation, and verification as ongoing controls rather than a single gate at login. A user may authenticate successfully and still be denied access if the device is unmanaged, the session looks unusual, or the request targets sensitive data outside the user’s current need. The same logic applies to applications and services: a workload should not inherit broad east-west access simply because it lives in the same environment or shares a subnet.

At a practical level, teams usually need to align three layers:

Identity and session assurance, so access starts with a strong signal about the principal and the context of the request.
Device and workload posture, so unmanaged, jailbroken, stale, or misconfigured assets do not receive the same trust as known-good ones.
Data and application policy, so the resource itself carries the rules that determine whether the request is still allowed.

This is where zero trust becomes operational rather than rhetorical. If a file, API, or application can be accessed only after policy checks confirm the request is appropriate, then lateral movement becomes harder and stolen credentials become less valuable. That is also why visibility matters: teams need telemetry on denied requests, step-up challenges, abnormal access paths, and policy exceptions to see whether their controls are actually reducing exposure. The most useful signal is not just successful authentication, but whether access continues to match risk as conditions change. Where organisations stop at single sign-on and call it zero trust, the model breaks down because authentication has been mistaken for continuous verification.

Where zero trust becomes brittle: legacy trust paths, exceptions, and overloaded policies

Tighter access control often increases operational overhead, requiring organisations to balance stronger containment against user friction and administrative complexity.

One common edge case is the legacy application that cannot evaluate context well or cannot enforce granular authorisation. In those cases, teams often compensate with network segmentation, proxy enforcement, or wrapper controls, but the protection is weaker than a native policy decision at the resource. Another variation is the exception process: if service accounts, break-glass access, or contractor workflows are left outside normal policy for convenience, those paths can become the least governed part of the environment.

There is also a genuine consensus gap in the industry about how much emphasis to place on device trust versus identity trust for different use cases. The practical answer depends on the asset being protected. For high-value internal applications and sensitive data, device posture and session risk usually matter more than for low-risk self-service tools. For machine-to-machine access, workload identity and secrets handling matter more than user-centric controls. Teams should use the same zero trust logic, but not the same control stack, across every scenario. The NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is useful when teams need to translate that model into specific control families for access, monitoring, and configuration.

Where zero trust is least effective is where organisations preserve broad exceptions, over-trust inherited permissions, or fail to define what “trusted enough” means for each application tier.

Risk and Threat Considerations

Zero trust is primarily about reducing the blast radius of compromise, but it also changes the attacker’s economics. If access depends on continuous policy checks, attackers have a harder time turning one stolen credential, one hijacked session, or one compromised endpoint into broad internal reach. The risk is greatest when an organisation labels a network or identity plane “zero trust” while still leaving implicit trust paths in place.

Failure mechanism: Attackers commonly exploit inherited trust, over-permissive session tokens, unmanaged device access, or weak exception handling to move from initial access to broader exposure. If policy checks are only performed at login, a compromised session can remain valid long enough to access sensitive applications or data without re-evaluation.

Impact: The consequence is usually lateral movement, data exposure, or privilege expansion across systems that were assumed to be protected by the zero trust model. In hybrid and SaaS-heavy environments, that can also create governance gaps where security teams lose sight of which requests were actually authorised versus merely authenticated.

Standards & Framework Alignment

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

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication, and Access Control	Zero trust depends on strong identity and access decisions at request time.
	PR.AC-4 — Access Permissions and Authorisations	Zero trust requires access decisions to reflect current need and context.
	DE.CM-7 — Monitoring for Unauthorised Personnel, Connections, Devices, and Software	Zero trust relies on continuous monitoring of sessions and device posture.
Recommendation — Enforce least-privilege access and continuous authentication for each request. Restrict permissions to the minimum required for each user and workload. Monitor access behaviour continuously to detect policy drift and abnormal use.
CIS Controls v8	6 — Access Control Management	Zero trust operationalises tighter access governance across users and systems.
	8 — Audit Log Management	Zero trust needs logging to validate access decisions and spot misuse.
	5 — Account Management	Zero trust depends on controlling identities, lifecycle, and privileged access.
Recommendation — Review and revoke unnecessary access paths so trust is not implied by location. Log access decisions and exceptions so continuous verification remains auditable. Manage account lifecycle tightly so stale identities do not retain trust.
MITRE ATT&CK	T1078 — Valid Accounts	Zero trust directly targets abuse of stolen or misused credentials.
	T1210 — Exploitation of Remote Services	Zero trust reduces the value of remote access paths attackers use after compromise.
Recommendation — Detect and limit valid-account abuse by adding context checks and session scrutiny. Harden remote access paths and require policy checks before remote sessions proceed.

Practitioner Guidance

What to prioritise: Start with the highest-value access paths first, not with the easiest applications to modernise. Zero trust gives the most value where privileged data, administrative actions, or broadly shared internal services still rely on implicit trust.

What to verify: Confirm that every important access decision depends on more than identity alone. Teams should be able to show which signals affect the decision, what happens when those signals change, and how exceptions are reviewed.

Common mistake: Treating single sign-on, MFA, or segmentation as proof that zero trust is in place. Those controls help, but zero trust only exists when policy keeps evaluating whether access remains appropriate throughout the session and across the request path.

Practitioner takeaway: Zero trust works when teams govern trust as a dynamic decision about each request, not as a permanent property of a user, device, or internal network.