Mobile & Endpoint Security

To achieve a defensible, conflict-free Intune configuration we use the Open Intune Baseline (OIB) as a robust, granular configuration starting point. We then tailor this baseline for the target environment and applicable compliance controls.

This approach satisfies requirements for a baseline Intune deployment while ensuring long-term operational stability and auditability.

Architectural Decision

For the reasoning behind replacing generic Microsoft Security Baselines with community-vetted, granular OIB JSON imports, refer to Chapter 9: Foundational Architecture and Design.

Mobile Enrollment and App Protection

Mobile security in Intune spans two distinct architectural models: Mobile Device Management (MDM), where Intune controls the entire device; and Mobile Application Management (MAM) — also called App Protection Policies (APP) — where Intune controls only the data inside specific managed apps, leaving the rest of the device untouched. The right model depends on whether the device is corporate-owned or personally owned (BYOD), and — on Android — how strong a separation between work and personal data is required.

The three postures most organizations land on:

Posture	Device Ownership	What Intune Controls
Corporate MDM	Corporate-owned	Entire device — enrollment, configuration, apps, wipe
BYOD MAM (App Protection)	Personally owned	Data inside managed apps only; device untouched
BYOD Work Profile (Android)	Personally owned	A managed work container alongside the user's personal space

The Role of the Company Portal and Broker Apps

The single most commonly misunderstood part of Intune mobile is which app delivers policy to the device for each scenario. The Intune Company Portal is required in some scenarios, not required in others, and sometimes required installed but not signed in. Android and iOS behave differently, and corporate and BYOD behave differently within each platform.

Scenario	Broker / Required App	Company Portal?
iOS Corporate (Apple ADE)	—	No — optional for end-user self-service only
Android Corporate (Fully Managed)	Microsoft Intune app (DPC)	No — Company Portal is not used
iOS BYOD (MAM / App Protection)	Microsoft Authenticator	No
Android BYOD (MAM / App Protection)	Intune Company Portal	Yes — installed, not signed in, not enrolled
Android BYOD (Work Profile)	Intune Company Portal	Yes — drives the Work Profile enrollment

Two points worth internalizing:

• On Android Fully Managed, the Device Policy Controller is the Microsoft Intune app, not Company Portal. This is the single biggest source of confusion in Android corporate enrollment — documentation and end-user instructions frequently reference "Company Portal" by reflex when Intune is the actual requirement.
• On Android BYOD MAM, Company Portal must be present on the device as the broker that the Intune App SDK inside each managed app uses to fetch policy. The user does not sign into it, does not enroll, and does not interact with it after install. It just has to exist. Without it, App Protection policies will not apply to Outlook, Teams, and other managed apps.

Corporate MDM Enrollment

Corporate-owned devices enroll into full MDM. Intune controls the entire device, provisions configuration and apps, and can wipe the device entirely.

iOS / iPadOS — Apple Automated Device Enrollment (ADE)

Prerequisites:

• Apple Business Manager (ABM) tenant
• ABM linked to Intune via an MDM server token
• Devices purchased through an ABM-registered reseller (or Apple direct) so they appear in ABM automatically

Enrollment flow:

1. Device is unboxed and powered on.
2. During Apple Setup Assistant, the device contacts Apple and is handed to Intune.
3. Intune applies the ADE enrollment profile — supervised mode, non-removable MDM, and any Setup Assistant panes configured to skip.
4. User signs in with their Entra ID work account; device is registered to that user.

Company Portal is not required for enrollment. It can optionally be pushed as a required app so users can reset their passcode, view compliance state, or initiate remote actions on their own device.

For legacy inventory not registered in ABM, Apple Configurator enrollment (tethered to a Mac) wipes and enrolls the device into supervised MDM. Useful for one-time migration of an existing fleet.

Android — Android Enterprise Fully Managed (COBO)

Android Fully Managed creates a corporate-only device with no personal profile or personal space. Intune controls everything.

Enrollment methods:

Method	When to Use
QR code	Small-scale rollouts — QR is generated by the Intune Fully Managed enrollment profile and scanned during device OOBE
Google Zero-Touch Enrollment	Large-scale rollouts on supported OEMs (Pixel and most major brands) — devices assigned in the Zero-Touch portal auto-enroll on first boot
Samsung Knox Mobile Enrollment (KME)	Samsung-specific equivalent to Zero-Touch — assigned via the Knox portal
afw#setup token	Manual text entry during OOBE — useful for one-offs, not scale

The Microsoft Intune app is the DPC (Device Policy Controller) on Fully Managed Android. Company Portal is not used on this platform.

BYOD App Protection (MAM)

App Protection Policies protect corporate data inside managed apps — Outlook, Teams, OneDrive, Edge, Word, Excel, PowerPoint, and any line-of-business app that integrates with the Intune App SDK. Policies target the user identity, not the device. The device is never enrolled into MDM.

Typical protections:

• Require PIN or biometric to open managed apps
• Block copy/paste, Save As, and data transfer to unmanaged apps
• Block save-to-personal-cloud
• Enforce app-level encryption
• Selective wipe of corporate data only — personal data is never touched

iOS BYOD (MAM)

• Enrollment: none
• Broker: Microsoft Authenticator
• Company Portal: not required

User experience: the user installs Outlook (and Teams, OneDrive, etc.) from the App Store, signs in with their work account, and APP policy applies automatically on first launch. Most users already have Authenticator installed for MFA, so no additional setup is typically needed.

Android BYOD (MAM)

• Enrollment: none
• Broker: Intune Company Portal
• Company Portal: required — installed on the device, but the user does not sign in and the device is not enrolled

User experience: the user installs Company Portal from Google Play (no sign-in), installs Outlook (and Teams, OneDrive, etc.), then signs into the managed apps with their work account. APP policy applies automatically. The Intune App SDK inside each managed app uses Company Portal as the broker to fetch policy from Intune.

This is the exact opposite of iOS: on iOS the broker is Authenticator; on Android the broker is Company Portal.

Android BYOD Work Profile (MDM with Container)

Work Profile is the middle path between MAM-only BYOD and Fully Managed corporate. It creates a managed work container alongside the user's personal space. Work apps, data, and email live inside the container; personal data is never touched.

• Enrollment: Work Profile enrollment driven by Company Portal
• Company Portal: required — user signs in to provision the work container
• Intune control scope: only the work container — Intune can wipe the container without affecting personal data

Work Profile is the right choice when MAM alone is considered insufficient — for regulated data, when device-level compliance conditions are needed in Conditional Access, or when the organization wants a stronger separation than app-level controls provide.

Choosing MAM vs. Work Profile on Android

