Zero Trust deployment approach with Microsoft Intune

Microsoft Intune is a mobile device management solution that supports your organization's Zero Trust journey.

Zero Trust isn't a product or service. Instead, it's a modern cybersecurity strategy that assumes no implicit trust, not even within the corporate network. Instead of trusting users, devices, or applications by default, a Zero Trust approach explicitly verifies every access request, continuously assesses risk, and enforces least privilege access across the entire digital estate.

Core principles of Zero Trust include:

Why manage endpoints for Zero Trust?

The modern enterprise has incredible diversity in endpoints accessing organizational data. Users work from anywhere, from any device, more than at any time in history. This creates a massive attack surface, and endpoints can easily become the weakest link in your Zero Trust security strategy.

While organizations are typically proactive in protecting PCs from vulnerabilities and attacks, mobile devices often go unmonitored and without protections. Gaining visibility into endpoints that access your corporate resources is the first step in your Zero Trust device strategy.

To avoid exposing your data to risk, you need to monitor every endpoint for risks and employ granular access controls to deliver the appropriate level of access based on organizational policy. For example, if a personal device is jailbroken, you can block its access to prevent enterprise applications from being exposed to known vulnerabilities.

For an overview of how Intune supports Zero Trust principles (verify explicitly, use least privilege access, and assume breach), see Zero Trust with Microsoft Intune.

Seven-layer Zero Trust deployment progression

Building a comprehensive Zero Trust security posture for devices involves progressively implementing layers of protection. Each layer builds on the previous one, starting with basic data protection and advancing to sophisticated threat detection and data loss prevention.

The following table shows recommended deployment progression for Zero Trust device security:

Understanding the seven deployment layers

This section explains each layer in the Zero Trust deployment progression. While the seven-layer table shows what each layer accomplishes, these descriptions provide context, examples, and clarification of key concepts.

App protection without enrollment (Layer 1)

App protection policies protect organizational data within apps, controlling how users access and share work data. Layer 1 focuses on protecting data on unmanaged personal devices without requiring enrollment, but app protection policies can also be applied to enrolled devices for defense-in-depth.

Users install apps like Outlook or Teams from the store, sign in with their work account, and data protection policies automatically apply. This approach is commonly called MAM without enrollment or bring-your-own-device (BYOD).

Example: A user's personal iPhone has Outlook installed. Your app protection policy requires a PIN to access work email, prevents copying work data to personal apps, and blocks saving email attachments to personal cloud storage. The user maintains full control of their device while organizational data stays protected.

For details, see Deployment guidance: App protection policies.

Device enrollment (Layer 2)

Enrollment registers devices with Intune, enabling comprehensive device management. Intune deploys apps, configures settings, enforces compliance policies, and provides complete visibility into the device state.

Example: A corporate laptop enrolls in Intune during Windows Autopilot setup. Intune configures Wi-Fi, deploys certificates, installs security baselines, enforces BitLocker encryption, and monitors compliance with your password policy.

For details, see Deployment guidance: Enroll devices.

Compliance policies (Layer 3)

Compliance policies define security requirements that devices must meet to access organizational resources. These policies evaluate device health and mark devices as compliant or noncompliant based on settings you configure, such as password requirements, OS versions, encryption status, and jailbreak detection.

Example: Your compliance policy requires Windows devices to have BitLocker enabled, run a minimum OS version, and use a password with at least eight characters. A user's laptop missing BitLocker is marked noncompliant. The user receives notifications about the requirement and has time to remediate before access is blocked (if you enforce layer 4).

For details, see Deployment guidance: Compliance policies.

Require healthy and compliant devices (Layer 4)

This layer implements enterprise-level Zero Trust identity and device access policies by requiring devices to be healthy and compliant before granting access to organizational resources. You work with your identity team to create Conditional Access policies in Microsoft Entra ID that enforce the compliance decisions from layer 3.

This layer represents the shift from assessment to enforcement. After compliance policies mark devices as compliant or noncompliant, Conditional Access policies use that signal to grant or block access to email, SharePoint, Teams, and other protected resources.

Example: Your identity team configures a Conditional Access policy that requires devices to be marked as compliant before users can access Microsoft 365 apps. A user attempts to access Outlook from a Windows device that is managed by Intune. The device is noncompliant because it doesn't meet an Intune compliance requirement, disk encryption (BitLocker) isn't enabled. Because the device isn't marked as compliant, Conditional Access blocks access to Outlook and prompts the user to resolve the issue. After the user enables BitLocker, the device reports its updated compliance state to Intune. Once the device is evaluated as compliant, Conditional Access reevaluates the sign-in and access to Outlook is restored.

For details, see Require managed devices with Conditional Access.

Configuration profiles (Layer 5)

Configuration profiles configure device settings to harden security, enable features, and create consistent configurations across your fleet. While compliance policies (layer 3) assess whether devices meet requirements, configuration profiles proactively deploy settings to ensure devices are configured correctly.

You can deploy settings through device configuration profiles or endpoint security policies. Device configuration profiles support broad scenarios including Wi-Fi and VPN profiles, certificate deployment, password policies, disk encryption settings, and Group Policy equivalents. Endpoint security policies provide streamlined experiences focused specifically on security settings like antivirus, disk encryption, firewall, attack surface reduction, and endpoint detection and response.

Example: You deploy a Windows security baseline to corporate laptops. The baseline enables Windows Firewall, configures BitLocker encryption, disables legacy protocols, enables attack surface reduction rules, and configures dozens of other security settings. Users don't need to configure any of these settings manually—Intune applies them automatically.

For details, see Deploy configuration profiles.

Device risk monitoring (Layer 6)

