This chapter covers Zero Trust implementation in Microsoft 365, a foundational security model for the MS-102 exam. Zero Trust is not a product but a security framework that assumes breach and verifies every access request. Approximately 15–20% of exam questions touch on Zero Trust principles, conditional access, and related technologies. You will learn the three core pillars: verify explicitly, use least privilege, and assume breach, along with practical deployment using Microsoft 365 tools like Conditional Access, Intune, and Defender for Cloud Apps.
Jump to a section
Imagine a fortified embassy in a hostile city. The old perimeter security model was like having a single wall around the entire city — once inside the wall, everyone was trusted. Zero Trust is like the embassy: it assumes the city is compromised. The embassy has no single perimeter wall; instead, every door, every room, every file cabinet is individually locked and requires explicit verification. To enter the embassy, you must present a badge (identity) and be scanned (device health). Once inside, you cannot walk freely; you need a separate pass for each room (least privilege). Every movement is logged and monitored (continuous validation). If you try to open a door without a pass, alarms trigger and you are escorted out (conditional access policies revoking access). The ambassador does not trust anyone based on location — even employees inside the embassy must re-authenticate every few minutes (session timeouts). This mirrors Zero Trust's core principle: never trust, always verify, regardless of network location.
What is Zero Trust and Why It Exists
Zero Trust is a security model that eliminates implicit trust in any user, device, or network. Traditional perimeter-based security assumed that anything inside the corporate network was safe. However, modern threats like phishing, insider attacks, and cloud adoption have made the perimeter obsolete. Zero Trust, defined by NIST SP 800-207, shifts to a model where every access request is fully authenticated, authorized, and encrypted before granting access, regardless of origin. The guiding principles are:
Verify explicitly: Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.
Use least privilege: Limit user access with Just-In-Time (JIT) and Just-Enough-Access (JEA), risk-based adaptive policies, and data protection.
Assume breach: Minimize blast radius for breaches, segment access, verify end-to-end encryption, and use analytics to detect threats.
How Zero Trust Works Internally
Microsoft's Zero Trust framework is built on six pillars: Identities, Devices, Applications, Data, Infrastructure, and Network. Each pillar enforces verification at every layer.
Identities: Azure AD (now Microsoft Entra ID) is the control plane. Every access request is authenticated using modern protocols (OAuth 2.0, OpenID Connect, SAML). Conditional Access policies evaluate signals like user risk (from Identity Protection), device compliance (from Intune), and location (IP address). If a policy requires multi-factor authentication (MFA), the user must complete MFA before a token is issued. Tokens are short-lived (default 60–90 minutes for access tokens, 24 hours for refresh tokens) and can be revoked instantly.
Devices: Microsoft Intune manages device compliance. Devices must be enrolled and meet policies (e.g., encryption, OS version, antivirus). Device health is signaled via Microsoft Defender for Endpoint. Conditional Access can require devices to be marked as compliant or hybrid Azure AD joined.
Applications: Applications are discovered and controlled via Microsoft Defender for Cloud Apps (formerly MCAS). Session controls enforce data protection in real time – for example, preventing download of sensitive documents from a non-compliant device.
Data: Data classification via Microsoft Purview Information Protection labels data and applies encryption. Sensitivity labels are applied to documents and emails, and policies enforce actions like encryption or watermarking.
Infrastructure: Azure Arc and Microsoft Defender for Cloud monitor on-premises and multi-cloud resources for vulnerabilities and threats.
Network: Micro-segmentation is achieved through Azure Virtual Network, network security groups, and Azure Firewall. For Microsoft 365, network segmentation is less relevant; instead, Conditional Access and app control enforce network-level trust.
Key Components, Values, Defaults, and Timers
Conditional Access: Policies are evaluated at every sign-in. Default session timeout for Azure AD is 60 minutes for access tokens; refresh tokens expire after 90 days of inactivity. Conditional Access session controls can enforce sign-in frequency (e.g., every 1 hour).
Identity Protection: User risk and sign-in risk are calculated in real time. Risk levels: low, medium, high. For example, a sign-in from an anonymous IP address triggers medium risk. Policies can block or require password change.
Intune Compliance: Devices are checked every 8 hours (default check-in interval). Non-compliant devices can be blocked from accessing corporate resources.
Defender for Cloud Apps: Anomaly detection uses machine learning; alerts are generated for activities like impossible travel (e.g., sign-in from New York and London within 1 hour).
Privileged Identity Management (PIM): JIT activation for admin roles. Default maximum activation duration is 8 hours. Approvals can be required.
Microsoft Purview: Sensitivity labels support encryption using Azure Rights Management (RMS). Default template for highly confidential includes encryption with user-defined permissions.
Configuration and Verification Commands
Zero Trust is configured via multiple portals. Key PowerShell commands for verification:
Conditional Access policies:
Get-AzureADMSConditionalAccessPolicyLists all policies. To see details:
Get-AzureADMSConditionalAccessPolicy -PolicyId <id>Identity Protection:
Get-AzureADIdentityProtectionRiskyUser
Get-AzureADIdentityProtectionRiskySignInIntune compliance:
Get-IntuneDeviceCompliancePolicy
Get-IntuneManagedDevice | Select DeviceName, ComplianceStateDefender for Cloud Apps:
Get-MCASAlert
Get-MCASActivityPIM:
Get-AzureADMSPrivilegedRoleAssignmentInteraction with Related Technologies
Zero Trust integrates deeply with Microsoft 365 Defender (XDR) and Microsoft Sentinel (SIEM). Defender for Endpoint sends device risk signals to Conditional Access. Defender for Office 365 protects email and collaboration. Sentinel aggregates logs from all pillars to detect attacks. Azure AD Identity Protection feeds risk into Conditional Access. Intune provides device compliance. Microsoft Purview enforces data protection. Together, they create a unified Zero Trust architecture.
Exam-Relevant Details
The MS-102 exam focuses on implementing Zero Trust principles using Microsoft 365 tools. You must know the six pillars and how to configure Conditional Access, Intune compliance, and Defender for Cloud Apps.
Know the difference between Conditional Access policies and Identity Protection policies. Conditional Access enforces controls; Identity Protection detects risk.
Understand that Zero Trust does not replace firewalls or VPNs but complements them. For remote access, Azure AD Application Proxy or VPN with Conditional Access is used.
Be familiar with the Zero Trust deployment plan: start with identities, then devices, then applications, then data, then infrastructure, then network.
Remember that Zero Trust requires a cultural shift – no implicit trust, continuous validation.
Define Zero Trust Policies
Begin by documenting security requirements: which users, devices, and apps need access. Define policies for identity verification (MFA), device compliance (Intune), and access controls (Conditional Access). For example, require MFA for all admins, block legacy authentication, and require compliant devices for sensitive data. This step establishes the rules engine that will enforce Zero Trust.
Configure Identity Protection
In Azure AD, enable Identity Protection to detect risky users and sign-ins. Configure user risk policies (e.g., block high-risk users) and sign-in risk policies (e.g., require MFA for medium risk). Identity Protection uses machine learning to detect anomalies like leaked credentials, impossible travel, and atypical locations. These risk signals are fed into Conditional Access policies.
Enforce Device Compliance with Intune
Enroll devices into Intune and create compliance policies. For Windows 10/11, require BitLocker encryption, antivirus (Windows Defender), OS version, and firewall. Set a grace period (default 30 days) for non-compliance. Use Conditional Access to block access from non-compliant devices. Device compliance is checked every 8 hours; if a device falls out of compliance, access is revoked.
Implement Conditional Access Policies
Create Conditional Access policies in Azure AD. Each policy has assignments (users, groups, cloud apps, conditions like location or device platform) and access controls (block, grant, or session). Grant controls can require MFA, compliant device, or approved app. Session controls enforce sign-in frequency, app restrictions, or token lifetime. Policies are evaluated in order; the first matching policy applies.
Deploy Microsoft Defender for Cloud Apps
Connect Defender for Cloud Apps to Microsoft 365 and other SaaS apps. Enable anomaly detection and create session policies to monitor user activity. For example, prevent download of high-risk files from unmanaged devices. Use app connectors to control access to third-party apps. Defender for Cloud Apps provides visibility and control over shadow IT and data exfiltration.
In a large enterprise with 10,000 employees, Zero Trust was deployed to secure remote access after the shift to hybrid work. The company used Conditional Access to require MFA for all users, with sign-in frequency of 4 hours. Intune compliance required Windows 10 devices to have BitLocker and Defender AV. Non-compliant devices were blocked from accessing SharePoint and Exchange Online. Defender for Cloud Apps detected an insider threat: an employee downloading thousands of files to a personal OneDrive. A session policy automatically blocked the download and alerted the security team. Performance considerations: Conditional Access adds ~1 second latency per sign-in due to policy evaluation. Misconfiguration can lock out users – for example, a policy that requires a compliant device but no devices are enrolled. Always test policies in report-only mode first. Another scenario: a healthcare organization used Zero Trust to protect patient data. They implemented sensitivity labels via Microsoft Purview to encrypt emails containing PHI. Conditional Access blocked access from non-compliant mobile devices. The challenge was legacy authentication (IMAP, POP) – they had to disable it globally to prevent bypass. Common failure: forgetting to exclude emergency access accounts from lockout policies. Best practice: create break-glass accounts with strong passwords and no MFA, excluded from all Conditional Access policies.
The MS-102 exam tests Zero Trust under objective 3.1: Implement and manage security and compliance solutions. Key sub-objectives include:
3.1.1: Configure Conditional Access policies – know how to create, test, and monitor policies. Exam questions often ask about grant controls vs. session controls. Common wrong answer: confusing 'require MFA' with 'require compliant device'. Remember: MFA is an identity control; device compliance is a device control.
3.1.2: Implement Identity Protection – know user risk and sign-in risk policies. Trap: candidates think Identity Protection blocks access directly – it does not; it provides risk signals to Conditional Access.
3.1.3: Manage Microsoft Intune compliance – know that compliance policies evaluate device health every 8 hours. Wrong answer: compliance is checked at every sign-in (it is not; Conditional Access evaluates compliance state at sign-in, but the compliance check itself is periodic).
3.1.4: Implement Microsoft Defender for Cloud Apps – know session controls and app connectors. Common wrong answer: Defender for Cloud Apps replaces Conditional Access – it does not; it extends control to cloud apps outside Azure AD.
3.1.5: Deploy Microsoft Purview Information Protection – know sensitivity labels and encryption. Exam loves to test that labels can be applied automatically via auto-classification.
Edge cases: What happens if a user is blocked by Conditional Access but has a valid license? The policy still blocks. What if a device is marked compliant but the user's sign-in risk is high? The policy with higher priority (usually the more restrictive) applies. Exam questions often present a scenario with multiple policies; you must determine which policy takes effect. Remember: policies are evaluated in order, but the effective policy is the most restrictive combination of all applicable policies.
Eliminate wrong answers by focusing on mechanism: if the question mentions 'device health', think Intune compliance; if 'user behavior', think Identity Protection; if 'app control', think Defender for Cloud Apps.
Zero Trust has three core principles: verify explicitly, least privilege, assume breach.
Microsoft's Zero Trust has six pillars: Identities, Devices, Applications, Data, Infrastructure, Network.
Conditional Access policies are evaluated at sign-in, not per request.
Default access token lifetime is 60 minutes; refresh token lifetime is 90 days of inactivity.
Intune device compliance is checked every 8 hours; non-compliance can block access.
Identity Protection detects risk but does not block; Conditional Access enforces the block.
Defender for Cloud Apps provides session controls for SaaS apps outside Microsoft 365.
Always test Conditional Access policies in report-only mode before enabling.
Break-glass accounts must be excluded from all Conditional Access policies.
Zero Trust deployment order: identities, devices, applications, data, infrastructure, network.
These come up on the exam all the time. Here's how to tell them apart.
Conditional Access
Enforces access controls like MFA, block, or compliant device.
Evaluates conditions: user, location, device, app, risk.
Policies are assigned to users/groups and cloud apps.
Supports session controls like sign-in frequency.
Works with any Azure AD integrated app.
Identity Protection
Detects risk via machine learning (leaked credentials, impossible travel).
Generates user risk and sign-in risk levels (low, medium, high).
Policies are for risk remediation: block or require password change.
Does not enforce access directly; feeds risk to Conditional Access.
Only works with Azure AD identities, not external apps.
Mistake
Zero Trust means no VPN is needed.
Correct
Zero Trust does not eliminate VPN; it complements it. VPN provides network-level encryption, but Zero Trust adds per-request verification. Many organizations still use VPN for legacy apps.
Mistake
Conditional Access policies are evaluated at every network request.
Correct
Conditional Access policies are evaluated at sign-in, not per packet. Once a token is issued, it is cached for the token lifetime (default 60 min). Subsequent requests within that period do not re-evaluate policies.
Mistake
Device compliance is checked in real time.
Correct
Device compliance is checked every 8 hours by default. If a device becomes non-compliant, it can take up to 8 hours for the compliance state to update. However, Conditional Access can check the last known compliance state at sign-in.
Mistake
Identity Protection policies block users directly.
Correct
Identity Protection detects risk but does not block access. It generates risk events that Conditional Access policies can use. The block action is configured in Conditional Access.
Mistake
Zero Trust is a product you can buy.
Correct
Zero Trust is a security framework, not a product. Microsoft offers tools to implement Zero Trust, but the architecture must be designed and configured.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Conditional Access is the enforcement engine that grants or blocks access based on conditions like user, device, location, and risk. Identity Protection is a risk detection service that identifies compromised accounts and risky sign-ins. Identity Protection generates risk signals (e.g., user risk, sign-in risk) which Conditional Access policies can use as conditions. For example, a Conditional Access policy can require MFA if Identity Protection detects a medium-risk sign-in. In short: Identity Protection detects, Conditional Access enforces.
Use Conditional Access to create a policy that applies to all users and all cloud apps. Under grant controls, select 'Require multi-factor authentication'. Exclude emergency break-glass accounts. Test in report-only mode first. Alternatively, you can enable security defaults in Azure AD, which enforces MFA for all users but offers less customization. For granular control, Conditional Access is preferred.
Access tokens have a default lifetime of 60–90 minutes (varies by workload). Refresh tokens are valid for 90 days if used regularly; after 90 days of inactivity, they expire. These values can be configured via Conditional Access session controls (sign-in frequency) or Azure AD token lifetime policies (deprecated in favor of Conditional Access).
Yes, but device compliance is a key component. Without Intune, you cannot enforce device health checks like encryption or antivirus. However, you can still implement Zero Trust using Conditional Access with other signals like location, risk, and app. For a full Zero Trust implementation, Microsoft recommends Intune for device management.
Session controls allow you to restrict user experience within a session, such as limiting download of sensitive files, requiring sign-in frequency, or enforcing app restrictions. For example, you can set a session policy to prevent users from copying data to unmanaged devices. Session controls are enforced by Microsoft Defender for Cloud Apps for SaaS apps.
Create a Conditional Access policy that blocks access for all users when the client app is 'Exchange ActiveSync clients' or 'Other clients' (legacy). Set the grant control to 'Block access'. This effectively blocks protocols like IMAP, POP, and SMTP. Alternatively, you can disable legacy authentication at the tenant level via Exchange Online settings.
User risk indicates the likelihood that a user's identity is compromised (e.g., leaked credentials). Sign-in risk indicates that a specific sign-in attempt is suspicious (e.g., from an anonymous IP or atypical location). Identity Protection calculates both. Conditional Access can use either as a condition. User risk policies often require password change, while sign-in risk policies require MFA.
You've just covered Zero Trust Implementation in Microsoft 365 — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?