Consideration	MAM (App Protection Only)	Work Profile
User friction	Minimal — install Company Portal, install apps, sign in	Moderate — Work Profile provisioning takes several minutes
Separation strength	App-level (data inside managed apps)	Container-level (fully isolated work space)
Device-level compliance signals	Not available — no device enrollment	Available — Work Profile reports device compliance to CA
Support for unenrolled-device-blocking CA policies	Not applicable — device is not a CA subject	Yes — device compliance can gate access
Appropriate for regulated data (CUI, ePHI, PCI)	Marginal — depends on regulatory interpretation	Preferred
Remote wipe scope	App data only (selective wipe)	Work container only (personal data preserved)

The general rule: start with MAM for most BYOD scenarios. Escalate to Work Profile when the data classification, regulatory exposure, or Conditional Access posture require device-level compliance signals.

End-User Communication Templates

Clear platform-specific guidance reduces help desk load. The single biggest source of support tickets in BYOD rollouts is users on Android not installing Company Portal, or users on iOS installing Company Portal unnecessarily.

iOS BYOD users:

To access company email and files on your personal iPhone or iPad:

1. Install Microsoft Authenticator from the App Store (you may already have this for MFA).
2. Install Microsoft Outlook (and Teams, OneDrive as needed) from the App Store.
3. Sign in with your work account. You may be asked to set an app PIN.

You do not need to enroll your device or install the Company Portal app.

Android BYOD users:

To access company email and files on your personal Android device:

1. Install the Intune Company Portal app from Google Play. Do not sign in or enroll the device — just leave it installed.
2. Install Microsoft Outlook (and Teams, OneDrive as needed) from Google Play.
3. Sign into Outlook with your work account. You may be asked to set an app PIN.

Your personal data and apps remain untouched — the company can only manage data inside the work apps.

Play Integrity on Android App Protection

Android App Protection policies can evaluate Google Play Integrity verdicts to detect rooted, emulated, or otherwise tampered devices and block access accordingly. The underlying Graph schema settings still carry the legacy "SafetyNet" prefix (requiredAndroidSafetyNetDeviceAttestationType, requiredAndroidSafetyNetAppsVerificationType), but Google retired SafetyNet Attestation and Intune now evaluates verdicts via the Play Integrity API.

Google's Strong Integrity verdict definition is currently enforced. App Protection policies left at none for device attestation accept any device — including rooted ones — without challenge. Recommended baseline: enable at least basic integrity for device attestation; consider basic & device integrity for higher-sensitivity data.

Open Intune Baseline (OIB)

OIB aggregates best practices into a unified set of granular JSON files deployable using the IntuneManagement tool by Mikael Karlsson. The following procedure walks through downloading both tools, connecting to your tenant, importing the policies, and preparing them for assignment.

Do not assign any imported policies to groups until you have reviewed and applied the modifications documented in the sections below.

Extract to a short, local path

Do not extract to your Downloads folder or any OneDrive-synced location. The Downloads folder creates problems:

• Long paths. OIB JSON filenames are verbose. Combined with a user profile path like C:\Users\Michael.LastName\Downloads\OpenIntuneBaseline-main\DeviceConfiguration\..., the total path easily exceeds the Windows 260-character limit. The tool silently skips files it cannot open.
• OneDrive Known Folder Move. Many enterprise builds redirect Downloads to OneDrive. Files appear local but may be cloud-only placeholders (Files On-Demand) that the tool cannot read.
• Browser download protection. Edge and Chrome apply Mark of the Web (MOTW) restrictions to downloaded ZIPs. Unblock the ZIP itself before extracting — otherwise the extracted files inherit the block flag.

Use a short, local path outside your user profile: C:\IT_Tools\ is recommended.

Step 1 — Download the IntuneManagement tool

The IntuneManagement tool is a collection of graphical PowerShell scripts rather than a traditional .exe installer.

1. Go to the Micke-K/IntuneManagement GitHub repository. Click the green Code button → Download ZIP.

2. Unblock the ZIP before extracting. Right-click the downloaded ZIP → Properties → check Unblock → OK. This prevents the block flag from propagating to every extracted file.

3. Extract the ZIP and move the inner IntuneManagement-master folder to C:\IT_Tools\IntuneManagement.

4. Verify the scripts are unblocked. Open PowerShell as Administrator and run:

   Get-ChildItem -Path "C:\IT_Tools\IntuneManagement" -Recurse | Unblock-File

Step 2 — Download the OIB JSON files

1. Go to the Open Intune Baseline GitHub repository. Click the green Code button → Download ZIP.
2. Unblock the ZIP before extracting (same as Step 1 — right-click → Properties → Unblock).
3. Extract the ZIP to C:\IT_Tools\OpenIntuneBaseline.
4. Navigate into the extracted folder. GitHub ZIPs create a wrapper folder (e.g., OpenIntuneBaseline-main inside OpenIntuneBaseline). Open that inner folder and confirm you can see the policy subfolders as immediate children:
   • DeviceConfiguration — Settings Catalog profiles
   • EndpointSecurity — Endpoint Security profiles (ASR, BitLocker, Defender AV, Firewall, LAPS, WHfB)
   • CompliancePolicies — (if present in the version you downloaded)

Which version?

The OIB folder and file names include a version number (e.g., v3.7). Note this version — it appears in the policy names after import and helps you track which baseline you deployed.

Step 3 — Launch the tool and configure for your cloud

1. Navigate to the IntuneManagement folder and run Start_PS7.cmd (PowerShell 7) or Start.cmd (PowerShell 5.1).

GCC High

2. Before signing in, configure the tool for the sovereign cloud:
   • Click File → Settings in the top left
   • Under the MSAL section, check Show Azure AD login menu
   • Click Save

Commercial

No additional configuration needed — the tool defaults to the Commercial cloud. Proceed to the next step.

Step 4 — Sign in and grant consent

GCC High

1. Click the Profile icon (top right) to sign in. A pre-login window appears — select Azure US Government.
2. Authenticate with a Global Administrator account. A Global Administrator is required for the first sign-in because the consent step below grants the IntuneManagement app Microsoft Graph API permissions (read/write to Intune policies, device configurations, and endpoint security profiles) on behalf of the organization.

Commercial

1. Click the Profile icon (top right) to sign in.
2. Authenticate with a Global Administrator account. A Global Administrator is required for the first sign-in because the consent step below grants the IntuneManagement app Microsoft Graph API permissions (read/write to Intune policies, device configurations, and endpoint security profiles) on behalf of the organization.

3. After signing in, click the Profile icon again and select Request Consent. An Entra ID consent prompt appears listing the Microsoft Graph permissions the tool requires. Review the permissions and click Accept.
4. Close and relaunch the tool. The consent grant does not take effect until the app acquires a new token. Relaunch the tool, sign in again (selecting Azure US Government for GCC High), and confirm you can navigate the Intune data in the left panel.

Subsequent sign-ins

