SY0-701Chapter 8 of 212Objective 1.2

Zero Trust Architecture

This chapter covers Zero Trust Architecture (ZTA), a foundational security model that shifts from perimeter-based defense to a 'never trust, always verify' approach. For the SY0-701 exam, this maps to Objective 1.2 (General Security Concepts) and is critical for understanding modern network design, identity management, and micro-segmentation. Zero Trust is not a product but a strategic framework that assumes breach and enforces strict access controls regardless of user location.

25 min read
Intermediate
Updated May 31, 2026

The All-Access Building Pass vs. Room-by-Room Badge

Imagine a corporate office building. In the traditional perimeter-based security model, every employee gets a single all-access building pass. Once you show that pass at the front door, you can roam freely: enter the server room, walk into the CEO's office, or access the finance department's file cabinets. The security guard at the entrance trusts anyone with a badge. If an attacker steals that badge—or if a disgruntled employee uses it—they have unfettered access to everything. Now consider a Zero Trust building. There is no single all-access pass. Instead, each employee gets a badge that only opens the specific doors they need for their current task, and only during their work hours. To enter the server room, you must authenticate at that door with a separate verification—maybe a fingerprint scan. The guard at the entrance still checks your ID, but then every internal door also requires authentication and authorization. Even if an attacker steals your badge, they can't open the server room door because they can't provide your fingerprint. The building's network is segmented into micro-perimeters: each floor, each room is its own security zone. This mirrors Zero Trust's 'never trust, always verify' principle: no implicit trust is granted based on location (inside the building) or identity alone. Every access request is evaluated in real time, with context (time, location, device health).

How It Actually Works

What is Zero Trust Architecture?

Zero Trust Architecture (ZTA) is a security model that eliminates implicit trust by continuously validating every stage of a digital interaction. It was popularized by John Kindervag at Forrester Research in 2010 and has become the de facto standard for modern enterprise security, especially with the rise of cloud computing and remote work. The core principle is 'never trust, always verify'—meaning no user, device, or network segment is trusted by default, even if they are inside the corporate perimeter.

The Threat It Addresses

Traditional perimeter-based security (the 'castle-and-moat' model) assumes that everything inside the network is safe. Once an attacker breaches the perimeter—via phishing, stolen credentials, or a zero-day exploit—they can move laterally with little resistance. Zero Trust assumes that a breach has already occurred or will occur, and therefore restricts lateral movement by enforcing granular access controls. This mitigates the impact of credential theft, insider threats, and advanced persistent threats (APTs).

How Zero Trust Works Mechanically

Zero Trust operates on three core principles: - Verify explicitly: Always authenticate and authorize based on all available data points (user identity, location, device health, service/ workload, data classification, and anomalies). - Use least privilege access: Limit user access with Just-In-Time (JIT) and Just-Enough-Access (JEA) policies, risk-based adaptive policies, and data protection. - Assume breach: Minimize blast radius by segmenting access (micro-segmentation), encrypting all communications, and using analytics to detect threats in real time.

A typical Zero Trust access request follows this flow: 1. User initiates access to a resource (e.g., an application or database). 2. Policy Enforcement Point (PEP) intercepts the request (e.g., a gateway or reverse proxy). 3. Policy Decision Point (PDP) evaluates the request against policies: checks identity (e.g., via SAML or OIDC), device posture (e.g., endpoint compliance via MDM), location, time, and risk score. 4. PDP returns allow/deny decision to PEP. 5. PEP enforces the decision: allows access, denies, or triggers step-up authentication (e.g., MFA). 6. Continuous monitoring of the session for anomalies; if risk increases, the session may be terminated.

Key Components of Zero Trust

Identity: The foundation. Uses IAM (Identity and Access Management) with strong authentication (MFA, passwordless).

Device: Endpoint health and compliance are checked before granting access. Tools: MDM (Mobile Device Management), EDR (Endpoint Detection and Response).

Network: Micro-segmentation isolates workloads; use of software-defined perimeter (SDP) or next-gen firewalls (NGFW) to enforce per-application access.

Data: Encryption at rest and in transit; data classification and labeling; DLP (Data Loss Prevention).

Applications: Application-level access controls; no direct network access; use of reverse proxies.

Automation and Orchestration: Policy engines that automate decisions; SOAR (Security Orchestration, Automation, and Response) for incident response.

Variants and Standards

NIST SP 800-207: The definitive guide for Zero Trust Architecture, published by the National Institute of Standards and Technology. It defines logical components: Policy Engine (PE), Policy Administrator (PA), and Policy Enforcement Point (PEP).

