The Intune Hardening Checklist: 16 Controls From Enrollment Gate to Final Wipe
TL;DR
- By default Intune enrolls any device, personal or corporate, and keeps stale devices forever; enrollment restrictions and cleanup rules are the first two settings to change in every tenant.
- Compliance policies do nothing to attackers until a Conditional Access policy blocks noncompliant devices, which requires at least Azure AD P1 licensing.
- Requiring MFA at Intune enrollment stops unauthorized users from joining devices to your network, and a Temporary Access Pass covers first-time users with no MFA methods registered.
- Push disk encryption through configuration profiles before enforcing compliance policies that require it, so encryption configures silently instead of prompting users.
- App protection policies secure corporate data on iOS and Android without enrolling the device, which makes them the BYOD control most environments are missing.
Think of a managed device as having a lifecycle: it asks to enroll, proves it is healthy, gets hardened and patched, runs approved apps, and eventually leaves. A defensible Intune baseline puts a control at every stage, and that is how the 16 controls below are organized. These are recommendations, not absolutes; unique constraints will rule some out in some environments, so evaluate and test each one before broad deployment. Every control here is mapped to the CIS Controls, and the same treatment exists for the rest of the Microsoft suite (Azure AD, Teams, Exchange, SharePoint, OneDrive) in the full CIS-mapped hardening guide.

The matrix as a spreadsheet: Intune Baselines v1.xlsx (opens in new tab)
Stage 1: Who and what gets in the door?
1. Block personal devices at enrollment
By default, any device can enroll into Intune whether it is corporate or personal. Configure device restrictions so users cannot accidentally enroll personal hardware, and only the device types your organization actually supports (Windows, Linux, macOS, and so on) can enroll at all.
Policy
- Device restrictions are configured to block personal devices from enrolling in the MDM solution
- Only corporation-defined device types are supported for Intune enrollment
Licensing: any tenant with Intune licensing.
Setup
Docs: Overview of enrollment restrictions (opens in new tab) and Create device platform restrictions (opens in new tab).
- Follow the steps in Create device platform restrictions (opens in new tab)
- Under Personally-Owned, select Block for each device type

End-user impact: Medium. Users cannot enroll any device classified as personal. With Windows auto-enrollment enabled, users are prompted to enroll when opening common Office apps like Teams; if they accept on a personally owned device, the enrollment is blocked.
PowerShell: Enrollment restriction samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Video: Setting up enrollment restrictions and device settings (opens in new tab)
CIS mapping

2. Require MFA to enroll a device
Intune plus Azure AD Conditional Access can require multifactor authentication during device enrollment, so anyone enrolling a device must first authenticate with a second device and two forms of credentials. Unauthorized users should not be joining devices to your network.
Policy: MFA is required to enroll devices into Intune.
Licensing: requires at least Azure AD P1, standalone or via EMS+E3/E5, Microsoft 365 Business Premium, Microsoft 365 E3, or Microsoft 365 E5.
Setup
Require multifactor authentication for Intune device enrollment (opens in new tab)
End-user impact: Medium. Users must satisfy the MFA prompt to enroll. For brand-new users with no MFA methods registered yet, issue a Temporary Access Pass (opens in new tab) so they can enroll passwordless methods on first sign-in.

Tip: the Temporary Access Pass approach above is the answer to nearly every "new hire cannot enroll" ticket this control generates.
PowerShell: Conditional Access API samples from Azure-Samples (opens in new tab)
Video: Enabling MFA when joining a device to Azure AD (opens in new tab)
CIS mapping

3. Hold new devices until required apps install
When a user first onboards to a new device, required applications such as AV or endpoint protection should finish installing before the user starts working. The enrollment status page handles this for Windows devices during first sign-in, which pairs naturally with Windows Autopilot provisioning.
Policy: device use is restricted until required applications are installed.
Licensing: any tenant with Intune licensing.
Setup
Set up the Enrollment Status Page (opens in new tab) and Selecting required apps for your Enrollment Status Page (opens in new tab)

End-user impact: Medium. Varies with the apps involved; users may wait while installs finish. Define the minimum set of blocking applications rather than the full install list, so onboarding does not stall on nice-to-haves.
PowerShell: none currently.
Videos: Enrollment Status Page, what it is and what it isn't (opens in new tab), Decode the Windows Enrollment Status Page (opens in new tab), Set up the Enrollment Status Page (opens in new tab)
CIS mapping