After the initial consent, any account with Intune Administrator or Global Administrator can sign in — the consent is granted to the app registration, not the individual user. You do not need to repeat the consent step unless the tool is updated with new permission requirements.

Step 5 — Import the OIB policies

Import terminology

In the IntuneManagement tool, Import means "push JSON files into Intune" (create policies in the tenant) and Export means "pull policies from Intune and save as JSON files." The tool is a pass-through — JSON files go directly to the Microsoft Graph API.

The tool has two import modes: Bulk → Import imports an entire folder structure at once across all policy types. The per-section Import button in the main window imports only the policy type you're currently viewing (e.g., Antivirus only). For an OIB deployment, use Bulk → Import.

1. Click Bulk → Import from the top menu
2. Click Select Folder and browse to the inner folder that contains the policy subfolders directly (e.g., C:\IT_Tools\OpenIntuneBaseline\OpenIntuneBaseline-main). You should see DeviceConfiguration, EndpointSecurity, etc. as immediate children of the folder you select. If you select the outer wrapper folder, the tool will report no policies found.
3. The tool scans the folder recursively and displays all discovered JSON policy files, grouped by type (Device Configuration, Endpoint Security, etc.)
4. Select all policies you want to import — for a first deployment, import everything. You can remove individual policies later.
5. Click Import to start the operation
6. The tool creates each policy in your Intune tenant via Microsoft Graph. Watch the progress log for errors.

Common import issues

Symptom	Cause	Fix
"No policies found" or empty import list	Selected the outer wrapper folder instead of the inner folder containing DeviceConfiguration, EndpointSecurity, etc.	Browse one level deeper — select the OpenIntuneBaseline-main folder, not the parent
"No policies found" (correct folder selected)	Files extracted to an OneDrive-synced folder and are cloud-only placeholders (Files On-Demand)	Re-extract to a local path outside OneDrive (e.g., C:\IT_Tools\)
"No policies found" (correct folder, local path)	Long file paths exceeding 260 characters — the tool silently skips files it cannot open	Shorten the path. Extract directly to C:\IT_Tools\ rather than a deeply nested location
"No policies found" (all above checked)	Blocked files. The ZIP was not unblocked before extraction, and the block flag propagated to all JSON files	Run Get-ChildItem -Path "C:\IT_Tools\OpenIntuneBaseline" -Recurse | Unblock-File
"No policies found" (all above checked)	IntuneManagement tool version does not recognize the OIB folder structure or JSON format	Download the latest version of both the IntuneManagement tool and OIB
"Insufficient privileges" error	Account lacks required role or consent was not granted	Ensure you completed the consent step (Step 4) and are signed in with Global Admin or Intune Admin
"Resource not found" or "BadRequest" on a specific policy	OIB JSON references a setting or template not available in your tenant's cloud or license tier	Skip that policy and create it manually using the OIB JSON as a reference
Duplicate policy names	You ran the import twice	Delete the duplicates from Intune before re-importing
MSAL / token errors in GCC High	Sovereign cloud not selected before sign-in	Close the tool, reopen, verify Azure US Government is set in File → Settings → MSAL, then sign in again
Consent prompt does not appear	Browser popup blocked or consent already granted	Check browser popup settings; if consent was previously granted, this step is not needed again

Step 6 — Verify the import

1. Open the Microsoft Intune admin center (intune.microsoft.us for GCC High, intune.microsoft.com for Commercial)
2. Navigate to Devices → Configuration and Endpoint Security — you should see the OIB policies listed with names like Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7
3. Open several policies and confirm settings are populated (not empty)
4. Do not assign any policy to a group yet — first apply the environment-specific modifications below

Step 7 — Apply environment-specific modifications

After import, review each policy against the modifications documented in the following sections before assigning to any device or user group:

• GCC High tenants: Apply the GCC High Critical Modifications documented below under the GCC High tab (telemetry, cryptography, identity routing)
• All tenants: Customize the settings in the CMMC Control Mapping Matrix (GCC High tab) or NIST SP 800-171 Rev. 3 Control Mapping (Commercial tab) — specifically banner text, lock screen timeout, removable media policy, and the compliance policy
• Existing GPO environments: Cross-reference against your GPO gap analysis to ensure high-value settings from the existing estate are preserved

Step 8 — Assign policies

Once modifications are complete:

1. Create a pilot device group (5–10 devices representing your hardware diversity)
2. Assign all OIB policies to the pilot group
3. Monitor Devices → Monitor → Assignment failures and Configuration → Per-policy status for conflicts or errors
4. After 48 hours of clean pilot operation, expand assignment to broader device groups in waves

Do not assign to "All Devices" on day one

OIB policies will overwrite existing Intune, GPO, and local security settings. A phased rollout lets you catch conflicts (duplicate settings, policy fights, app-breaking hardening) before they affect production users. If the client has existing ad-hoc Intune policies, expect conflicts — the pilot phase is where you identify and retire them.

GCC High

GCC High Critical Modifications

OIB is designed for the Commercial cloud, we must apply the following changes for GCC High and CMMC compliance.

Telemetry & Reporting

OIB enables deep Windows diagnostic data and Defender telemetry which are not supported in GCC High, leading to "Error" states in Intune profiles.

• Action: Edit the imported OIB EDR and Windows Data Collection profiles. Set Expedite telemetry reporting frequency to Not Configured. Ensure diagnostic data is limited to "Required" (Basic) to prevent data spill risks.

Stop Fighting Device Conflicts

Maintaining a defensible, conflict-free Intune configuration using the Open Intune Baseline (OIB) requires surgical modifications for GCC High. If your deployment is bogged down by phantom errors, conflicting security baselines, or devices that fail compliance checks, Mindline can help. We design and deploy modular, CMMC-aligned Intune profiles that keep your endpoints secure without disrupting your end users. Let us streamline your endpoint operations. Visit mindline.com.

Cryptography & FIPS Compliance

OIB establishes strong BitLocker defaults, but CMMC/DoD assessments often scrutinize cryptographic modules strictly.

• Action: Verify the OIB Disk Encryption profile enforces XTS-AES 256-bit encryption. If your specific contract requires strict FIPS 140-2 validation, ensure the local security policy for "System cryptography: Use FIPS compliant algorithms" is enabled (Note: test thoroughly as it can break apps).

Identity Routing

OIB will provision standard Windows Hello for Business (WHfB) settings, but it does not account for sovereign cloud routing.

• Action: Ensure the Entra ID Connect sync and Kerberos routing for Cloud Trust point specifically to US Government endpoints (e.g., *.login.microsoftonline.us).

Commercial

No corresponding requirement for Commercial tenants.

GCC High

CMMC Control Mapping Matrix

Here are the baseline profiles mapped to their corresponding NIST SP 800-171 controls for your System Security Plan (SSP). Note that some controls utilize the Open Intune Baseline (OIB) JSON files, while others require manual configuration or custom XML to meet strict compliance requirements.