Google BeyondCorp: A zero-trust model that shifts access from network perimeter to user and device identity. No VPN required.

Cisco Zero Trust: Focuses on user, device, network, and application.

Palo Alto Networks Zero Trust: Uses NGFW with App-ID and User-ID.

Zscaler Zero Trust Exchange: A cloud-based SDP that connects users to apps directly, not to the network.

How Attackers Exploit Weak Zero Trust Implementations

Token theft: If an attacker steals an OAuth token, they can impersonate a user. Mitigation: short token lifetimes and token binding.

Device spoofing: An attacker uses a compromised device that passes posture checks. Mitigation: device attestation and continuous monitoring.

Policy misconfiguration: Overly permissive policies allow lateral movement. Mitigation: regular policy reviews and use of default-deny.

Insider threats: A legitimate user with access abuses privileges. Mitigation: JIT and JEA, user behavior analytics (UBA).

Real Command/Tool Examples

Micro-segmentation with iptables:

# Allow only SSH from specific IP to a specific host
iptables -A INPUT -s 10.0.1.0/24 -d 192.168.1.10 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP

Policy Enforcement with Nginx as a reverse proxy:

server {
    listen 443 ssl;
    location /api/ {
        # Enforce authentication via OAuth2 proxy
        auth_request /auth;
        proxy_pass http://backend;
    }
}

OAuth2 token validation using curl:

curl -H "Authorization: Bearer <token>" https://api.example.com/resource

Device posture check with Microsoft Intune: Script to check if device is compliant:

$compliant = Get-IntuneDeviceCompliancePolicy -DeviceId $deviceId
if ($compliant) { Write-Host "Device is compliant" }

Walk-Through

1

Identify and Classify Resources

Begin by cataloging all data, applications, assets, and services (DAAS) within the organization. For each resource, determine its sensitivity level (e.g., public, internal, confidential, restricted). Use data classification tools like Microsoft Information Protection or Boldon James. This step is critical because Zero Trust policies are built around protecting these resources. A common mistake is skipping classification and applying blanket policies, which either over-restrict or under-protect. The output is a resource inventory with metadata tags.

2

Map Transaction Flows

Identify how users, devices, and services interact with each resource. For each flow, document the source, destination, protocol, and required privileges. Tools like network traffic analyzers (e.g., Wireshark, Zeek) or cloud flow logs (e.g., AWS VPC Flow Logs) help. This step reveals dependencies and potential lateral movement paths. In a Zero Trust model, you want to minimize flows by implementing micro-segmentation. A common mistake is assuming all flows are necessary; challenge each flow and eliminate any that lack a business justification.

3

Design Zero Trust Architecture

Based on the resource classification and flows, design the logical architecture. Define Policy Engine (PE), Policy Administrator (PA), and Policy Enforcement Points (PEPs). Choose a deployment model: either a greenfield implementation or overlay on existing infrastructure. For SY0-701, understand the NIST SP 800-207 components. The architecture must include identity provider (IdP), device management (MDM), and a policy engine (e.g., Cisco ISE, Azure AD Conditional Access). A common mistake is trying to implement Zero Trust as a single product rather than a set of integrated controls.

4

Implement Policies and Enforcement

Create policies that enforce least privilege and explicit verification. Policies should be dynamic, incorporating user role, device posture, location, and risk score. Use tools like Azure AD Conditional Access, which can require MFA if a sign-in is risky. Implement PEPs such as VPN-less access via a reverse proxy (e.g., Zscaler, Cloudflare Access) or a software-defined perimeter (SDP). For micro-segmentation, use network firewalls or host-based firewalls (e.g., Windows Defender Firewall). A common mistake is applying static policies that don't adapt to context.

5

Monitor and Maintain

Continuously monitor all sessions for anomalies. Use SIEM (e.g., Splunk, Azure Sentinel) to collect logs from PEPs, IdP, and endpoints. Implement User and Entity Behavior Analytics (UEBA) to detect deviations (e.g., a user accessing resources at unusual times). Regularly review and update policies based on new threats or changes in resource classification. Perform tabletop exercises to test incident response. A common mistake is treating Zero Trust as a one-time project; it requires ongoing tuning and validation.

What This Looks Like on the Job

Scenario 1: Remote Access to Corporate Applications

A large enterprise with 10,000 remote employees uses a legacy VPN for accessing internal apps. The VPN grants full network access, leading to lateral movement after a credential theft incident. The SOC analyst sees alerts from the SIEM indicating a user account 'jdoe' is logging in from an unusual IP (Russia) and accessing HR databases at 3 AM. The analyst uses Azure AD Conditional Access to revoke the session and require MFA re-authentication. The correct response is to implement ZTA by replacing the VPN with a Zscaler Zero Trust Exchange, which provides per-application access based on identity and device posture. The analyst would see logs showing no network-level access, only application sessions. A common mistake is keeping the VPN and adding MFA, which still allows lateral movement if the VPN is compromised.