Stage 2: Can the device prove it is healthy?
4. Define a compliance policy for every supported platform
Device compliance policies define the settings a platform must meet to satisfy corporate requirements, and they are the raw material Conditional Access uses in the next control. Devices should be continuously monitored against them.
Policy
- A device compliance policy exists for each platform the corporation supports
- Devices that miss the standard are marked noncompliant immediately
Licensing: any tenant with Intune licensing.
Setup
Overview: Device compliance policies in Microsoft Intune (opens in new tab)
Per platform: Windows (opens in new tab), macOS (opens in new tab), iOS/iPadOS (opens in new tab), Android device administrator (opens in new tab), Android (AOSP) (opens in new tab), Android Enterprise (opens in new tab)

End-user impact: Medium. On their own, compliance policies only affect reporting; impact arrives when Conditional Access enforces them. Some settings do prompt users directly. Requiring encryption of data storage, for example, prompts users to set up BitLocker if it is not already on; push a configuration profile that configures encryption automatically (control 9 below) to avoid those help desk calls.
Tip: settings will vary by organization, but standardize them wherever possible.
PowerShell: Compliance policy samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Videos: iOS device compliance policy (opens in new tab), Windows 10 compliance policy (opens in new tab), Custom compliance policies (opens in new tab)
CIS mapping

5. Block noncompliant devices from corporate resources
This is where compliance grows teeth. A Conditional Access policy that requires a compliant device shuts out both enrolled devices that have fallen out of compliance and devices that never enrolled at all.
Policy: noncompliant devices cannot access corporate resources.
Licensing: requires at least Azure AD P1, standalone or via EMS+E3/E5, Microsoft 365 Business Premium, Microsoft 365 E3, or Microsoft 365 E5.
Setup
- Follow these steps (opens in new tab) to create a Conditional Access policy
- Under Assignments, include all users, and be sure to exclude a break-glass account so you can never lock yourself out
- Under Cloud apps, include all cloud apps
- Leave the Conditions section unconfigured
- Under Grant, choose Require device to be marked as compliant

End-user impact: High. A user on a device not marked compliant sees a block message telling them to contact IT.

Tips
- Define a formal process for investigating noncompliant devices, and document the common noncompliance triggers to speed up resolution
- Automate alerting on noncompliant devices where possible so you act before the user calls
- Give users a support contact path that is not email, because a blocked device cannot open Outlook
PowerShell: Conditional Access API samples from Azure-Samples (opens in new tab)
Video: Preventing access on noncompliant devices (opens in new tab)
CIS mapping

Stage 3: Is the device configuration actually hardened?
6. Deploy security baselines to Windows devices
Security baselines in Intune are pre-configured groups of settings reflecting best-practice recommendations from the relevant Microsoft security teams. Intune ships baselines for Windows 10/11 device settings, Microsoft Edge, Microsoft Defender for Endpoint Protection, and more, supported on Windows 10 version 1809 and later and Windows 11. They rapidly deploy sensible defaults for settings such as:
- Password requirements
- Lock screen settings
- App installation
Policy: security baselines are configured for Windows devices.
Licensing: any tenant with Intune licensing.
Setup
Configure security baseline profiles in Intune (opens in new tab)

End-user impact: Medium. Some pre-configured baseline settings can disrupt users. Test against a device on the corporate network with a pilot group before broad deployment.
Tip: baselines are one of several Intune mechanisms that configure device settings. Know what else in your environment touches the same settings so policies do not fight each other; see Avoid policy conflicts (opens in new tab).
PowerShell: Endpoint security samples on microsoftgraph/powershell-intune-samples (opens in new tab) and Creating endpoint security policies with PowerShell (opens in new tab)
Videos: Microsoft Endpoint Manager security baselines (opens in new tab) and Endpoint protection part IV, security baselines (opens in new tab)
CIS mapping

