This chapter covers Zero Trust implementation using Microsoft Security technologies, a core topic for the SC-200 exam. You will learn the principles, architecture, and practical deployment of Zero Trust with Microsoft 365 Defender, Azure AD Conditional Access, and Microsoft Sentinel. Approximately 15-20% of exam questions touch Zero Trust concepts, making this a high-yield area for passing the Security Operations Analyst exam.
Jump to a section
Zero Trust is like a modern apartment building that abandoned the old model of a single front door lock and trusted everyone inside. Instead, every door in the building requires a key card—the lobby door, the elevator, the hallway door to each floor, and finally the apartment door. The card is coded with exactly which doors the resident can open and at what times. A guest cannot enter the lobby without being buzzed in by a specific resident, and even then, the guest's card only works for that one elevator ride and that one apartment door for a limited time. The building's security system continuously monitors every card swipe—if a resident tries to enter a floor they don't live on, the door stays locked and an alert is sent. The system also checks the card's expiration, the time of day, and whether the card was reported stolen. This is exactly how Zero Trust works: no implicit trust based on location (inside the building = inside the network), every access request is verified (key card check), least privilege is enforced (only specific doors), and continuous monitoring detects anomalies (unusual swipe patterns).
What is Zero Trust and Why It Exists
Zero Trust is a security model that assumes breach and verifies each request as though it originates from an open network. It was introduced by John Kindervag at Forrester Research in 2010 as a response to the shortcomings of the traditional perimeter-based security model (castle-and-moat). In the traditional model, anything inside the corporate network was trusted by default, which allowed attackers who breached the perimeter to move laterally with little resistance. Zero Trust flips this: no entity is trusted by default, regardless of its location (inside or outside the network).
The guiding principles are: - Verify explicitly: Always authenticate and authorize based on all available data points. - Use least privilege access: Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA). - Assume breach: Segment access, verify end-to-end encryption, and use analytics to detect anomalies.
Microsoft’s Zero Trust model is built on three pillars: Identity, Endpoints, Network, Data, Applications, and Infrastructure. For SC-200, the focus is on identity (Azure AD), endpoints (Microsoft Defender for Endpoint), and network (Azure Firewall, Virtual Network security).
How Zero Trust Works Internally
At the protocol level, Zero Trust enforces access decisions at each layer. Consider a user accessing a corporate application from a personal device:
Authentication: The user presents credentials to Azure AD. Azure AD verifies the user's identity using password hash sync, Pass-through Authentication, or Federation. It also checks for risk signals from Identity Protection (e.g., impossible travel, anonymous IP).
Authorization: Conditional Access policies evaluate the request. The policy engine checks: user group membership, device compliance (Intune), location (IP range), application sensitivity, and sign-in risk. If the device is not compliant, the user may be blocked or required to enroll.
Access control: If authorized, a token is issued with claims specifying what the user can do. The application (e.g., SharePoint) enforces the token claims. For on-premises resources, Azure AD Application Proxy routes traffic after similar checks.
Micro-segmentation: Network traffic is segmented using Azure Virtual Network, Network Security Groups (NSGs), and Azure Firewall. Each resource can only communicate with specific other resources based on tags and policies.
Continuous monitoring: Microsoft 365 Defender and Microsoft Sentinel collect telemetry from endpoints, identities, and networks. Anomalies trigger automated responses (e.g., user risk policy forces password change).
Key Components, Values, Defaults, and Timers
Azure AD Conditional Access: Default policy blocks legacy authentication. Session controls include app enforced restrictions (e.g., block download for unmanaged devices), sign-in frequency (default 90 days for persistent cookies), and persistent browser session (default 90 days).
Microsoft Defender for Endpoint: Device risk score (0-100) is calculated based on signals. Default action for high-risk devices is block.
Azure AD Identity Protection: User risk policy triggers when user risk level is High (default threshold). Sign-in risk policy triggers on Medium and above.
Microsoft Sentinel: Uses KQL queries to detect anomalies. Default retention is 90 days.
Azure Firewall: Deny all by default; explicit allow rules are required. Threat intelligence-based filtering can block traffic to/from known malicious IPs.
Configuration and Verification Commands
To configure Conditional Access policy via PowerShell:
Connect-AzureAD
$policy = New-AzureADMSConditionalAccessPolicy `
-DisplayName "Block Legacy Auth" `
-State "Enabled" `
-Conditions @{`
ClientAppTypes = @("ExchangeActiveSync", "Other")`
} `
-GrantControls @{`
BuiltInControls = @("Block")`
}To verify device compliance with Intune:
Get-IntuneManagedDevice -Filter "complianceState eq 'Noncompliant'"Interaction with Related Technologies
Zero Trust integrates with: - Microsoft 365 Defender: Correlates signals from endpoints, email, and identities. - Azure AD Identity Protection: Provides risk scores used by Conditional Access. - Microsoft Endpoint Manager (Intune): Enforces device compliance. - Azure Policy: Enforces compliance on Azure resources (e.g., require encryption at rest). - Microsoft Sentinel: Collects logs and can trigger automated playbooks (e.g., isolate compromised device).
For example, a user trying to access a sensitive app from an untrusted network might trigger Conditional Access to require MFA. If the user's device is non-compliant, access is blocked. Defender for Endpoint sends a signal to Azure AD about device risk, which is factored into the access decision.
Define Zero Trust Policy Architecture
Start by identifying your protect surfaces: identities, devices, data, applications, and infrastructure. Map the data flow for each application. For each flow, define the who (identity), what (device), where (network), and why (purpose). This step is crucial because it determines which Conditional Access policies and micro-segmentation rules you need. In an enterprise, this is often a cross-team effort involving security architects, network engineers, and application owners. The output is a policy document that lists each resource, its sensitivity level, and the required controls (MFA, device compliance, encryption).
Configure Azure AD Conditional Access
Implement the policies defined in step 1. In the Azure portal, navigate to Azure Active Directory > Security > Conditional Access. Create a new policy: assign users (e.g., all users or a pilot group), cloud apps (e.g., Office 365, custom apps), conditions (e.g., locations, device platforms, client apps), and grant controls (e.g., require MFA, require device compliance). Use the 'What If' tool to test policies before enabling. A common mistake is creating overly restrictive policies that lock out admins; always include break-glass accounts excluded from policies.
Implement Device Compliance with Intune
Enroll devices in Intune and create compliance policies. For Windows 10, a compliance policy can require BitLocker encryption, firewall enabled, antivirus active (Microsoft Defender), and minimum OS version. Conditional Access can then require devices to be marked as compliant. When a device is non-compliant, the user sees a message to remediate (e.g., enable BitLocker). Intune reports compliance status in real-time. For SC-200, know that compliance is a key signal for access decisions.
Deploy Microsoft Defender for Endpoint
Onboard endpoints to Defender for Endpoint via Group Policy, Microsoft Endpoint Manager, or local script. Defender collects telemetry: process creation, network connections, file modifications. It assigns a risk score (0-100) based on detected threats. Conditional Access can use this score: for example, block access if device risk is medium or high. In the Microsoft 365 Defender portal, you can view the device risk level and investigate alerts. Integration with Azure AD allows real-time risk signals.
Enable Identity Protection and Risk Policies
In Azure AD, enable Identity Protection to detect risks like leaked credentials, impossible travel, and anonymous IP addresses. Configure user risk policy: automatically block or require password change when user risk is high. Configure sign-in risk policy: block or require MFA when sign-in risk is medium or high. These policies are part of the Zero Trust 'verify explicitly' principle. For the exam, remember that user risk is calculated over time, while sign-in risk is per attempt.
Scenario 1: Remote Access to Corporate Apps
A global enterprise with 10,000 employees uses Zero Trust to secure access to Office 365 and internal web apps from any device. They deploy Azure AD Conditional Access with policies requiring MFA for all external access, device compliance for access to sensitive HR apps, and sign-in frequency of 1 hour for finance apps. They use Azure AD Application Proxy for on-premises apps, which enforces Conditional Access before proxying traffic. Performance is monitored via Azure AD sign-in logs. A common issue is users with stale device compliance status because Intune compliance checks run every 8 hours by default; administrators increase frequency to 4 hours for sensitive groups.
Scenario 2: Micro-Segmentation in Azure
A financial services company hosts a multi-tier application in Azure: web frontend, application server, and database. They implement Zero Trust network using NSGs and Azure Firewall. Each tier is in its own subnet with NSG rules that only allow specific traffic: web subnet allows inbound from internet on port 443, app subnet only allows inbound from web subnet on port 8080, database subnet only allows inbound from app subnet on port 1433. Azure Firewall logs all traffic; anomalies trigger Sentinel alerts. A misconfiguration often occurs when an NSG rule is too permissive (e.g., allowing all inbound from VNet), which defeats segmentation. They use Azure Policy to enforce NSG rules and alert on changes.
Scenario 3: Third-Party Contractor Access
A manufacturing company grants limited access to external contractors for a specific project. They use Azure AD B2B collaboration to invite contractors as guest users. Conditional Access policies are applied: require MFA from trusted devices, block access from non-corporate IPs, and limit access to specific SharePoint sites using app enforced restrictions. Contractors use their own devices; Intune compliance is not enforced because devices are not managed. Instead, session controls block download of sensitive documents. The challenge is ensuring guest accounts are reviewed and removed after the project ends. They use Azure AD access reviews to automate quarterly certification.
SC-200 Exam Focus on Zero Trust
The SC-200 exam tests your ability to implement and manage Zero Trust using Microsoft security tools. The relevant objective is Domain 3: Cloud Security, Objective 3.2: Implement Zero Trust with Microsoft Security. Specific sub-objectives include:
Configure Conditional Access policies
Implement device compliance and risk policies
Configure Microsoft Defender for Endpoint risk-based access
Deploy Azure AD Identity Protection
Use Microsoft Sentinel for Zero Trust monitoring
Common Wrong Answers and Why Candidates Choose Them
'Zero Trust means no trust at all, so you must block everything by default.' This is wrong because Zero Trust still allows access after verification. The correct approach is 'verify explicitly and then grant least privilege access.'
'Conditional Access policies are only for cloud apps.' While they primarily target cloud apps, Conditional Access can also protect on-premises apps via Azure AD Application Proxy. Candidates often forget this integration.
'Device compliance is the same as device risk.' Compliance is a binary state (compliant/non-compliant) based on policies (e.g., BitLocker enabled). Risk is a score (0-100) based on threat telemetry from Defender for Endpoint. They are different signals used together.
'MFA alone is sufficient for Zero Trust.' MFA is one component; Zero Trust also requires device health, location, and risk assessment. Candidates often overlook the need for continuous monitoring.
Specific Numbers and Terms on the Exam
Conditional Access default sign-in frequency: 90 days for persistent cookies.
Identity Protection user risk policy triggers at High risk level by default.
Sign-in risk policy triggers at Medium and above.
Defender for Endpoint device risk score: 0-100; High risk > 70.
Intune compliance check interval: default 8 hours, configurable.
Azure AD B2B guest user access: can be limited via Conditional Access.
Edge Cases the Exam Loves
Legacy authentication: The exam tests that blocking legacy auth (POP3, IMAP, SMTP) is a common conditional access policy. Legacy auth does not support MFA.
Break-glass accounts: These must be excluded from Conditional Access policies to avoid admin lockout. They should be monitored separately.
Guest users: Conditional Access policies apply to guest users as well, but some controls (like device compliance) may not apply if the device is not managed.
Session controls: 'App enforced restrictions' can block download of sensitive data even if the user is authenticated.
How to Eliminate Wrong Answers
When you see a question about access decisions, ask: 'What signals does Conditional Access use?' The answer should include user, device, location, and risk. If an option mentions only one factor (e.g., 'user is authenticated'), it is likely wrong. For questions about micro-segmentation, remember that NSGs are stateful and can filter by source/destination IP, port, and protocol. Azure Firewall is stateless and provides more advanced features like FQDN filtering and threat intelligence.
Zero Trust principles: verify explicitly, use least privilege, assume breach.
Conditional Access policies can block legacy authentication (POP3, IMAP, SMTP) which doesn't support MFA.
Default sign-in frequency in Conditional Access is 90 days for persistent cookies.
Identity Protection user risk policy triggers at High risk; sign-in risk policy triggers at Medium and above.
Defender for Endpoint device risk score ranges 0-100; High risk > 70.
Intune compliance check interval defaults to 8 hours but can be configured.
Break-glass accounts must be excluded from Conditional Access policies to prevent lockout.
Azure AD Application Proxy extends Conditional Access to on-premises apps.
These come up on the exam all the time. Here's how to tell them apart.
Traditional Perimeter Security
Trusts everything inside the network by default.
Single perimeter defense (firewall at network edge).
Access decisions based on IP address and network location.
Lateral movement is easy once inside.
Compliance checked at entry only.
Zero Trust Security
No implicit trust; verify every access request.
Micro-perimeters around each resource.
Access decisions based on user, device, and risk.
Lateral movement is blocked by segmentation.
Continuous monitoring and compliance checks.
Mistake
Zero Trust means you should never trust any user, even after authentication.
Correct
Zero Trust means verify each request, but once verified, access is granted based on least privilege. Trust is not binary; it is conditional and continuously evaluated.
Mistake
Conditional Access policies only apply to users inside the organization.
Correct
Conditional Access applies to any user authenticating to Azure AD, including guest users from other organizations (B2B) and external identities.
Mistake
Device compliance and device risk are the same thing from Intune.
Correct
Device compliance is a binary state set by Intune policies (e.g., encryption enabled). Device risk is a score from Defender for Endpoint based on threat activity. They are separate signals.
Mistake
Zero Trust eliminates the need for firewalls and VPNs.
Correct
Zero Trust does not eliminate these; it redefines their role. Firewalls enforce micro-segmentation, and VPNs may still be used for legacy apps, but access is verified before connecting.
Mistake
MFA is the only control needed for Zero Trust identity verification.
Correct
MFA is one factor; Zero Trust also requires device health, location, and risk assessment. The principle is 'verify explicitly' using multiple signals.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
User risk is a cumulative risk score for a user account based on past suspicious activities (e.g., leaked credentials). Sign-in risk is a per-authentication risk based on signals like anonymous IP, impossible travel, or unfamiliar sign-in properties. User risk policies typically require password reset when high; sign-in risk policies can block or require MFA. Both are used in Conditional Access.
In Azure AD Conditional Access, create a policy that requires device to be marked as compliant. The device must be enrolled in Intune and meet compliance policies (e.g., BitLocker enabled, firewall on). When a user tries to access the app from a non-compliant device, they are blocked or redirected to enrollment. This integrates with Intune for compliance state.
Yes, Conditional Access policies apply to guest users (B2B) as well. You can require MFA, block access from untrusted locations, or limit access to specific apps. However, device compliance policies may not apply if the guest's device is not managed by your Intune. Use session controls like app enforced restrictions to limit data download.
Microsoft Sentinel provides continuous monitoring and threat detection across the environment. It ingests logs from Azure AD, Defender for Endpoint, and Azure Firewall. It can trigger automated playbooks to respond to incidents, such as isolating a compromised device or revoking user sessions. Sentinel helps enforce the 'assume breach' principle by detecting anomalies.
Use Network Security Groups (NSGs) and Azure Firewall. NSGs are stateful and filter traffic based on source/destination IP, port, and protocol. Assign NSGs to subnets or NICs. Azure Firewall provides additional features like FQDN filtering and threat intelligence. Combine with Azure Policy to enforce NSG rules. For example, allow only web tier to communicate with app tier on specific ports.
The default sign-in frequency for persistent browser sessions is 90 days. For mobile apps, it is 90 days as well. You can configure this in Conditional Access session controls to require reauthentication more frequently (e.g., every 1 hour) for sensitive apps.
Defender for Endpoint sends a device risk score to Azure AD. In Conditional Access, you can create a policy that requires a device risk score below a certain threshold (e.g., require device to be low or medium risk). If the device is high risk, access is blocked. This provides real-time risk-based access control.
You've just covered Zero Trust Implementation with Microsoft Security — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?