Scenario 2: Insider Threat Detection

A finance department employee, 'asmith', suddenly accesses the source code repository (which is not part of her job role). The Zero Trust policy engine (e.g., Cisco ISE) flags this as anomalous because the access policy only allows developers. The PEP (a reverse proxy) denies the request and logs the attempt. The SOC analyst reviews the alert in the SIEM and sees that 'asmith' attempted to access 'git.company.com' from her workstation. The analyst confirms with the manager that this is unauthorized and triggers an investigation. The correct response is to block the access and investigate potential credential compromise or malicious intent. A common mistake is ignoring the alert because 'asmith' is a trusted employee, but Zero Trust assumes no implicit trust.

Scenario 3: Third-Party Vendor Access

A vendor needs temporary access to a specific API for integration testing. Using a traditional model, the vendor might get a VPN account and full network access. In a Zero Trust model, the administrator creates a JIT (Just-In-Time) access policy that grants access to only the API endpoint for a 24-hour window, using a guest identity provider (e.g., Azure AD B2B). The PEP enforces the policy, and logs show only API calls, no network scans. The SOC analyst sees the access in the SIEM and can verify it matches the approved request. A common mistake is granting permanent access or overly broad permissions, which violates least privilege.

How SY0-701 Actually Tests This

What SY0-701 Tests on Zero Trust

Objective 1.2: General Security Concepts – Zero Trust is a key concept. The exam expects you to understand the three core principles: verify explicitly, least privilege, assume breach.

Know the NIST SP 800-207 components: Policy Engine (PE), Policy Administrator (PA), Policy Enforcement Point (PEP). The exam may ask which component makes the access decision (PE) or enforces it (PEP).

Understand micro-segmentation: It's a technique to isolate workloads and limit lateral movement. The exam may contrast it with VLANs or network segmentation.

Be familiar with SDP (Software-Defined Perimeter): Often called the 'black cloud' – it hides infrastructure and grants access on a per-request basis.

Know that Zero Trust is NOT a product: It's a framework. Wrong answers often list a specific product as 'Zero Trust'.

Common Wrong Answers and Why

1.

'Zero Trust means no passwords' – Zero Trust emphasizes strong authentication, including MFA, but passwords are still used. The exam tests that passwordless is a trend, not a requirement.

2.

'Zero Trust eliminates the need for firewalls' – Firewalls are still used as PEPs, but they are not the only control. The exam expects you to know that micro-segmentation uses firewalls at a granular level.

3.

'Zero Trust only applies to cloud environments' – Zero Trust applies to on-prem, hybrid, and cloud. The exam may present a scenario with an on-prem data center and expect Zero Trust principles.

4.

'Zero Trust means no VPN' – While many Zero Trust implementations replace VPNs with SDP, the exam does not mandate eliminating VPNs. The key is that VPNs alone don't provide Zero Trust.

Specific Terms to Memorize

PEP, PE, PA – know their roles.

NIST SP 800-207 – the standard.

BeyondCorp – Google's implementation.

JIT/JEA – Just-In-Time and Just-Enough-Access.

SDP – Software-Defined Perimeter.

Decision Rule for Scenario Questions

When given a scenario asking which security model to implement, look for keywords: 'assumes breach', 'least privilege', 'micro-segmentation', 'verify every access'. If the scenario mentions 'trust no one inside the network', it's Zero Trust. If it focuses on 'strong perimeter' or 'IDS/IPS at the border', it's traditional perimeter defense. Eliminate any answer that says 'implicit trust' or 'once inside, trusted'.

Key Takeaways

Zero Trust is a security model, not a product; it's based on 'never trust, always verify'.

NIST SP 800-207 defines three core components: Policy Engine (PE), Policy Administrator (PA), and Policy Enforcement Point (PEP).

Micro-segmentation divides the network into small, isolated zones to limit lateral movement.

Least privilege is enforced through Just-In-Time (JIT) and Just-Enough-Access (JEA) policies.

Zero Trust assumes breach, so it focuses on reducing blast radius and continuous monitoring.

Software-Defined Perimeter (SDP) is a common Zero Trust implementation that hides infrastructure and grants access per request.

Google BeyondCorp is a well-known Zero Trust implementation that removes the need for VPN.

Zero Trust applies to all environments: on-premises, cloud, and hybrid.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Traditional Perimeter Security