Device risk monitoring integrates Microsoft Defender for Endpoint with Intune to add continuous threat detection, device risk assessment, and risk-based access controls. This layer shifts from static compliance checks to dynamic security monitoring that responds to active threats in real time.

When you onboard devices to Microsoft Defender for Endpoint, they begin reporting security telemetry and threat intelligence. Defender assigns each device a risk level (secured, low, medium, high, or unavailable) based on detected threats, vulnerabilities, and security posture. You can use this risk level in compliance policies to block access from high-risk devices or trigger remediation actions.

Example: A user's laptop becomes infected with malware. Microsoft Defender for Endpoint detects the threat and marks the device as high risk. Your compliance policy evaluating device risk immediately marks the device as noncompliant. Conditional Access blocks the user's access to organizational resources until the threat is remediated and the device risk returns to an acceptable level.

For details, see Microsoft Defender for Endpoint integration.

Endpoint data loss prevention (Layer 7)

Endpoint data loss prevention uses Microsoft Purview to prevent sensitive data from leaving managed endpoints through copy, print, upload, or transfer operations. While earlier layers protect access to resources, this layer protects the data itself by monitoring and controlling how users interact with sensitive files.

Devices onboarded to Microsoft Defender for Endpoint in layer 6 are automatically onboarded for Endpoint DLP with no additional Intune configuration. Your compliance team creates DLP policies in the Microsoft Purview portal defining which sensitivity labels, file types, or content patterns trigger protective actions.

Example: Your compliance team creates a DLP policy preventing files labeled "Confidential" from being copied to USB drives or uploaded to personal cloud storage. A user attempts to copy a confidential financial report to a USB drive. Endpoint DLP blocks the operation and displays a notification explaining the restriction. Depending on how the compliance team configured the policy, the block might be absolute or allow the user to provide a business justification and proceed. All activities are logged for compliance reporting.

For details, see Learn about Endpoint DLP and Get started with Endpoint DLP.

Enrollment vs. onboarding

As you implement these layers, you'll work with two related but different concepts: enrollment and onboarding. Understanding the difference helps clarify what happens at each layer.

Enrollment (Layer 2) registers devices with Intune for comprehensive device management. Onboarding (Layers 6-7) configures devices to report information to specific services like Microsoft Defender for Endpoint or Microsoft Purview.

Coordinating with Microsoft 365 teams

Implementing Zero Trust device security requires coordination across multiple teams in your organization. While you manage Intune policies, other teams manage complementary services that work together to enforce protection.

Identity team (Microsoft Entra ID)

Their responsibility: Manage Conditional Access policies, configure authentication requirements, and administer the Microsoft Entra ID tenant.

Your coordination:

• After you create app protection policies (layer 1), work with identity team to create Conditional Access policy requiring approved apps.
• After creating compliance policies (layer 3), coordinate Conditional Access policy requiring compliant devices:
  1. You create and assign compliance policies in Intune to define device requirements.
  2. Identity team creates Conditional Access policy in Microsoft Entra admin center.
  3. Conditional Access policy uses "Require device to be marked as compliant" grant control.
  4. Ensure both policies target the same user groups.
  5. Test together using the Conditional Access What If tool before enabling enforcement.
• For detailed workflow, see Common ways to use Conditional Access.
• For policy creation, see Require managed devices with Conditional Access.

Related guidance: Conditional Access with Intune

Threat protection team (Microsoft Defender)

Their responsibility: Set up and manage Microsoft Defender for Endpoint service, investigate threats, and manage security operations center (SOC) workflows.

Your coordination:

• Use Intune to onboard devices to Microsoft Defender for Endpoint (layer 6)
• Deploy both Windows security baseline and Defender for Endpoint security baseline to managed devices
• Receive device risk signals from Defender that feed into compliance policies
• Act on Intune security tasks that are created by Defender security admins for remediating discovered vulnerabilities and misconfigurations
• Coordinate incident response when threats are detected on managed devices

Related guidance:

• Microsoft Defender for Endpoint integration
• Remediate vulnerabilities with security tasks

Data security and privacy team (Microsoft Purview)

Their responsibility: Define data sensitivity schema, create DLP policies, and manage compliance requirements in Microsoft Purview.

Your coordination:

• Ensure devices are onboarded to support Endpoint DLP (automatic with MDE onboarding in layer 6)
• Identify which user groups should be included/excluded from DLP policies
• Verify device visibility in Microsoft Purview portal
• Support user education when DLP policies block or warn about data operations

Related guidance:

• Learn about Endpoint DLP
• Get started with Endpoint DLP

Best practices for cross-team coordination

• Establish regular coordination meetings during initial deployment of each layer.
• Document ownership - Be clear about which team manages which policies.
• Test together - Use audit mode and What If tools before enforcement.
• Align on user groups - Ensure consistent group assignments across services.
• Plan communications - Coordinate user notifications when policies might impact user experience.
• Share monitoring responsibilities - Each team monitors their service, but share insights about user impact.

Next steps

Get started with Zero Trust device security:

• Deployment guidance: App protection policies - Layer 1
• Deployment guidance: Enroll devices - Layer 2
• Deployment guidance: Compliance policies - Layer 3
• Require managed devices with Conditional Access - Layer 4

Learn more about Zero Trust:

• Zero Trust Guidance Center - Enterprise-scale strategy and architecture
• Secure endpoints with Zero Trust - Device-centric deployment objectives
• Zero Trust deployment plan with Microsoft 365 - Cross-service deployment guidance

Explore advanced protection layers:

• Deploy configuration profiles - Layer 5
• Microsoft Defender for Endpoint integration - Layer 6
• Learn about Endpoint DLP - Layer 7