7. Enforce lock screens and password rules on every platform
Lockout screen timeouts and password complexity should be enforced on all device platforms, with users prompted to change passwords that miss the bar. In Intune, where you configure this depends on the platform:
- Windows: security baselines (Device Lock, Local Policies Security Options), configuration profiles (Device Restrictions: Password)
- macOS: compliance policy (System Security)
- iOS: compliance policy (System Security)
- Android: compliance policy (System Security)
Policy: all supported devices enforce lockout screen timeouts and password settings.
Licensing: any tenant with Intune licensing.
Setup
Windows security baselines: Create security baseline profiles in Intune (opens in new tab)
- Under Device Lock, set the password requirements
- Under Local Policies Security Options, set the minutes of lock screen inactivity until the screen saver activates
macOS compliance policy: macOS device compliance settings (opens in new tab), under System Security, modify the password requirements and minutes of inactivity before a password is required
iOS compliance policy: iOS/iPadOS device compliance settings (opens in new tab), same System Security settings
Android compliance policy: Android Enterprise compliance settings (opens in new tab), same System Security settings

End-user impact: Medium. Users enrolling after enforcement may be prompted to update passwords that miss the policy.
Tip: watch for conflicts between configuration profiles, security baselines, and compliance policies that all touch password settings.
PowerShell: Compliance policy samples (opens in new tab) and device configuration samples (opens in new tab)
Videos: macOS configuration profiles in Intune (opens in new tab) and iOS device restrictions in Intune (opens in new tab)
CIS mapping

8. Require encryption everywhere, silently
Disk encryption belongs on every corporate-owned device, with application-layer encryption of corporate data where applicable. The Intune admin center exposes encryption in several places:
- Endpoint security > Disk encryption: FileVault (macOS) and BitLocker (Windows) settings
- Configuration profiles: Endpoint Protection (Windows Encryption, FileVault), Device Restrictions (iOS, Android)
- App protection policies: application data encryption for iOS and Android
Policy: disk encryption is required on all devices.
Licensing: any tenant with Intune licensing.
Setup
Disk encryption: Manage disk encryption with endpoint security policies (opens in new tab)
Configuration profiles: Configure endpoint protection settings (opens in new tab)
App protection policies: iOS/iPadOS settings (opens in new tab) and Android settings (opens in new tab)

End-user impact: Low. Configured correctly, encryption applies with no user interaction. The exception is a failed configuration, where the user gets prompted to fix it on the device.
Tips
- Watch for conflicts between configuration profiles, security baselines, compliance policies, and disk encryption profiles
- Push the disk encryption configuration profiles before enforcing any compliance policy that requires encryption, so encryption configures silently and users never see a setup prompt
PowerShell: Device configuration samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Videos: Troubleshooting BitLocker encryption with Intune (opens in new tab), Enforce FileVault on macOS (opens in new tab), Configuring and deploying BitLocker client policies (opens in new tab), Configure BitLocker policy in Intune (opens in new tab)
CIS mapping

9. Replace passwords with Windows Hello for Business
On Windows 10/11 devices, Windows Hello for Business swaps passwords for strong two-factor authentication on the device: a user credential tied to the hardware, unlocked with a biometric or PIN.
Policy: Windows Hello for Business is configured where applicable.
Licensing: any tenant with Intune licensing.
Setup
- At enrollment time: Configure a tenant-wide Windows Hello for Business policy (opens in new tab)
- After enrollment: Deploy Windows Hello policy to device groups (opens in new tab)

End-user impact: Low. Users are prompted to set up facial recognition or a fingerprint depending on the device, plus a PIN as the fallback when biometrics fail or are unavailable.
PowerShell: Device configuration samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Videos: Deploy Windows Hello for Business using configuration profiles (opens in new tab) and Configure Windows Hello for Business in Intune (opens in new tab)
CIS mapping

Stage 4: Are patches landing on schedule?
10. Configure Windows update rings
Windows update rings (Windows Update for Business) manage the patch cycle across your Windows fleet. Stagger updates across the organization so a bad feature update or bug surfaces in a small group first, and push critical updates immediately to all devices through the update ring service. Enterprise customers can also look at Windows Autopatch (opens in new tab) to automate ring deployment.
Policy: Windows update rings are configured and assigned to all Windows devices.
Licensing
- Any tenant with Intune licensing
- OS requirements: Update rings prerequisites (opens in new tab)
- Autopatch prerequisites: Windows Autopatch prerequisites (opens in new tab)
Setup
Create and assign update rings (opens in new tab)

End-user impact: Medium-High. Patching has always been notorious for disrupting users. Update rings let you define deployment windows, typically after business hours, and set how long users can defer before installation is forced. Expect occasional rollbacks when an update breaks a line-of-business app.
Tips
- Define the process for rolling back updates and for pushing critical updates to everything, before you need either
- In broad deployment, defer quality updates at least 14 days to cut rollback frequency
PowerShell: Software update samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Videos: Windows update rings (opens in new tab) and Automate Windows patching (opens in new tab)
CIS mapping