Trusts users inside the network implicitly

Single perimeter defense (firewall/VPN)

Lateral movement is possible once inside

Access based on network location (IP address)

Static policies (e.g., group membership)

Zero Trust Architecture

Never trusts implicitly; verifies every request

Multiple micro-perimeters (per resource)

Lateral movement is blocked by micro-segmentation

Access based on identity, device, and context

Dynamic policies (risk-based, JIT)

Watch Out for These

Mistake

Zero Trust means you don't trust any users or devices at all.

Correct

Zero Trust does not mean distrust; it means 'never trust implicitly'. Trust is established dynamically based on multiple factors (identity, device, context) and is continuously verified. Users and devices are trusted only after successful verification and only for the specific access needed.

Mistake

Implementing Zero Trust requires a complete network overhaul.

Correct

Zero Trust can be implemented incrementally. Many organizations start with a specific application or workload, using an overlay architecture (e.g., SDP) that doesn't require replacing existing infrastructure. NIST SP 800-207 describes deployment variants including 'greenfield' and 'overlay'.

Mistake

Zero Trust eliminates the need for perimeter firewalls.

Correct

Perimeter firewalls still play a role as one layer of defense, but Zero Trust adds micro-segmentation and per-application access controls. Firewalls are used as PEPs for specific segments, not as the sole gatekeeper.

Mistake

Zero Trust is only for large enterprises with big budgets.

Correct

Zero Trust principles can be applied at any scale using cloud-based services (e.g., Azure AD Conditional Access, Cloudflare Access) that are affordable even for small businesses. The key is the mindset, not the cost.

Mistake

Zero Trust and the principle of least privilege are the same thing.

Correct

Least privilege is a component of Zero Trust, but Zero Trust is broader, including explicit verification and assume breach. Least privilege alone does not require continuous verification or micro-segmentation.

Frequently Asked Questions

What is the difference between Zero Trust and the principle of least privilege?

Least privilege is a security principle that grants users only the permissions they need to perform their job. Zero Trust is a broader architecture that includes least privilege but also adds explicit verification of every access request, continuous monitoring, and the assumption that a breach has occurred. In Zero Trust, least privilege is enforced through JIT and JEA policies, but Zero Trust also requires verifying the user and device at every access attempt, not just at login.

What are the main components of Zero Trust according to NIST SP 800-207?

NIST SP 800-207 defines three logical components: Policy Engine (PE) which makes access decisions based on policy and context; Policy Administrator (PA) which generates authentication tokens and configures the PEP; and Policy Enforcement Point (PEP) which enforces the decision by allowing or denying access. The PEP can be a gateway, firewall, or agent. The PE and PA are often combined in a single product like Azure AD Conditional Access.

How does micro-segmentation work in Zero Trust?

Micro-segmentation divides the network into very small zones, often at the workload level, using virtual firewalls or host-based firewalls. Each zone has its own security policies that control traffic between zones. For example, a web server can only talk to a database server on a specific port, and no other traffic is allowed. This prevents lateral movement if an attacker compromises one zone. Tools include VMware NSX, Cisco ACI, or iptables on Linux.

Is Zero Trust the same as a software-defined perimeter (SDP)?

No, but SDP is a key technology used to implement Zero Trust. SDP creates a 'black cloud' that hides network infrastructure; users and devices must authenticate and be authorized before they can see any resources. SDP typically uses a controller to authenticate users and a gateway to proxy connections. While Zero Trust is a broader framework, SDP is one of its most common implementations.

Can Zero Trust be applied to on-premises data centers?

Yes, Zero Trust applies to any environment. For on-premises, you can implement micro-segmentation using VLANs or firewalls, enforce strong authentication with an on-premises identity provider (e.g., Active Directory with MFA), and use network access control (NAC) to check device posture. The principles are the same regardless of where the resources are located.

What is the role of MFA in Zero Trust?

MFA is a critical component of explicit verification. In Zero Trust, every access request should be authenticated, and MFA adds an extra layer of security beyond passwords. It is often required when accessing sensitive resources or when the access context is risky (e.g., from an unknown location). The exam expects you to know that MFA is a key control for verifying identity in Zero Trust.

How does Zero Trust handle insider threats?

Zero Trust mitigates insider threats by enforcing least privilege and continuous monitoring. Even a trusted user with valid credentials is only given the minimum access needed, and any anomalous behavior (e.g., accessing resources outside of normal patterns) triggers alerts or access revocation. User and Entity Behavior Analytics (UEBA) is often used to detect insider threats.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Zero Trust Architecture — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.

Done with this chapter?