Microsoft Intune has become the default control plane for modern endpoint management in Microsoft 365 environments, largely because it lets you apply consistent controls across Windows, macOS, iOS/iPadOS, and Android without relying on on-premises infrastructure. The operational value is not “cloud MDM” by itself—it’s how you use Microsoft Intune policies to standardize configuration, enforce compliance, and connect device posture to access decisions.
The challenge is that Intune policy is not a single thing. You configure devices using configuration profiles and settings catalogs, secure them using endpoint security policy and security baselines, define pass/fail checks using compliance policies, and then actually enforce outcomes through Conditional Access. If you don’t treat these components as one system, you’ll end up with conflicting settings, unclear ownership, and policies that work in pilot but fail at scale.
This guide is written for IT administrators and system engineers who need a practical policy architecture that holds up across platforms, business units, and evolving security requirements. It focuses on how to design, deploy, and maintain Intune policies so that device management becomes repeatable instead of a constant incident response exercise.
How Intune policy types fit together (and where each one ends)
A reliable Intune design starts with understanding what each policy type is responsible for—and what it isn’t. Many production issues come from expecting one policy category to do the job of another.
Configuration policies (Configuration profiles and Settings catalog) define device settings such as Wi-Fi, VPN, certificates, password rules, browser settings, and OS features. For Windows, this often maps to CSP (Configuration Service Provider) settings and ADMX-backed policies. For Apple platforms, this maps to MDM payloads. Configuration policies are about desired state.
Endpoint security policies are configuration policies packaged by security intent: antivirus, firewall, disk encryption, attack surface reduction, account protection, and security baselines. They often overlap with configuration settings, but you should prefer endpoint security policy for security controls because it’s structured for that purpose, provides clearer reporting, and aligns better with Microsoft’s evolving security stack.
Compliance policies are evaluators. They check whether a device meets criteria (OS version, BitLocker enabled, secure boot, password complexity, jailbreak/root status, threat level via Microsoft Defender for Endpoint integration). Compliance policies generally do not fix the device—they mark it compliant or noncompliant.
Conditional Access (in Microsoft Entra ID) is the enforcement engine. Compliance is only impactful when you connect it to access decisions. Conditional Access can require a compliant device, require an approved app, or block legacy authentication. Intune policy builds the posture; Conditional Access uses that posture to make access decisions.
App protection policies (MAM) protect corporate data inside apps (e.g., Outlook, Teams, OneDrive) even when the device is not enrolled. This matters for BYOD and for edge cases where device enrollment is not feasible. App protection is not a replacement for device compliance—it’s a different control plane focused on data handling.
A coherent operational model is: configuration and endpoint security define intended settings, compliance evaluates state, Conditional Access enforces access, and app protection reduces risk where enrollment is not present.
Prerequisites and planning: tenants, identities, licensing, and device authority
Before you build policies, validate the foundations that determine whether devices can receive them and whether users can enroll without friction.
Start with identity and directory design. Intune is tightly integrated with Microsoft Entra ID (formerly Azure AD). Every managed device is registered in Entra ID, and management actions are scoped through that identity. If you have multiple tenants, decide whether you’re centralizing management or allowing regional autonomy. Cross-tenant scenarios are possible but add complexity; it’s usually best to standardize on a single management tenant unless regulatory constraints require separation.
Licensing determines which controls you can actually use. Many core MDM features are available with Intune Plan 1, while advanced capabilities such as Endpoint Privilege Management, some advanced analytics, and deeper security integrations may require Intune Suite or adjacent licensing. Conditional Access is an Entra ID feature (commonly Entra ID P1/P2 depending on requirements). Make sure your policy design aligns with what your licenses can enforce.
Next, confirm device authority and enrollment methods by platform:
For Windows, you typically choose between Azure AD joined, Hybrid Azure AD joined (less recommended for new builds), or Azure AD registered (BYOD). Windows Autopilot is the standard for corporate provisioning. Your enrollment strategy determines whether policies apply at device setup time.
For iOS/iPadOS and macOS, decide whether you will use Apple Business Manager (ABM) for Automated Device Enrollment (ADE). For macOS, also decide whether you’ll leverage declarative device management capabilities where applicable and how you’ll handle local admin rights.
For Android, Android Enterprise is the modern standard. Decide whether you will support Fully Managed, Corporate-Owned Work Profile (COPE), or Work Profile on personal devices. Each mode has different policy reach.
Finally, ensure role-based access control (RBAC) and administrative boundaries are defined early. Intune allows custom roles and scope tags; if you skip this, your policy management will turn into shared-global admin behavior and become hard to audit.
Designing an Intune policy architecture that scales
A scalable approach to Microsoft Intune policies starts with separation of concerns. You want policies that are small enough to reason about, but not so granular that you create thousands of objects with unclear precedence.
A practical architecture usually includes:
1) A global baseline layer that applies to almost all corporate-managed devices (security baseline settings, minimum OS versions, password/lock requirements, disk encryption requirements).
2) A platform layer (Windows, macOS, iOS/iPadOS, Android) that covers platform-specific security and configuration essentials.
3) A persona or use-case layer (kiosk, shared devices, developers, executives, frontline, VDI endpoints) with settings tailored to job function.
4) An application enablement layer for Wi-Fi, VPN, certificates, and SSO components required for business apps.
The key is that each layer should have a clear ownership model and a clear rule: if two policies could configure the same setting, you should know which one is authoritative.
Naming conventions and documentation that prevent policy sprawl
Policy sprawl isn’t just “too many policies”; it’s too many policies with no way to understand why they exist. Use a naming convention that encodes platform, intent, scope, and ring.
A workable pattern looks like:
[Platform]-[Type]-[Intent]-[Scope]-[Ring]
Examples:
WIN-SECBASE-MicrosoftSecurityBaseline-AllCorp-Ring1WIN-CONFIG-BitLockerSettings-AllCorp-Ring1IOS-CONFIG-WiFi-CorpSSID-AllCorp-ProdANDR-COMPLIANCE-Standard-COPE-Prod
Keep a short internal design record that maps which settings live where. You don’t need heavyweight documentation, but you do need enough to avoid duplicate controls and silent conflicts.
Assignment strategy: groups, filters, and rings
Assignments are where good designs fail. If you assign policies directly to broad groups without segmentation, you can’t test changes safely.
Use deployment rings: pilot, early adopter, broad production. For Windows, rings often align with update rings and feature update policies, but you can also use them for configuration and security changes.
Prefer dynamic device groups or filters when you need precise targeting. Filters are particularly useful because they can reduce group explosion; for example, you can assign a policy to “All Windows devices” and filter to only “Windows 11” or “Corporate-owned.”
A simple ring approach:
- Ring 0: IT and test devices
- Ring 1: early adopters (5–10%)
- Ring 2: broad production (remaining)
For each ring, ensure you can identify membership deterministically (device attributes, Autopilot group tags, enrollment profile, or a dedicated group).
Configuration profiles and the Settings catalog on Windows
Windows policy in Intune has evolved significantly. The Settings catalog is now the default approach for many settings because it provides a searchable, categorized experience and avoids the guesswork of custom OMA-URI for many common scenarios.
When you design Windows configuration policies, start by deciding whether the setting belongs in:
- Endpoint security policy (if it’s a security control like BitLocker, firewall, Defender, ASR)
- Security baselines (if you want Microsoft’s curated defaults)
- Settings catalog (if it’s general configuration or a specific Windows policy setting)
- Administrative Templates (ADMX-backed settings, still relevant for many GPO-like controls)
- Custom OMA-URI (only when needed)
This ordering helps reduce conflicts and gives you better reporting.
Example scenario 1: Migrating from Group Policy to Intune without breaking users
Consider a mid-sized organization moving from on-prem Group Policy to Intune-managed Windows 11. Their most common failure mode is attempting a “lift and shift” of every GPO into Intune. That often causes broken VPN, duplicate certificate deployment, and inconsistent browser controls.
A safer approach is to migrate by intent:
First, establish a Windows security baseline (or Microsoft-recommended endpoint security policies) in Ring 0 and Ring 1. This sets the minimum security posture.
Next, migrate enablement policies: Wi-Fi, VPN, certificates, proxy settings, and line-of-business dependencies. These should be validated with actual user workflows.
Finally, migrate UX and productivity controls (Start menu layout, default app associations, OneDrive known folder move, Edge settings). Those are usually less security-critical but can generate a high support volume if done abruptly.
The key insight is that “security posture” and “user workflow enablement” must move together. A BitLocker requirement, for example, is meaningless if the device can’t access the corporate network or authenticate to required services.
Where custom OMA-URI still matters
Custom OMA-URI policies configure CSP settings directly. They are still useful for edge cases, but they require precise knowledge of the CSP path, data type, and supported Windows versions. Use them when the Settings catalog and templates don’t expose the control you need.
If you must use OMA-URI, document:
- CSP path and supported OS versions
- Data type (String/Integer/Boolean)
- Expected impact and rollback plan
Keep custom policies isolated and scoped narrowly to reduce blast radius.
Endpoint security policies: treat security as a first-class policy domain
Endpoint security policies in Intune are designed to centralize security controls rather than scattering them across configuration profiles. This matters operationally because security teams often need different permissions, reporting, and change cadence than EUC (end-user computing) teams.
A common, effective pattern is:
- Use security baselines to get to “reasonable defaults” quickly.
- Use endpoint security policies to tailor to your environment and meet specific requirements.
- Use compliance policies to validate critical security conditions.
- Use Conditional Access to require compliance for cloud app access.
Disk encryption with BitLocker (Windows)
For Windows, BitLocker is typically enforced through Endpoint security > Disk encryption. Decide early whether you will escrow recovery keys to Entra ID (common for cloud-managed) and whether you need additional escrow to on-prem AD DS (hybrid environments).
Also decide your operational model for recovery: helpdesk access, auditing, and whether users can self-recover through a portal. The policy is not just “turn on BitLocker”; it’s also how you handle key lifecycle.
Firewall, Defender, and attack surface reduction
Defender Antivirus and firewall settings should be aligned with your security monitoring. If you use Microsoft Defender for Endpoint (MDE), integrate Intune and MDE so that device risk signals can contribute to compliance and Conditional Access.
Attack Surface Reduction (ASR) rules are powerful but can disrupt workflows if deployed aggressively without ring-based testing. Treat ASR like application compatibility: validate with real workloads, especially for developer tools, macros, and automation scripts.
Compliance policies: define what “good” looks like and make it measurable
Compliance policies are frequently misunderstood as “enforcement.” In reality, compliance policies measure device state and return a compliance result. Remediation depends on configuration policies and endpoint security policies, while enforcement depends on Conditional Access.
A compliance design should focus on a small set of high-signal checks:
- Minimum OS version (and potentially maximum, if you need to block outdated builds)
- Require encryption (BitLocker/FileVault where supported)
- Require a password/biometric and a maximum inactivity lock time
- Block jailbroken/rooted devices on mobile platforms
- Optionally incorporate device risk from MDE
Avoid making compliance a catch-all for every preference. If your compliance policy is too strict or too broad, you will create user lockouts and exceptions that erode trust in the system.
Grace periods and user notifications
Where possible, use grace periods so users can remediate before losing access. Pair this with clear user messaging. Intune can show noncompliance reasons in Company Portal; your policy choices should make those reasons actionable.
For example, “OS version below minimum” is actionable if the device can update. “Device not compliant” without details leads to tickets.
Conditional Access: turn compliance into real enforcement
Conditional Access (CA) is where Intune posture becomes meaningful. Without CA, a noncompliant device can still authenticate, and compliance becomes just a dashboard metric.
Your CA design should align with identity security basics:
- Require modern authentication.
- Block legacy authentication.
- Require MFA based on risk and sensitivity.
- Require compliant device (or approved client apps) for key cloud services.
A typical baseline CA pattern is to require a compliant device for Microsoft 365 apps (Exchange Online, SharePoint/OneDrive, Teams) while allowing limited access from unmanaged devices via web-only restrictions if needed.
Example scenario 2: BYOD smartphones with app protection instead of enrollment
A common real-world case is a professional services firm with high BYOD adoption. Users refuse full device enrollment, but the business still needs to protect email and files.
In this model, you apply app protection policies to Microsoft 365 mobile apps. You require:
- PIN or biometric to access corporate data in managed apps
- Encryption of app data
- Restrict “Save As” to personal locations
- Block copy/paste from corporate to personal apps (or allow with restrictions)
- Wipe corporate app data on sign-out or after a compliance trigger
Then you use Conditional Access to require an approved app (Microsoft apps with Intune app protection) for Exchange Online and SharePoint on mobile. This approach does not manage the entire device, but it materially reduces data leakage risk.
The transition from “we can’t manage BYOD” to “we can protect corporate data in BYOD apps” is often the difference between an unenforceable policy statement and an operational control.
Apple platform policy design: macOS and iOS/iPadOS without surprises
Apple management has unique constraints because many settings require user approval, supervision, or specific enrollment types. The biggest practical mistake is assuming macOS/iOS behave like Windows GPO.
Start by standardizing enrollment through Apple Business Manager where possible. Supervised devices (iOS/iPadOS) and ADE-enrolled Macs give you broader control and fewer user prompts.
macOS configuration and security policy approach
On macOS, you’ll likely manage:
- FileVault (disk encryption)
- Firewall settings and privacy controls
- SSO extensions and configuration profiles for identity
- PPPC (Privacy Preferences Policy Control) profiles for app permissions
- Kernel/system extensions approvals (where still relevant)
Be cautious with PPPC. PPPC profiles are deterministic and can solve repeated prompts for approved apps, but they require accurate bundle IDs and services. Treat PPPC like application packaging: validate with the exact app version and deployment method.
iOS/iPadOS: supervision, app modes, and data boundaries
For iOS/iPadOS, choose whether you’re supporting:
- Corporate-owned devices enrolled through ADE (recommended for corporate devices)
- User enrollment for BYOD (where supported and appropriate)
- App protection without enrollment (for lightweight BYOD)
If you manage corporate iPhones, you can apply restrictions that are impossible or inappropriate on BYOD, such as blocking iCloud backup for managed data or enforcing supervised-only controls.
Android Enterprise policy design: match policy to enrollment mode
Android Enterprise is not one “Android enrollment.” Policies that work for Fully Managed may not apply in Work Profile mode.
Define which modes you support:
- Fully Managed: corporate-owned devices with full control.
- COPE: corporate-owned with a work profile separating corporate and personal.
- Work Profile (BYOD): personal device with a managed work profile.
Your configuration and compliance policies should be separated by enrollment mode to avoid confusion. For example, you might require a stronger password for Fully Managed devices but allow biometrics with a shorter timeout for Work Profile.
Android also benefits from application configuration policies (managed configurations) for apps like Teams, Outlook, and vendor-specific line-of-business apps. Use these to preconfigure accounts, disable unmanaged storage, or set server endpoints.
Autopilot and automated enrollment: policies that land at the right time
For Windows corporate provisioning, Windows Autopilot determines how reliably your policies apply during the first user experience. If you apply security controls too late, users may start working on a partially configured device. If you apply too much too early, setup becomes slow and fragile.
A practical approach is to separate:
- Enrollment Status Page (ESP) blocking apps/settings: only what’s required for secure, functional first sign-in.
- Post-enrollment policies: everything else.
This often means ensuring that:
- Device compliance prerequisites (encryption requirements, Defender onboarding) are configured early.
- Network access (Wi-Fi/VPN profiles) is available during setup if needed.
- Critical apps (Company Portal if required, security agents, VPN client) install during ESP.
Example scenario 3: Zero-touch Windows deployment for a distributed workforce
Imagine a retail company with no local IT at branch sites. They ship laptops directly to employees. The primary operational risk is that a user signs in and starts working before security controls apply.
They implement Autopilot with a user-driven Azure AD join profile and configure ESP to block until:
- Defender for Endpoint is onboarded
- BitLocker encryption is enabled and recovery key is escrowed
- VPN client is installed (for access to legacy on-prem apps)
- Required productivity suite is installed
The result is not just convenience; it’s consistent posture. Helpdesk tickets drop because devices converge to a known-good state within the first hour, not over several days of background installs.
Update management policies: make OS currency part of compliance
Patch posture is one of the strongest predictors of compromise risk. Intune provides Windows Update for Business policies (update rings, feature update policies, quality update policies, driver update management in some scenarios) and equivalent update controls on other platforms.
Treat updates as part of your policy system, not a separate project. Your compliance policies should set a minimum OS version aligned to your update deployment schedule.
For Windows, a typical pattern is:
- Ring 0: IT validation (fast)
- Ring 1: early adopters
- Ring 2: broad production (slower)
Then align the compliance minimum OS version with your expected rollout. Don’t set compliance minimums tighter than your update rings can deliver, or you will create noncompliance without a path to remediation.
Using PowerShell to inventory Windows build versions (for planning)
In hybrid environments or during migration, you may want to inventory build versions from existing devices to set realistic compliance thresholds. For example:
Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion |
Select-Object Name, OperatingSystem, OperatingSystemVersion |
Export-Csv .\ad-os-inventory.csv -NoTypeInformation
This doesn’t configure Intune, but it helps you avoid defining a minimum OS version that half the fleet cannot meet without hardware refresh.
Certificates, Wi-Fi, and VPN: the policies that make everything else usable
Security posture means little if devices can’t connect securely. Certificate deployment, Wi-Fi profiles, and VPN configuration are the “plumbing” policies that determine whether endpoints can reach business services.
For certificates, you commonly choose between:
- SCEP/PKCS via Intune Certificate Connector (for on-prem CA integration)
- Third-party certificate services
- Imported certificates for smaller environments (less scalable)
Design certificate policies with lifecycle in mind: renewal intervals, revocation, and what happens during device reprovisioning. Also consider how certificate identity maps to network controls (802.1X Wi-Fi, VPN auth, mutual TLS apps).
For VPN, Intune supports built-in VPN profiles for common vendors and custom profiles where needed. Validate split tunneling, always-on behavior, and DNS settings in your ring rollout; small DNS mistakes can look like “Intune policy failure” but are actually name resolution problems.
App deployment and policy interactions: keep installs predictable
Applications and policies interact in subtle ways. For example, an endpoint security policy might block a driver required by a VPN client, or an ASR rule might block a script used by an installer.
Treat application onboarding as part of your policy change process:
- Identify security controls that could affect installation (ASR, SmartScreen, firewall rules).
- Validate in Ring 0 with the same policies as production.
- Decide whether an app is required, available, or uninstall (where applicable).
Use dependency mapping sparingly but intentionally. For mission-critical apps, it’s worth ensuring prerequisites are present before installation.
Policy conflict management: reduce overlapping settings by design
Intune policy conflict resolution varies by platform and setting type. On Windows, some settings behave as “last writer wins,” while others may result in a conflict state. On Apple platforms, conflicting payloads can lead to undefined behavior or ignored settings.
The practical way to manage this is not to memorize every conflict rule—it’s to prevent conflicts:
- Prefer endpoint security policies for security settings.
- Avoid configuring the same setting in multiple places (e.g., Defender settings in both settings catalog and endpoint security).
- Keep baselines close to default unless you have a reason to diverge.
- Use ring-based testing before broad rollout.
When you need exceptions, avoid “one-off” policies assigned to individuals. Instead, model exceptions as a controlled persona group (e.g., WIN-EXCEPTION-Developers) with explicit approval and periodic review.
Operationalizing change: versioning, validation, and rollout control
At scale, Intune policy work is change management. The platform is straightforward; the complexity is human.
Adopt an operational rhythm:
- Build or modify policies in Ring 0 first.
- Allow enough time for policy evaluation and device check-in.
- Validate using device-side evidence (settings on device, event logs where relevant) and Intune reporting.
- Expand to Ring 1, then Ring 2.
Where possible, treat policy edits like code changes: track what changed, why it changed, and who approved it. Many organizations use a lightweight ticketing workflow plus structured naming and tags.
Using Microsoft Graph to export policy configurations (for change tracking)
If you need repeatable exports for audit/change tracking, Microsoft Graph can retrieve policy objects. The exact endpoints vary by policy type, but the pattern is consistent: authenticate, query, and export JSON.
Below is a conceptual PowerShell pattern using Microsoft Graph PowerShell SDK (you should scope permissions appropriately and adapt endpoints to your policy types):
powershell
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
# Example: list device configuration profiles
$profiles = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations"
$profiles.value | Select-Object id, displayName, '@odata.type' | Format-Table
# Export a specific profile JSON
$profileId = "00000000-0000-0000-0000-000000000000"
$profile = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations/$profileId"
$profile | ConvertTo-Json -Depth 50 | Out-File ".\intune-profile-$profileId.json" -Encoding utf8
Use this approach to create a point-in-time snapshot before and after significant changes. Even if you don’t automate full CI/CD for Intune, a basic export habit improves rollback confidence.
Reporting and monitoring: verify outcomes, not just assignments
Assignments tell you what you intended to apply; reporting tells you what actually happened.
For configuration policies, validate on multiple levels:
- Policy assignment success/failure in Intune
- Per-setting reporting (where available)
- Device-side state (especially for security settings)
For compliance, focus on:
- Noncompliance reasons (do they map to actionable remediation?)
- Trends by platform and OS version
- Exception volumes and whether they are justified
For Conditional Access, monitor sign-in logs in Entra ID:
- Are users being blocked for expected reasons?
- Are there unexpected blocks tied to compliance or device platform?
- Are legacy auth attempts being blocked (and are they legitimate business flows that need modernization)?
This monitoring closes the loop between policy intent and user impact.
RBAC and scope tags: delegating Intune safely
Intune often starts with a small team and then grows. Without RBAC, growth becomes risky because too many people can change global policy.
Use RBAC to separate duties:
- Endpoint engineering team manages configuration and app deployment.
- Security team manages endpoint security policies and baseline alignment.
- Helpdesk has limited actions (remote wipe, sync, rotate BitLocker keys access depending on your model).
Scope tags help when you need administrative separation by region, subsidiary, or business unit. The important detail is to align scope tags with group targeting; otherwise, admins may see objects they can’t effectively manage.
Putting it all together: a reference policy blueprint
Once you understand the building blocks—configuration, security, compliance, enforcement—you can define a blueprint that’s easy to replicate.
A practical blueprint for a mixed environment might look like this:
Windows 11 corporate devices
Start with:
- Autopilot profile(s) by persona
- Enrollment Status Page settings
- Endpoint security: BitLocker, Defender, firewall, ASR (ring-based)
- Security baseline (if used) with minimal deviations
- Settings catalog for OS configuration (Edge, OneDrive, UX controls)
- Compliance policy: encryption, minimum OS, password, MDE risk (if integrated)
- Conditional Access: require compliant device for Microsoft 365; require MFA; block legacy auth
Then add enablement:
- SCEP/PKCS certificates if needed
- Wi-Fi 802.1X profile and/or VPN profile
- Required apps
macOS corporate devices
Start with:
- ADE enrollment via ABM
- FileVault policy and key escrow approach
- Configuration profiles for SSO and Wi-Fi/VPN
- PPPC profiles for approved security and productivity apps
- Compliance policy aligned with OS update posture
- Conditional Access requirements aligned with corporate risk tolerance
Mobile (iOS/Android) corporate and BYOD
For corporate-owned:
- ADE (iOS) or Fully Managed/COPE (Android)
- Device restrictions, passcode policies
- Compliance and Conditional Access requiring compliant devices
For BYOD:
- App protection policies for Microsoft 365 apps
- Conditional Access requiring approved apps and/or app protection
This blueprint is intentionally layered. It allows you to harden endpoints without making enrollment brittle and gives you clear levers for exceptions.
A final operational note: policy outcomes depend on lifecycle discipline
Intune policy success is less about individual settings and more about disciplined lifecycle management. Devices age, OS versions change, vendor defaults shift, and security guidance evolves. If your policies aren’t periodically reviewed, you will accumulate outdated baselines, conflicting controls, and compliance checks that no longer map to real risk.
Build a recurring cadence—monthly or quarterly—to review:
- Which policies have exceptions and why
- Whether security baselines need revision
- Whether compliance minimums still align with update rings
- Whether app protection policies match how users actually work
That cadence turns Microsoft Intune policies from a one-time project into a sustainable endpoint management system.