11. Manage Apple updates the same way
Intune manages software updates for macOS, iOS, and iPad devices enrolled as supervised devices (opens in new tab), mirroring what update rings do for Windows.
Policy: update policies are configured for macOS, iOS, and iPad devices.
Licensing: any tenant with Intune licensing.
Setup
Manage macOS software updates (opens in new tab) and manage iOS/iPadOS software updates (opens in new tab)

End-user impact: Medium-High. Same patching disruption story; define deployment windows after hours. On supervised macOS devices you may want to hide updates from users for a period, which a settings catalog policy with update restriction periods handles: delay visibility of macOS updates (opens in new tab).
Tip: the Install immediately option is the most user-impactful setting, because it reboots the machine on the spot.
PowerShell: Software update samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Video: Patching macOS devices with Microsoft Intune (opens in new tab)
CIS mapping

Stage 5: Is corporate data only flowing through apps you control?
12. Protect mobile data with app protection policies
Through Intune's mobile application management (MAM), app protection policies let users reach corporate applications on mobile devices securely without enrolling the device. You can require an app PIN, block cut, copy, and paste to unmanaged applications, and more. Configure them for both iOS and Android.
Policy: app protection policies are configured for iOS and Android devices.
Licensing: any tenant with Intune licensing.
Setup
Create and deploy app protection policies (opens in new tab), with the setting references for Android (opens in new tab) and iOS/iPadOS (opens in new tab)
End-user impact: Medium. Opening corporate data in a managed app like Outlook shows the user a prompt that the app is under corporate management, and depending on the policy they may need to take action such as setting an application PIN.

Tip: do not scope the policy to all apps on the device. The recommended setting is all Microsoft apps.
PowerShell: App protection policy samples on microsoftgraph/powershell-intune-samples (opens in new tab)
Videos: Protecting corporate data on iOS and Android (opens in new tab), Android app protection policies (opens in new tab), iOS app protection policies (opens in new tab)
CIS mapping

13. Restrict mobile access to approved client apps
Conditional Access can require approved client apps (opens in new tab) for corporate data on mobile. The point: keep mail out of the native mail client, an app you can neither control nor wipe when the user leaves.
Policy: mobile devices can only reach corporate data through approved client apps.
Licensing: requires at least Azure AD P1, standalone or via EMS+E3/E5, Microsoft 365 Business Premium, Microsoft 365 E3, or Microsoft 365 E5.
Setup
- Create a Conditional Access policy scoped to mobile devices, following the same flow as the compliant-device policy (opens in new tab)
- In the access controls, select only the Require approved client app setting
Note: you can add the require app protection policy grant here as well, but it forces those devices to enroll in MDM. More information: Grant controls in Conditional Access policy (opens in new tab).
End-user impact: Medium. A user opening corporate data in an unapproved client, such as the native mail app, is redirected to the App Store or Google Play to download the approved client, in this case Outlook.

Tip: app protection policies can be scoped to managed or unmanaged devices. If yours are scoped to managed devices, you will likely want the Require App Protection Policy grant in this Conditional Access policy too.
PowerShell: none currently.
Video: Configure Conditional Access and app protection policies for iOS (opens in new tab)
CIS mapping

14. Deploy and maintain an authorized app inventory
Keep an inventory of corporate-approved applications, package and deploy them from the Apps section of the Intune admin center, and run the whole application lifecycle, patching included, through Intune.
Policy: authorized applications are deployed to managed devices.
Licensing: any tenant with Intune licensing.
Setup
Prepare Win32 apps for Intune (opens in new tab) and add Microsoft Store apps (opens in new tab)

End-user impact: Low. Depends on the apps. The installation package you define determines whether an app installs automatically or appears as optional for the user.
Tip: use packaging tools like Winget and Chocolatey to automate app packaging and deployment. We cover that workflow end to end in our guide to automating Win32 app packaging.
PowerShell and open source
- Romanitho/Winget-Install (opens in new tab)
- Romanitho/Winget-AutoUpdate (opens in new tab)
- o-l-a-v/winget-intune-win32 (opens in new tab)
Videos: How to automate app packaging for Windows devices (opens in new tab), deploying apps in Intune (opens in new tab), Winget plus Intune (opens in new tab)
CIS mapping