Deliverable Scope	Profile Source / Filename	Critical Setting Verification	NIST 800-171 Control	Audit Method
Attack Surface Reduction - D	Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7	Ensure "Block Office apps from creating child processes" and "Block credential stealing" set to Block.	3.1.1, 3.14.1 (Limit system access; Flaw remediation)	MDE Advanced Hunting KQL (DeviceEvents); Intune ASR Report.
Exploit Protection	Manual Creation: Custom ASR XML Profile	Verify custom XML enables DEP, ASLR, and SEHOP system-wide.	3.14.1 (Identify and correct system flaws)	PowerShell Get-ProcessMitigation; Windows Security App.
Defender for Endpoint (EDR)	Manual Creation: Intune Endpoint Security Profile	Verify Auto-onboard via Intune Connector is active.	3.14.3 (Monitor system security alerts and advisories)	MDE Device Inventory; Intune EDR Onboarding Status.
BitLocker (OS Disk)	Win - OIB - ES - Encryption - D - BitLocker (OS Disk) - v3.7	Verify XTS-AES 256-bit encryption is enforced for OS and fixed drives. Note: Windows may attempt to independently enable encryption.	3.13.11, 3.8.6 (FIPS 140-2 would require additional configuration and testing; Protect CUI on mobile devices)	Intune Encryption Report; Local manage-bde -status.
Windows Hello for Business - D	Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2 Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5	Verify Require TPM, Minimum PIN: 6, and US Gov routing URLs.	3.5.3 (Use multifactor authentication for local and network access)	Entra ID Sign-in Logs (Auth Requirement: MFA); Local dsregcmd /status.
Windows LAPS	Win - OIB - ES - Windows LAPS - D - LAPS Configuration - v3.1	Configure Windows LAPS. Enable backup to Entra ID, enforce 14+ characters, and set rotation to 30 days.	3.1.1, 3.1.5 (Limit access; Least privilege)	Entra ID LAPS Audit Logs; Intune Device Local Admin status.
Local Security	Win - OIB - SC - Device Security - D - Local Security Policies - v3.0	Edit profile to add Interactive Logon Message Text and Interactive Logon Message Title. Replace with your Banner Text.	3.1.9 (Provide privacy and security notices)	Local Registry: HKLM\SOFTWARE\...\Policies\System\LegalNoticeText.
Security Experience	Win - OIB - ES - Defender Antivirus - D - Security Experience - v3.3	Ensure Hide Windows Security Notification Area and Enable Tamper Protection are enforced.	3.4.5 (Restrict nonessential programs)	MDE Security Center (Tamper Protection status).
Removable Media	Manual Creation: Custom ASR Device Control XML	Verify XML policies deny all write access while allowing approved hardware IDs.	3.8.1, 3.8.7 (Control removable media)	MDE Advanced Hunting KQL (RemovableStoragePolicyTriggered).
Login and Lock Screen	Win - OIB - SC - Device Security - U - Power and Device Lock - v3.6 Win - OIB - SC - Device Security - D - Login and Lock Screen - v3.1	Adjust the OIB default to ensure Max Inactivity Time Device Lock is 15 Minutes (900 seconds) or less.	3.1.10 (Session lock)	Intune Profile Status.
Reports and Telemetry	Win - OIB - SC - Windows Update for Business - D - Reports and Telemetry - v3.0	Set "Allow Telemetry" to Basic/Security and completely remove "Expedite telemetry reporting frequency".	3.1.3 (Control the flow of CUI)	Intune Profile Status.

Transitioning Existing MDE Deployments

Clients often worry that pushing the Defender for Endpoint (MDE) onboarding policy via Intune will break existing standalone MDE installations. It will not.

• MDE is Built-In: On Windows 10/11, MDE is not a separately installed application; it is a dormant sensor built into the OS. The Intune policy simply passes a configuration file pointing that sensor to your Intune tenant.
• No Interruption: If the device is already reporting to your tenant (e.g., previously onboarded via local script or GPO), Intune simply detects the active sensor, registers a "Success" state, and continues without interrupting protection. (Note: If the device is reporting to a completely different company's tenant, it must be offboarded first).
• Configuration Takeover: While the onboarding itself is harmless, Intune will immediately overwrite legacy local or GPO security configurations (like AV scans and ASR rules). This is the desired behavior, as Intune must become the single, authoritative source of truth for your CMMC System Security Plan.

Why hide the Windows Security Notification Area?

Clients often worry that hiding the security notification area means turning off their antivirus. It does not. Hiding this area simply removes the Windows Security "shield" icon from the user's taskbar and suppresses local pop-up alerts. The underlying protections (Defender AV, ASR, Exploit Protection) remain fully active in the background. In a CMMC and Zero Trust architecture, this is enforced for two reasons:

1. Preventing Tampering: It removes the user interface, preventing standard users from attempting to pause real-time protection, add exclusions for risky files, or bypass SmartScreen blocks.
2. Centralizing Operations: Security alerts are routed silently to the Microsoft Defender portal for the IT/SOC team to investigate, rather than causing user panic or generating unnecessary helpdesk tickets for routine background scans.

Intune Endpoint Privilege Management (EPM)

EPM is an add-on license that allows standard users to elevate specific, approved applications without needing IT to type in the LAPS password. While LAPS is practically mandatory for CMMC to secure the default admin account, EPM is highly recommended for operational sanity so your helpdesk isn't overwhelmed with UAC elevation requests for legacy DoD apps. EPM is being included in the Microsoft 365 E5/G5 SKUs starting July 1, 2026.

Intune Compliance Policy — GCC High

OIB includes four user-scoped compliance policies that validate the device state. These policies act as the signal used by Entra ID Conditional Access to block non-compliant devices from accessing protected data.

OIB Compliance Policy	What it validates
Win - OIB - Compliance - U - Password - v3.1	Password complexity and length requirements
Win - OIB - Compliance - U - Device Security - v3.1	Firewall, Antivirus/Antispyware, Secure Boot
Win - OIB - Compliance - U - Device Health - v3.1	BitLocker encryption, device health attestation
Win - OIB - Compliance - U - Defender for Endpoint - v3.1	MDE machine risk score threshold

Why four separate compliance policies instead of one?

OIB splits compliance into granular policies for the same reason it splits configuration profiles:

• Phased rollout — deploy Device Health and Device Security immediately, but hold the Password policy until you've communicated the forced password reset to users
• Different non-compliance actions — Password violations may warrant a grace period while BitLocker/Firewall violations are marked non-compliant immediately
• Targeted exclusions — the Defender for Endpoint policy only applies to devices onboarded to MDE; exclude devices without P2 licensing
• Faster diagnosis — if a device is non-compliant, four granular policies immediately show which category failed rather than requiring you to hunt through a single monolithic policy

If you have a single combined compliance policy from a previous deployment, retire it once the four OIB policies are validated and covering the same settings.

After import, review and adjust the OIB compliance policies against the requirements below. The OIB defaults may not match your compliance requirements exactly — verify each setting value.

Policy Type: Windows 10 and later

Policy Section	Setting Name	Required Value	NIST SP 800-171 Rev. 2 (CMMC)	Non-Compliance Action
Device Health	Require BitLocker	Require	3.13.11, 3.8.6 (FIPS-validated cryptography; Protect CUI on portable storage)	Mark non-compliant immediately.
Device Health	Require Secure Boot	Require	3.14.1 (Identify and correct system flaws)	Mark non-compliant immediately.
System Security	Minimum OS version	10.0.22631.xxxx (Current - 2 N)	3.14.1 (Flaw remediation)	Grace period: 3 days.
System Security	Firewall	Require	3.13.1 (Monitor, control, and protect communications)	Mark non-compliant immediately.
System Security	Antivirus / Antispyware	Require	3.14.2 (Provide protection from malicious code)	Mark non-compliant immediately.
System Security	Require a password to unlock mobile devices	Require (Minimum length: 8, Block simple passwords)	3.5.7, 3.5.8 (Password complexity; Prohibit password reuse)	Mark non-compliant immediately.
Defender for Endpoint	Machine Risk Score	Medium or lower	3.14.3 (Monitor system security alerts and advisories)	Mark non-compliant immediately.

Password Policy Changes Force Password Resets

Since your machine has no way to know if your local account existing password is compliant, you will be forced to change your password the next time you login.

Windows Hello for Business Setup

For WHfB Intune policy configuration (Entra Join) and Cloud Kerberos Trust setup (Hybrid Join), see Windows Hello for Business Setup & Troubleshooting.

One OIB-specific step: in the imported OIB Account Protection policy, explicitly enable Use Cloud Trust for On-Prem Auth. This setting is separate from the WHfB policy itself and is easy to miss during an OIB import.

Commercial

NIST SP 800-171 Rev. 3 Control Mapping

Here are the baseline profiles mapped to their corresponding NIST SP 800-171 Rev. 3 security requirements for your security plan documentation. These same technical configurations apply regardless of regulatory track; where Rev. 3 introduced new or reorganized requirements (notably 3.5.12 for replay-resistant authentication), those identifiers replace their Rev. 2 equivalents.

Deliverable Scope	Profile Source / Filename	Critical Setting Verification	NIST SP 800-171 Rev. 3 Requirement	Audit Method
Attack Surface Reduction - D	Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7	Ensure "Block Office apps from creating child processes" and "Block credential stealing" set to Block.	3.1.1, 3.14.1 (Limit system access; Flaw remediation)	MDE Advanced Hunting KQL (DeviceEvents); Intune ASR Report.
Exploit Protection	Manual Creation: Custom ASR XML Profile	Verify custom XML enables DEP, ASLR, and SEHOP system-wide.	3.14.1 (Identify and correct system flaws)	PowerShell Get-ProcessMitigation; Windows Security App.
Defender for Endpoint (EDR)	Manual Creation: Intune Endpoint Security Profile	Verify Auto-onboard via Intune Connector is active.	3.14.3 (Monitor system security alerts and advisories)	MDE Device Inventory; Intune EDR Onboarding Status.
BitLocker (OS Disk)	Win - OIB - ES - Encryption - D - BitLocker (OS Disk) - v3.7	Verify XTS-AES 256-bit encryption is enforced for OS and fixed drives.	3.13.11, 3.8.1 (FIPS-validated cryptography; Protect media)	Intune Encryption Report; Local manage-bde -status.
Windows Hello for Business - D	Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2 Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5	Verify Require TPM and Minimum PIN: 6.	3.5.3, 3.5.12 (Multifactor authentication; Replay-resistant authentication)	Entra ID Sign-in Logs (Auth Requirement: MFA); Local dsregcmd /status.
Windows LAPS	Win - OIB - ES - Windows LAPS - D - LAPS Configuration - v3.1	Configure Windows LAPS. Enable backup to Entra ID, enforce 14+ characters, and set rotation to 30 days.	3.1.1, 3.1.5 (Limit access; Least privilege)	Entra ID LAPS Audit Logs; Intune Device Local Admin status.
Local Security	Win - OIB - SC - Device Security - D - Local Security Policies - v3.0	Edit profile to add Interactive Logon Message Text and Interactive Logon Message Title. Replace with your Banner Text.	3.1.9 (Provide privacy and security notices)	Local Registry: HKLM\SOFTWARE\...\Policies\System\LegalNoticeText.
Security Experience	Win - OIB - ES - Defender Antivirus - D - Security Experience - v3.3	Ensure Hide Windows Security Notification Area and Enable Tamper Protection are enforced.	3.4.5 (Restrict nonessential programs)	MDE Security Center (Tamper Protection status).
Removable Media	Manual Creation: Custom ASR Device Control XML	Verify XML policies deny all write access while allowing approved hardware IDs.	3.8.1, 3.8.7 (Control removable media)	MDE Advanced Hunting KQL (RemovableStoragePolicyTriggered).
Login and Lock Screen	Win - OIB - SC - Device Security - U - Power and Device Lock - v3.6 Win - OIB - SC - Device Security - D - Login and Lock Screen - v3.1	Adjust the OIB default to ensure Max Inactivity Time Device Lock is 15 Minutes (900 seconds) or less.	3.1.10 (Session lock)	Intune Profile Status.
Reports and Telemetry	Win - OIB - SC - Windows Update for Business - D - Reports and Telemetry - v3.0	Set "Allow Telemetry" to Basic/Security.	3.1.3 (Control the flow of sensitive information)	Intune Profile Status.

Transitioning Existing MDE Deployments

Clients often worry that pushing the Defender for Endpoint (MDE) onboarding policy via Intune will break existing standalone MDE installations. It will not.

• MDE is Built-In: On Windows 10/11, MDE is not a separately installed application; it is a dormant sensor built into the OS. The Intune policy simply passes a configuration file pointing that sensor to your Intune tenant.
• No Interruption: If the device is already reporting to your tenant (e.g., previously onboarded via local script or GPO), Intune simply detects the active sensor, registers a "Success" state, and continues without interrupting protection. (Note: If the device is reporting to a completely different company's tenant, it must be offboarded first).
• Configuration Takeover: While the onboarding itself is harmless, Intune will immediately overwrite legacy local or GPO security configurations (like AV scans and ASR rules). This is the desired behavior, as Intune must become the single, authoritative source of truth for your security program documentation.

Why hide the Windows Security Notification Area?

Clients often worry that hiding the security notification area means turning off their antivirus. It does not. Hiding this area simply removes the Windows Security "shield" icon from the user's taskbar and suppresses local pop-up alerts. The underlying protections (Defender AV, ASR, Exploit Protection) remain fully active in the background. In a Zero Trust architecture, this is enforced for two reasons:

1. Preventing Tampering: It removes the user interface, preventing standard users from attempting to pause real-time protection, add exclusions for risky files, or bypass SmartScreen blocks.
2. Centralizing Operations: Security alerts are routed silently to the Microsoft Defender portal for the IT/SOC team to investigate, rather than causing user panic or generating unnecessary helpdesk tickets for routine background scans.

Intune Endpoint Privilege Management (EPM)

EPM is an add-on license that allows standard users to elevate specific, approved applications without needing IT to type in the LAPS password. While LAPS is practically mandatory to secure the default admin account, EPM is highly recommended for operational sanity so your helpdesk isn't overwhelmed with UAC elevation requests for legacy apps. EPM is being included in the Microsoft 365 E5/G5 SKUs starting July 1, 2026.

Intune Compliance Policy — Commercial

OIB includes four user-scoped compliance policies that validate the device state. These policies act as the signal used by Entra ID Conditional Access to block non-compliant devices from accessing protected data.

OIB Compliance Policy	What it validates
Win - OIB - Compliance - U - Password - v3.1	Password complexity and length requirements
Win - OIB - Compliance - U - Device Security - v3.1	Firewall, Antivirus/Antispyware, Secure Boot
Win - OIB - Compliance - U - Device Health - v3.1	BitLocker encryption, device health attestation
Win - OIB - Compliance - U - Defender for Endpoint - v3.1	MDE machine risk score threshold

Why four separate compliance policies instead of one?

OIB splits compliance into granular policies for the same reason it splits configuration profiles:

• Phased rollout — deploy Device Health and Device Security immediately, but hold the Password policy until you've communicated the forced password reset to users
• Different non-compliance actions — Password violations may warrant a grace period while BitLocker/Firewall violations are marked non-compliant immediately
• Targeted exclusions — the Defender for Endpoint policy only applies to devices onboarded to MDE; exclude devices without P2 licensing
• Faster diagnosis — if a device is non-compliant, four granular policies immediately show which category failed rather than requiring you to hunt through a single monolithic policy

If you have a single combined compliance policy from a previous deployment, retire it once the four OIB policies are validated and covering the same settings.

After import, review and adjust the OIB compliance policies against the requirements below. The OIB defaults may not match your compliance requirements exactly — verify each setting value.

Policy Type: Windows 10 and later

Policy Section	Setting Name	Required Value	NIST SP 800-171 Rev. 3	Non-Compliance Action
Device Health	Require BitLocker	Require	3.13.11, 3.8.1 (FIPS-validated cryptography; Protect media)	Mark non-compliant immediately.
Device Health	Require Secure Boot	Require	3.4.1 (Establish and maintain baseline configurations)	Mark non-compliant immediately.
System Security	Minimum OS version	10.0.22631.xxxx (Current - 2 N)	3.4.1, 3.14.1 (Maintain baseline; Flaw remediation)	Grace period: 3 days.
System Security	Firewall	Require	3.13.1 (Monitor, control, and protect communications)	Mark non-compliant immediately.
System Security	Antivirus / Antispyware	Require	3.14.2 (Provide protection from malicious code)	Mark non-compliant immediately.
System Security	Require a password to unlock mobile devices	Require (Minimum length: 8, Block simple passwords)	3.5.7, 3.5.8, 3.5.12 (Password complexity; Prohibit reuse; Replay-resistant authentication)	Mark non-compliant immediately.
Defender for Endpoint	Machine Risk Score	Medium or lower	3.14.6 (Monitor system security alerts)	Mark non-compliant immediately.

Password Policy Changes Force Password Resets

Since your machine has no way to know if your local account existing password is compliant, you will be forced to change your password the next time you login.

Windows Hello for Business Setup

For WHfB Intune policy configuration (Entra Join) and Cloud Kerberos Trust setup (Hybrid Join), see Windows Hello for Business Setup & Troubleshooting.

One OIB-specific step: in the imported OIB Account Protection policy, explicitly enable Use Cloud Trust for On-Prem Auth. This setting is separate from the WHfB policy itself and is easy to miss during an OIB import.

USB Device Control & SOC Alerting

In high-security environments, simply blocking write access via the Settings Catalog may not be enough. To mirror the capabilities of tools like McAfee HBSS, you can whitelist specific, company-approved USB drives (e.g., a SanDisk Cruzer) while generating real-time SOC alerts when unapproved devices are plugged in.

This requires splitting the workload: Intune acts as the enforcement engine, while Defender for Endpoint acts as the auditor.

Intune

Instead of basic Administrative Templates, use Endpoint Security > Attack Surface Reduction > Device Control. This relies on XML-based rule sets.

Step 1: The Approved Hardware XML Create an XML file to define your approved USB model using its Vendor ID (VID) and Product ID (PID). Here is an example targeting a common SanDisk Cruzer (VID: 0781, PID: 5567).

Note: In XML, the ampersand connecting the VID and PID must be escaped as &.

<Group Id="{aaa512fa-275f-40e2-a39c-b92c08b3e352}">
    <MatchType>MatchAny</MatchType>
    <DescriptorIdList>
        <HardwareId>USB\VID_0781&amp;PID_5567</HardwareId>
    </DescriptorIdList>
</Group>

Step 2: The Policy Rule XML Create a second XML file that blocks write/execute access for all removable media, but explicitly excludes the SanDisk group you just created. Crucially, it sets the block action to AuditDenied, which tells Defender to generate an alert.

<PolicyRule Id="{c544a991-5786-2819-949e-a032cb790d0e}">
    <Name>Block USB Writes, Allow SanDisk Cruzer</Name>
    <IncludedIdList>
        <GroupId>{9b28fae8-72f7-4267-a1a5-685f747a4345}</GroupId>
    </IncludedIdList>
    <ExcludedIdList>
        <GroupId>{aaa512fa-275f-40e2-a39c-b92c08b3e352}</GroupId>
    </ExcludedIdList>
    
    <Entry Id="{f8ddbbc5-8855-4776-a9f4-ee58c3a21414}">
        <Type>Deny</Type>
        <Options>0</Options>
        <AccessMask>6</AccessMask> 
    </Entry>
    
    <Entry Id="{7c518c86-38e5-40a9-86ee-e9f79f136817}">
        <Type>AuditDenied</Type>
        <Options>3</Options> 
        <AccessMask>6</AccessMask>
    </Entry>
</PolicyRule>

Step 3: Deployment Upload the Approved Hardware XML to the Reusable Settings tab in Intune. Then, create a new ASR policy (Profile: Device Control) and link your Policy Rule XML.

Defender for Endpoint

Intune does not send real-time alerts. To get the HBSS-style popup for the security team, you must configure a Custom Detection Rule in Microsoft Defender.

Navigate to Hunting > Advanced hunting and run the following KQL query:

// Detect blocked Removable Storage devices
DeviceEvents 
| where ActionType == "RemovableStoragePolicyTriggered" 
| extend parsed=parse_json(AdditionalFields) 
| extend RemovableStorageAccess = tostring(parsed.RemovableStorageAccess) 
| extend RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict) 
| extend MediaDescription = tostring(parsed.DeviceDescription)
| where RemovableStoragePolicyVerdict == "Deny"
| project Timestamp, DeviceName, InitiatingProcessAccountName, ActionType, RemovableStorageAccess, MediaDescription

Click Create detection rule in the top right corner and set the severity to Medium or High. This will automatically open an incident in your SOC dashboard whenever a user attempts to write to an unapproved USB drive.

Intune Compliance Policy — Shared Baseline

OIB includes four user-scoped compliance policies that validate the device state. These policies act as the signal used by Entra ID Conditional Access to block non-compliant devices from accessing protected data.

OIB Compliance Policy	What it validates
Win - OIB - Compliance - U - Password - v3.1	Password complexity and length requirements
Win - OIB - Compliance - U - Device Security - v3.1	Firewall, Antivirus/Antispyware, Secure Boot
Win - OIB - Compliance - U - Device Health - v3.1	BitLocker encryption, device health attestation
Win - OIB - Compliance - U - Defender for Endpoint - v3.1	MDE machine risk score threshold

Why four separate compliance policies instead of one?

OIB splits compliance into granular policies for the same reason it splits configuration profiles:

• Phased rollout — deploy Device Health and Device Security immediately, but hold the Password policy until you've communicated the forced password reset to users
• Different non-compliance actions — Password violations may warrant a grace period while BitLocker/Firewall violations are marked non-compliant immediately
• Targeted exclusions — the Defender for Endpoint policy only applies to devices onboarded to MDE; exclude devices without P2 licensing
• Faster diagnosis — if a device is non-compliant, four granular policies immediately show which category failed rather than requiring you to hunt through a single monolithic policy

If you have a single combined compliance policy from a previous deployment, retire it once the four OIB policies are validated and covering the same settings.

After import, review and adjust the OIB compliance policies against the requirements below. The OIB defaults may not match your compliance requirements exactly — verify each setting value.

Policy Type: Windows 10 and later

Policy Section	Setting Name	Required Value	Non-Compliance Action
Device Health	Require BitLocker	Require	Mark non-compliant immediately. (Blocks access to protected resources immediately)
Device Health	Require Secure Boot	Require	Mark non-compliant immediately.
System Security	Minimum OS version	10.0.22631.xxxx (Current - 2 N)	Grace period: 3 days. (Allows time for patching)
System Security	Firewall	Require	Mark non-compliant immediately.
System Security	Antivirus / Antispyware	Require	Mark non-compliant immediately.
System Security	Require a password to unlock mobile devices	Require (Minimum length: 8, Block simple passwords)	Mark non-compliant immediately. (Enforces NIST 3.5.7 & 3.5.8)
Defender for Endpoint	Machine Risk Score	Medium or lower	Mark non-compliant immediately. (Reacts to active threats)

Password Policy Changes Force Password Resets

Since your machine has no way to know if your local account existing password is compliant, you will be forced to change your password the next time you login.

Windows Hello for Business Setup

For WHfB Intune policy configuration (Entra Join) and Cloud Kerberos Trust setup (Hybrid Join), see Windows Hello for Business Setup & Troubleshooting.

One OIB-specific step: in the imported OIB Account Protection policy, explicitly enable Use Cloud Trust for On-Prem Auth. This setting is separate from the WHfB policy itself and is easy to miss during an OIB import.

Windows Update Rings

Windows Update for Business, managed through Intune Update rings for Windows 10 and later policies, controls when devices receive Windows quality updates (monthly security patches) and feature updates (major OS version changes). A single update ring for all devices creates operational risk in two directions: push too fast and a bad patch disables a fleet simultaneously; push too slow and known vulnerabilities stay open. A tiered ring strategy creates a controlled validation window — a bad patch that disrupts IT/Dev devices on day zero is caught and rolled back before it reaches General Ops on day seven.

Quality vs. Feature Update Deferrals

These are two independent deferral values in each ring:

• Quality update deferral: Controls delay of monthly security patches (Patch Tuesday). The short ring values below (0–10 days) apply here.
• Feature update deferral: Controls delay of major Windows version upgrades (e.g., 22H2 → 23H2). These are set to much longer values across all rings — the ring values below are not the right cadence for major OS changes, which require separate testing and a deliberate cutover.

Ring Strategy

Ring	Scope	Quality Deferral	Feature Deferral	Restart Behavior
IT & Dev	IT staff, administrators	0 days	30 days	Restart prompt after install
Pilot	Early adopters, department leads	3 days	60 days	Maintenance window restart
General Ops	City Hall and office staff	7 days	90 days	Maintenance window restart
Critical Ops	Public Safety, 24/7 services	10 days	180 days	Maintenance window restart (see note)

Assignments: Create one Entra ID security group per ring and assign it exclusively to that ring's policy. A device can only be in one update ring — if it matches multiple ring assignments, the highest-priority policy wins, which makes exclusive group assignment the safest approach.

Intune Policy Name	Assigned Group
WUR - IT and Dev	Update Ring - IT Dev
WUR - Pilot	Update Ring - Pilot
WUR - General Ops	Update Ring - General Ops
WUR - Critical Ops	Update Ring - Critical Ops

Intune Configuration

Navigate to Intune > Devices > Windows > Update rings for Windows 10 and later > Create profile.

IT & Dev Ring

Setting	Value	Rationale
Quality update deferral period (days)	0	IT staff are the canary — they see patches immediately
Feature update deferral period (days)	30	Enough time to read release notes and test critical apps
Microsoft product updates	Allow	Patches Office and Edge alongside Windows
Windows drivers	Allow	IT can absorb driver instability; helps surface hardware issues early
Automatic update behavior	Auto install and restart at scheduled time	IT machines can restart on a defined schedule
Active hours start	8 AM
Active hours end	7 PM
Deadline for quality updates	2 days	Ensures stragglers are patched within 48 hours
Deadline for feature updates	5 days
Grace period	0 days
Auto reboot before deadline	Yes	If device is idle at login screen, reboot
Option to pause Windows updates	Enable	Allow IT staff to pause during a critical incident

Pilot Ring

Setting	Value	Rationale
Quality update deferral period (days)	3	3-day soak after IT/Dev validates
Feature update deferral period (days)	60
Microsoft product updates	Allow
Windows drivers	Allow
Automatic update behavior	Auto install and restart at maintenance time
Active hours start	8 AM
Active hours end	7 PM
Deadline for quality updates	5 days
Deadline for feature updates	7 days
Grace period	1 day
Auto reboot before deadline	No
Option to pause Windows updates	Disable	Pilot users should not be pausing patches

General Ops Ring

Setting	Value	Rationale
Quality update deferral period (days)	7	Full week soak; covers any delayed Microsoft issue reports
Feature update deferral period (days)	90
Microsoft product updates	Allow
Windows drivers	Allow
Automatic update behavior	Auto install and restart at maintenance time
Active hours start	7 AM
Active hours end	7 PM
Deadline for quality updates	7 days
Deadline for feature updates	14 days
Grace period	2 days
Auto reboot before deadline	No
Option to pause Windows updates	Disable

Critical Ops Ring

Setting	Value	Rationale
Quality update deferral period (days)	10	10-day soak; patch is validated by all other rings before it arrives
Feature update deferral period (days)	180	Major OS changes require explicit coordination with command staff
Microsoft product updates	Allow
Windows drivers	Allow
Automatic update behavior	Auto install and restart at maintenance time	Restart occurs in the maintenance window (see active hours)
Active hours start	6 AM
Active hours end	11 PM	Maintenance window is 11 PM–6 AM — during shift overlap or low activity
Deadline for quality updates	14 days	Hard deadline: device will restart within the next maintenance window after day 14
Deadline for feature updates	30 days
Grace period	3 days
Auto reboot before deadline	No
Option to pause Windows updates	Enable	Allows command staff or device owner to hold a patch during an active incident; 35-day maximum enforced by Intune

Critical Ops: Change Management Required Before Rollout

First responders currently control their own reboots. The ring above configures maintenance-window restarts (11 PM–6 AM) rather than random forced reboots, but this still represents a change from the current self-managed model.

Before deploying this ring to Public Safety devices, coordinate with command staff to:

1. Communicate that reboots will occur automatically in the 11 PM–6 AM window — not during active shifts
2. Confirm shift patterns to verify the maintenance window is appropriate (overnight shifts may need adjustment)
3. Clarify the pause option: the "Option to pause Windows updates" setting allows command staff or a delegated IT liaison to hold a patch for up to 35 days during a critical incident, but this is not a permanent bypass
4. Identify dedicated vs. shift-shared devices — dedicated devices tied to a single officer can use the officer's schedule; shared devices (e.g., in-vehicle or at a desk) should use the maintenance window approach

The 14-day quality update deadline is a hard enforcement point: even if the device misses every maintenance window, it will restart at day 14. This deadline cannot be extended indefinitely without a separate policy exception.

Compliance Policy Alignment

The Compliance Policy earlier in this chapter sets Minimum OS version with a 3-day grace period. Devices in the Critical Ops ring defer quality updates for 10 days — meaning they will temporarily run an older patch level than the compliance requirement checks for, triggering a non-compliant state and potentially blocking Conditional Access for public safety staff.

Action required: Create a separate Compliance Policy targeting the Update Ring - Critical Ops group with a grace period of 14 days on the Minimum OS version setting. This matches the quality update deadline and prevents false non-compliance signals from blocking access to protected resources on actively-updated-but-deferred devices.

Shared PC Update Ring

The Shared PC update ring defined in Scenario: Shared PC Mode operates independently of this ring strategy. Shared PCs use a 0-day quality deferral with forced maintenance-window restarts — effectively IT & Dev urgency combined with Shared PC discipline. Do not assign shared PC devices to any of the four rings above; keep them in their dedicated Shared PC ring.

---

Wi-Fi Configuration

Intune provides built-in Wi-Fi configuration profiles — no PowerShell or netsh scripts needed for ongoing management. Deploy Wi-Fi profiles to configure devices to automatically connect to corporate wireless networks with the correct SSID, security type, and credentials.

netsh is for OOBE bootstrapping only

The netsh wlan export/add approach documented in Provisioning with Windows Autopilot is a one-time technician step during Autopilot provisioning — the device needs Wi-Fi connectivity before it has enrolled in Intune and received a Wi-Fi profile. For ongoing Wi-Fi management after enrollment, use the Intune Wi-Fi profiles documented below.

Creating a Wi-Fi Profile

Intune → Devices → Configuration → + Create → Templates → Wi-Fi

Platform: Windows 10 and later

Setting	WPA2-Personal (Shared Secret)	WPA2/WPA3-Enterprise (802.1X)
Wi-Fi type	Basic	Enterprise
Wi-Fi name (SSID)	The network name devices should connect to	Same
Connect automatically	Yes	Yes
Connect when network is not broadcasting	Yes (if the SSID is hidden)	Yes (if hidden)
Security type	WPA/WPA2-Personal	WPA/WPA2-Enterprise
Pre-shared key	Enter the shared password	N/A
EAP type	N/A	PEAP or EAP-TLS
Certificate	N/A	Reference a SCEP or PKCS certificate profile deployed via Intune
Trusted root CA	N/A	Reference the root CA certificate profile

For most organizations migrating from GPO-managed Wi-Fi with shared passwords, WPA2-Personal (Basic) is the starting point. The target state is WPA2/WPA3-Enterprise with certificate authentication — this eliminates shared passwords and provides per-device authentication, but requires a certificate infrastructure (Intune SCEP/PKCS with a Certificate Connector or cloud PKI).

Department-Specific Wi-Fi Targeting

Different departments, buildings, or device roles often require different Wi-Fi configurations — different SSIDs, different passwords, or different network segments. Use Intune assignment filters or device groups to target the right Wi-Fi profile to the right devices.

Example: Police and Fire department devices on different networks

Wi-Fi Profile	SSID	Assigned to	Filter / Group
Wi-Fi - Police D1 MDT	CPD-MDT-Secure	All Devices	Filter: device.deviceName -startsWith "CPDM-1"
Wi-Fi - Police D2 MDT	CPD-MDT-Secure	All Devices	Filter: device.deviceName -startsWith "CPDM-2"
Wi-Fi - CFD Battalion	CFD-Apparatus	All Devices	Filter: device.deviceName -startsWith "CFD-"
Wi-Fi - City General	CityNet-Corp	All Devices	No filter — all managed devices

Filters vs. device groups for Wi-Fi targeting

Intune filters are evaluated at policy delivery time and take effect on the next device sync — faster than waiting for dynamic group membership to recalculate. For department-specific Wi-Fi where the device naming convention is consistent, filters are the preferred targeting mechanism. Use dynamic device groups when the targeting logic requires attributes that filters don't support (e.g., Entra ID extension attributes).

CMMC Relevance

Wi-Fi configuration profiles satisfy AC.L2-3.1.16 (Wireless Access) — they enforce that managed devices connect only to authorized wireless networks with approved security settings. Combined with Conditional Access policies requiring compliant devices, this ensures CUI is only accessed over controlled wireless connections.