Stage 6: What happens when a device goes quiet or a user walks out?
15. Auto-delete devices that stop checking in
By default, Intune never removes a device no matter how long it sits idle. To keep the inventory limited to active, authorized devices, configure cleanup rules to delete anything that has not checked in for over 30 days.
Policy: devices that have not checked in for over 30 days are deleted from Intune.
Licensing: any tenant with Intune licensing.
Setup
- Go to the Intune admin center
- Click Devices
- Scroll to Other and select Device clean-up rules
- Select Yes for the first option
- Set the time period to 30 days
- Click Save

End-user impact: Low. A device idle for more than 30 days is removed from Intune. Devices can be recovered for up to 180 days, which covers someone on extended leave.
Tip: if Intune is your source of truth for asset inventory, consider 60 or 90 days instead, so you have more time to identify stale devices and reissue or retire them before removal.
PowerShell: Intune device cleanup rules write-up with scripts (opens in new tab)
Video: How to set up an automatic device cleanup rule in Intune (opens in new tab)
CIS mapping

16. Wipe devices and apps on departure or loss
Standard operating procedures should exist for remotely wiping devices and applications when a user leaves the organization or reports a device lost or stolen. This is the control nobody tests until the week they need it.
Policy: devices and applications are wiped when a user leaves the organization or reports a lost or stolen device.
Licensing: any tenant with Intune licensing.
Setup
Retire or wipe devices using Intune (opens in new tab) and wipe only corporate data from apps (opens in new tab)

End-user impact: None, unless a wipe is issued in error against a device that should have been left alone.
PowerShell: none currently.
Videos: Wipe and remove a Windows 10 device (opens in new tab), remotely erase macOS (opens in new tab), Windows Autopilot Reset (opens in new tab), perform a selective wipe (opens in new tab)
CIS mapping

Where do you go past these 16?
CIS publishes benchmarks for Microsoft Intune covering Windows 10 and Windows 11 devices. Their granularity is too verbose for a checklist like this one, but they are the right next stop: review them over time and pull additional controls into your baseline as your environment warrants. Download them in the Microsoft Intune for Windows section at CIS Downloads (opens in new tab).
Frequently asked questions
Which of these Intune controls require extra licensing?
Most need only Intune itself. The two Conditional Access controls, blocking noncompliant devices and requiring approved client apps, need at least Azure AD P1, included in EMS E3/E5, Microsoft 365 Business Premium, E3, and E5.
Should device cleanup really delete devices after 30 days?
30 days is the recommended baseline, and devices can be recovered for up to 180 days. If Intune is your source of truth for asset inventory, 60 or 90 days gives you more time to identify stale devices and reissue or retire them before removal.
Do app protection policies require device enrollment?
No. App protection policies use Intune's mobile application management (MAM), so users can access corporate apps securely on mobile devices without enrolling the device into MDM. Scope them to all Microsoft apps rather than every app on the device.
What about the CIS Intune benchmarks?
CIS publishes benchmarks for Microsoft Intune covering Windows 10 and Windows 11 devices. They are too granular to cover in one checklist, but reviewing them over time and folding selected controls into your baseline is worth the effort. They are free at the CIS downloads site.
Sixteen controls, every tenant, every month
Building this baseline once is a project. Verifying it still holds across every client tenant is a treadmill. CloudCapsule checks 250+ controls, device posture included, in about 60 seconds per tenant.
Book a demo
Written by
Nick Ross
CEO · Microsoft MVP · Founder, T-Minus 365
Nick is not just a CEO, he's a respected thought leader and influencer in the MSP space. Tens of thousands of MSPs learn through his YouTube channel, T-Minus365. Nick has been honored as a three-time Microsoft MVP for his educational content; his expertise and influence are the backbone of our mission, ensuring that you are in the best hands when it comes to security.
Nick joined Pax8 in 2017, where he would ultimately oversee product management for PSA and Microsoft integrations. Following his tenure at Pax8, Nick has continued to demonstrate his leadership prowess as an executive at various MSPs, culminating in his most recent role at Sourcepass.
Nick holds a Bachelor's Degree in Business Management from Florida State University, as well as a Minor Degree in Entrepreneurship. In his free time, Nick is an avid hiker, reader, and fitness-junkie.


