Open Intune Baseline Deployment

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.

OIB aggregates best practices into a unified set of granular JSON files deployable using the IntuneManagement tool by Mikael Karlsson. The procedure below 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.

Why OIB

A defensible deployment isn't "Intune deployed": it's a documented, enforceable, evidence-producing configuration baseline where every setting traces to a control. An empty Intune tenant has none of that work done; a tenant with Microsoft's stock Security Baseline applied has some of it but inherits two problems:

• Granularity collisions. Stock baselines bundle dozens of settings per policy. When targeted changes are needed (banner text, lock screen timeout, removable-media control scoped to sensitive data), the modify-by-customization workflow blurs which settings came from Microsoft and which from you, a problem the moment anyone asks "show me the baseline, then show me the deviations from it."
• Conflict reporting. Two baselines touching the same setting produce conflict in Intune, not override. A tenant with MS Security Baseline plus an overlay typically shows tens of conflicted settings per device, each one a question you can't cleanly answer.

OIB solves both with granular, single-purpose Settings Catalog policies, each tied to a specific control. Layer 1 below maps 21 OIB policies to specific controls; a reader (or an assessor) walks the table and confirms coverage row-by-row.

GCC High

CMMC Level 2 asks for a documented baseline that maps cleanly to the 110 NIST SP 800-171 Rev. 2 practices. Layer 1 maps 21 OIB policies to specific Rev. 2 practices; absence of any is a finding during a C3PAO assessment. Design for the question: "Show me your established Intune baseline, the mapping from each policy to a NIST 800-171 Rev. 2 practice, and a sample device on which the baseline is enforced — not just assigned." The Layered Deployment Strategy below produces the first two artifacts; the Intune Diagnostics chapter produces the third.

Commercial

Commercial tenants pursuing NIST SP 800-171 Rev. 3 (voluntarily, or because a non-DoD contract requires it) need the same artifact: a documented baseline mapping each policy to a Rev. 3 requirement, enforced and evidenced. Layer 1 maps the same 21 policies to Rev. 3 numbers in the NIST SP 800-171 Rev. 3 Control Mapping later in this chapter. Tenants with no formal framework still benefit: the same 21 policies are the highest-value security baseline (conflict-free, granular, and auditable) useful for cyber-insurance attestations or raising Microsoft Secure Score.

The mechanism: what Settings Catalog policies actually do

Settings Catalog policies are not "Intune-stored configuration" in any meaningful sense: they are CSP writes. Each row compiles to one or more nodes in the Configuration Service Provider tree Microsoft maintains at ./Vendor/MSFT/Policy/Config/.... Intune delivers the CSP write at sync time; the device's MDM client applies it to registry, WMI, or kernel surface depending on the CSP. The Intune admin center is the authoring surface; the CSP tree is the enforcement surface, and that's the layer an assessor can audit independently of Intune: via registry inspection at HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\... or the MDM Diagnostics Report (MdmDiagnosticsTool.exe).

This matters for two reasons that surface at audit time:

1. Drift detection. A device with a policy assigned but offline at sync time shows "compliant" in Intune yet has a stale CSP state on disk. The truthful answer about enforcement lives on the device, not in the portal, a fact the Intune Diagnostics chapter operationalizes for audit evidence.
2. Tattooing. Some CSP nodes are non-tattooing (un-assigning the policy removes the write); some tattoo (the write persists). This is per-CSP-node behavior, documented in the CSP reference. The Scenario: Shared PC Mode chapter is one extended example of why the distinction matters at audit time.

GCC High only: tool and sovereign-cloud setup before importing

OIB is designed for commercial Microsoft 365. The IntuneManagement tool defaults to Commercial Microsoft Graph endpoints; importing OIB JSON against a GCC High tenant without first reconfiguring the tool for Azure US Government is the single most common Step-1 failure mode (covered in Step 1 below). The GCC High Critical Modifications section later in this chapter then strips OIB settings that don't ship in the sovereign cloud (deep Windows diagnostic telemetry, certain Defender cloud-protection toggles, and SmartScreen URL reputation among them).

Layered Deployment Strategy

OIB ships ≈59 Settings Catalog policies plus 4 Compliance policies because it's an opinionated comprehensive baseline. In practice only ≈21 of these form the core baseline (for CMMC Level 2 these 21 are the mandatory minimum, and for a Commercial deployment they are the highest-value starting set) while the remainder are defense-in-depth hardening or situational policies that may not apply to a given environment. This guide structures the OIB deployment in three layers so an engagement can deliver the defensible core without scope-creeping into discretionary hardening.

OIB ships ≈59 Settings Catalog policies plus 4 Compliance policies because it's an opinionated comprehensive baseline. In practice only ≈21 of these form the core baseline (the highest-value starting set) while the remainder are defense-in-depth hardening or situational policies that may not apply to a given environment. This guide structures the OIB deployment in three layers so an engagement can deliver the defensible core without scope-creeping into discretionary hardening.

Layer 1: Core Baseline (21 policies)

Every environment needs these: they're the defensible core of the baseline. The control reference shown in each table below is the NIST SP 800-171 Rev. 2 number as a common anchor; for the precise per-framework mapping, see the CMMC Control Mapping Matrix (GCC High) and the NIST SP 800-171 Rev. 3 Control Mapping (Commercial) later in this chapter. For a GCC High / CMMC engagement, the absence of any of these is a finding during a C3PAO assessment; for Commercial, they are the highest-value controls you'd be hard-pressed to justify omitting.

Every environment needs these: they're the defensible core of the baseline. The control reference shown in each table below is the NIST SP 800-171 Rev. 2 number as a common anchor; for the precise mapping, see the NIST SP 800-171 Rev. 3 Control Mapping later in this chapter. These are the highest-value controls you'd be hard-pressed to justify omitting.

The 21 policies are presented in two tables matching the Intune admin center's blade layout: Configuration (Endpoint Security and Settings Catalog policies surfaced under Devices → Configuration) and Compliance (the four OIB Compliance policies under Devices → Compliance). Each table is alphabetical by full policy name to match the portal's sort order, so a reader scanning their tenant can find the corresponding row at the same alphabetic position.

Delivery across management modes

These 21 policies assume Intune MDM-enrolled devices. Fleets that include MDE-attached workstations or Windows Servers (which can't fully enroll in Intune) deliver the 12 Endpoint Security policies differently: some over the Defender for Endpoint security-settings channel, the rest by GPO, with two server-tuned forks. See Defender for Endpoint § delivery matrix for the per-policy mapping.

Phishing-resistant MFA implementation choice

The list below uses Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2 as the Layer 1 implementation of CMMC 3.5.3 (multi-factor authentication). WHfB is the recommended Microsoft-stack default and the path of least resistance for a Windows fleet, but 3.5.3 itself is implementation-agnostic: FIDO2 security keys or PIV+CBA smart cards satisfy the same control. If your environment has an existing investment in one of those alternatives, replace the WHfB policy with the appropriate Intune profile (FIDO2 security key sign-in policy, or certificate-based authentication policy). The Conditional Access policies in Chapter 14 enforce phishing-resistant MFA at the network-access layer regardless of which Windows-side method is deployed.

Phishing-resistant MFA implementation choice

The list below uses Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2 as the Layer 1 implementation of multi-factor authentication. WHfB is the recommended Microsoft-stack default and the path of least resistance for a Windows fleet, but the control itself is implementation-agnostic: FIDO2 security keys or PIV+CBA smart cards satisfy the same requirement. If your environment has an existing investment in one of those alternatives, replace the WHfB policy with the appropriate Intune profile (FIDO2 security key sign-in policy, or certificate-based authentication policy). The Conditional Access policies in Chapter 14 enforce phishing-resistant MFA at the network-access layer regardless of which Windows-side method is deployed.

Baseline configuration (11 policies, 10 for cloud-only tenants)

OIB Settings Catalog imports that deploy as-is: no per-tenant authoring, no decisions. All surface under Devices → Configuration in the Intune admin center.

#	Policy	NIST 800-171 Rev. 2 control	Source
1	Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7	3.4.6 (least functionality)	OIB Settings Catalog
2	Win - OIB - ES - Defender Antivirus - D - AV Configuration - v3.3	3.14.2 (malicious code protection)	OIB Settings Catalog
3	Win - OIB - ES - Defender Antivirus - D - Security Experience - v3.3	3.4.5 (Tamper Protection: restrict nonessential programs)	OIB Settings Catalog
4	Win - OIB - ES - Encryption - D - BitLocker (OS Disk) - v3.7	3.13.11 / 3.8.6 (cryptographic protection of CUI)	OIB Settings Catalog
5	Win - OIB - ES - Windows Firewall - D - Firewall Configuration - v3.1	3.13.1 (boundary protection)	OIB Settings Catalog
6	Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2	3.5.3 (multi-factor authentication)	OIB Settings Catalog
7	Win - OIB - SC - Device Security - D - Audit and Event Logging - v3.7	3.3.1 / 3.3.2 (audit events)	OIB Settings Catalog
8	Win - OIB - SC - Device Security - D - Login and Lock Screen - v3.1	3.1.10 (session lock)	OIB Settings Catalog
9	Win - OIB - SC - Device Security - U - Power and Device Lock - v3.6	3.1.10 (session lock)	OIB Settings Catalog
10	Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5	3.5.3 (multi-factor authentication: hybrid SSO trust to on-prem AD; skip if cloud-only)	OIB Settings Catalog
11	Win - OIB - SC - Windows Update for Business - D - Reports and Telemetry - v3.0	3.1.3 (control flow of CUI: restrict telemetry)	OIB Settings Catalog

Local administrator account (3 policies, choose Option A or B)

These three policies govern the local admin account and must be deployed as a set: pick one column per device, don't mix them. Option A is the default: least disruptive for brownfield fleets, works on any Windows version, and keeps the built-in Administrator (LAPS-managed). Option B is Microsoft's recommended posture for uniform Windows 11 24H2+ fleets: it retires the built-in Administrator for a custom, tamper-protected managed account.

#	Policy	Option A: default (brownfield, any Windows)	Option B: hardened (24H2+ only)
12	Windows LAPS IA.L2-3.5.7, AC.L2-3.1.5	Win - OIB - ES - Windows LAPS - D - LAPS Configuration - v3.1: manages + rotates the built-in Administrator, backed up to Entra ID	Win - OIB - ES - Windows LAPS - D - LAPS Configuration (24H2+) - v3.6: Automatic Account Management creates + manages a custom WLapsAdmin
13	Local Administrators AC.L2-3.1.5 / 3.1.6 / 3.1.7	Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7: Replace → built-in Administrator + Tier 1 break-glass	Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7 (same policy): Replace → WLapsAdmin
14	Local Security Policies AC.L2-3.1.9, AC.L2-3.1.7, SC.L2-3.13.15	Win - OIB - SC - Device Security - D - Local Security Policies - v3.0: built-in Administrator stays enabled; banner + NTLM/SMB/UAC hardening	Win - OIB - SC - Device Security - D - Local Security Policies (24H2+) - v3.6: disables the built-in Administrator

Option B is a matched set: deploy all three (24H2+) variants together. The (24H2+) LSP disables the built-in Administrator, so without the (24H2+) LAPS provisioning WLapsAdmin the device has no usable local admin (recover via WinRE/hypervisor console). Mixed fleets: scope each (24H2+) policy with osVersion >= 10.0.26100; because only one Local Administrators policy can apply per device, you need two: one per target account. Full settings: Appendix B § Windows LAPS (24H2+) and § Local Security Policies (24H2+).

Deploying Option B to devices already in service

Azure VMs rename the built-in Administrator at provisioning time (find it by SID: Get-LocalUser | Where-Object { $_.SID.Value.EndsWith('-500') }). Put that name in the row-13 policy alongside WLapsAdmin. Then validate one device by assigning rows 12 and 13 and verifying before assigning row 14:

• the LAPS policy landed: Get-ItemProperty 'HKLM:\Software\Microsoft\Policies\LAPS'
• the account exists: Get-LocalUser WLapsAdmin (a transient 65000 error on row 13 is expected until LAPS creates it; the setting self-heals on the next evaluation)
• the password is retrievable from the device's Local administrator password page in the Intune portal
• then assign row 14: the built-in Administrator flips to disabled and the sign-in banner appears

Remaining devices can take all three policies at once; LAPS creates and tamper-protects its account independently.

Manual creations (3 policies)

Authored once per tenant, not part of the OIB Settings Catalog import because each is keyed to tenant-specific values. All surface under Devices → Configuration.

#	Policy	NIST 800-171 Rev. 2 control	Source
15	Win - Custom - ES - Defender for Endpoint Onboarding	3.14.3 (alert monitoring)	Manual (tenant-specific onboarding blob)
16	Win - Custom - ES - Device Control / Removable Media	3.8.7 (removable media control)	Manual (Reusable Settings + Device Control profile)
17	Win - Custom - ES - Exploit Protection	3.14.1 (flaw remediation)	Manual (Settings Catalog: Exploit Guard category)

Compliance policies (4)

User-scoped device compliance policies under Devices → Compliance. These act as the signal Conditional Access uses to gate access to protected resources.

#	Policy	NIST 800-171 Rev. 2 control	Source
18	Win - OIB - Compliance - U - Defender for Endpoint - v3.1	3.14.3 (alert monitoring)	OIB Compliance
19	Win - OIB - Compliance - U - Device Health - v3.1	3.13.11 / 3.8.6 (cryptographic protection)	OIB Compliance
20	Win - OIB - Compliance - U - Device Security - v3.1	3.13.1 + 3.14.2 (boundary protection, malicious code)	OIB Compliance
21	Win - OIB - Compliance - U - Password - v3.1	3.5.7 / 3.5.8 (password complexity, reuse)	OIB Compliance

Total: 21 policies: 11 baseline configuration (10 for cloud-only) + 3 local administrator account + 3 manual creations + 4 compliance. This is the consultant-deliverable core baseline, the CMMC L2 minimum for GCC High, and the recommended Commercial starting set.

Total: 21 policies: 11 baseline configuration (10 for cloud-only) + 3 local administrator account + 3 manual creations + 4 compliance. This is the consultant-deliverable core baseline and the recommended Commercial starting set.

Layer 2: Defense-in-Depth (33 policies, follow-on)

Recommended hardening above the Layer 1 core, for GCC High above CMMC minimums (not required to pass a C3PAO assessment); for Commercial, optional defense-in-depth. Suitable as a follow-on engagement after the Layer 1 baseline operates cleanly:

Recommended hardening above the Layer 1 core: optional defense-in-depth. Suitable as a follow-on engagement after the Layer 1 baseline operates cleanly:

• Microsoft Edge family (5 policies, D + U scopes): security, updates, extensions, password management, profiles/sign-in/sync
• Microsoft Office family (4 policies): D-scope security and updates; U-scope config and security
• OneDrive (2): D-scope and U-scope tenant-only sync configuration

• Defender Antivirus Update Rings (3): Pilot/UAT/Production rollout management for AV signatures (operational risk management; default Defender automatic update satisfies CMMC 3.14.4 without these rings)

• Defender Antivirus Update Rings (3): Pilot/UAT/Production rollout management for AV signatures (operational risk management; default Defender automatic update already covers signature currency without these rings)

• Device Security hardening (~11): Administrator Protection, Config Refresh, Enhanced Phishing Protection, Printing, Remote Desktop Services and RPC, Script File Associations, Security Hardening, Timezone, User Rights, Windows Package Manager, Device Guard / Credential Guard / HVCI
• Microsoft Accounts, Microsoft Store - D: corporate identity and app store surface controls
• Credential Management Passwordless, Windows Apps In-Box Removal, Defender AV Additional Configuration: modern auth, attack-surface reduction, AV layer extras
• Delivery Optimisation, Feature Configuration, Settings Sync: Windows Update and modern Windows experience tuning

Layer 3: Situational / Opt-In (13 policies)

Deploy only if the underlying feature is in scope:

Policy	Skip if...
Win - OIB - SC - Internet Explorer (Legacy) - D - Security - v3.1.1	You don't have IE-mode site requirements
Win - OIB - SC - Device Security - D - Windows Subsystem for Linux - v3.2	WSL is not allowed
Win - OIB - SC - Device Security - U - Windows Sandbox - v3.4	Sandbox is not allowed
Win - OIB - ES - Encryption - U - Personal Data Encryption - v3.4	BitLocker alone meets your encryption posture
Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (Audit Mode) - v3.1	Past initial validation phase (this replaces Layer 1's ASR L2 temporarily, doesn't add to it)
Win - OIB - SC - Device Security - D - Location and Privacy - v3.2	You're already managing this elsewhere
Win - OIB - SC - Device Security - U - Windows Spotlight and Org Messages - v3.0	Spotlight is already disabled by other means
Win - OIB - SC - Microsoft Edge - U - User Experience - v3.7	Browser cosmetics aren't in scope
Win - OIB - SC - Microsoft Store - U - Configuration - v3.3	Users have no Store access
Win - OIB - SC - Windows User Experience - U - Copilot - v3.6	Copilot is not in use

Recommended deployment

For a core baseline engagement (CMMC L2, NIST 800-171 Rev. 3, or general hardening): deploy Layer 1 only (21 policies; 20 if your tenant is cloud-only and skips Cloud Kerberos Trust). For CMMC, the remaining OIB policies are out of scope for assessment; for Commercial, they're optional hardening, in either case they can be addressed in a follow-on engagement or as client-led projects after the baseline is validated.

For a core baseline engagement (NIST 800-171 Rev. 3 or general hardening): deploy Layer 1 only (21 policies; 20 if your tenant is cloud-only and skips Cloud Kerberos Trust). The remaining OIB policies are optional hardening; they can be addressed in a follow-on engagement or as client-led projects after the baseline is validated.

For a comprehensive defense-in-depth deployment: deploy Layer 1 + Layer 2 (~53 policies), then evaluate Layer 3 per environment.

Both approaches use the same import procedure below: the difference is which JSON files you select in the Bulk Import dialog at Step 5. For a Layer 1–only deployment, copy the Layer 1 OIB JSON filenames listed above into a separate folder and point the Bulk Import dialog at that folder; the OIB Compliance imports come from the CompliancePolicies subfolder of the OIB ZIP, the manual creations are authored separately per their appendix sections.

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, as 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 the policies for your deployment scope. For a core baseline (CMMC L2, or a Commercial NIST 800-171 Rev. 3 starting set), select only the Layer 1 JSON files. For a comprehensive defense-in-depth deployment, select Layer 1 + Layer 2 (and Layer 3 entries that apply to your environment). You can also import everything and remove individual policies later, but a clean tenant policy list is easier to maintain and easier for an assessor to review than a list of unassigned policies.
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

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
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

1. Open the Microsoft Intune admin center (intune.microsoft.com)
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

• All tenants: Customize the settings in the 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

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.

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 targets the Commercial cloud; apply these changes for GCC High / CMMC.

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	Win - Custom - ES - Exploit Protection (manually created: Settings Catalog policy)	Verify DEP, ASLR (BottomUp + ForceRelocateImages), SEHOP, and CFG enforced system-wide and that DisallowExploitProtectionOverride is set.	3.14.1 (Identify and correct system flaws)	PowerShell Get-ProcessMitigation -System; Windows Security app shows "managed by your organization."
Defender for Endpoint (EDR)	Win - Custom - ES - Defender for Endpoint Onboarding (manually created: onboarding blob is tenant-specific)	Verify Auto-onboard via Intune Connector is active.	3.14.3 (Monitor system security alerts and advisories)	MDE Device Inventory; Intune EDR Onboarding Status.
Defender Antivirus (AV Configuration)	Win - OIB - ES - Defender Antivirus - D - AV Configuration - v3.3	Verify Real-time protection: On, Cloud-delivered protection: High, scan schedule, and any role-specific exclusions.	3.14.2 (Provide protection from malicious code)	MDE Antivirus Report; Local Get-MpPreference.
Windows Firewall	Win - OIB - ES - Windows Firewall - D - Firewall Configuration - v3.1	Verify all three profiles (Domain, Private, Public) set to Block inbound with Outbound: Allow.	3.13.1 (Monitor, control, and protect communications at boundaries)	Intune Firewall Status Report; Local Get-NetFirewallProfile.
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 the 21-character passphrase, set rotation to 7 days, and manage the built-in Administrator account. For uniform Windows 11 24H2+ fleets that want Automatic Account Management and built-in Administrator disable, see Option B under Local administrator account options.	3.1.5, 3.5.7 (Least privilege; Password management)	Entra ID LAPS Audit Logs; Intune Device Local Admin status.
Local Administrators	Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7	Verify the policy is set to Replace mode and the Members list is restricted to the built-in Administrator (LAPS-managed, Option A default) plus your designated Tier 1 break-glass account. (Under Option B / (24H2+), the Replace member is WLapsAdmin instead, see Local administrator account options.)	3.1.5, 3.1.6, 3.1.7 (Least privilege; non-privileged account use; privileged functions)	Intune Profile Status; Local Get-LocalGroupMember -Group "Administrators".
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. The Layer 1 default keeps the built-in Administrator account enabled. For uniform Windows 11 24H2+ fleets that want it disabled (with a LAPS-managed custom admin replacement), see Option B under Local administrator account options.	3.1.9, 3.1.7, 3.13.15 (Privacy and security notices; privileged functions via UAC; session authenticity via SMB/NTLM hardening)	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 (Access restrictions for changes)	MDE Security Center (Tamper Protection status).
Removable Media	Win - Custom - ES - Device Control / Removable Media (manually created: keyed to approved hardware IDs unique to each tenant)	Verify the policy denies 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.
Audit and Event Logging	Win - OIB - SC - Device Security - D - Audit and Event Logging - v3.7	Verify Object Access, Account Logon, and Privilege Use audit subcategories are enabled with both Success and Failure recording, and that maximum log size is sufficient (≥ 200 MB) for retention.	3.3.1, 3.3.2 (Create audit logs; Trace user actions)	Intune Profile Status; Local auditpol /get /category:*.

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, so 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.

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, Authenticator Management), 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	Win - Custom - ES - Exploit Protection (manually created: Settings Catalog policy)	Verify DEP, ASLR (BottomUp + ForceRelocateImages), SEHOP, and CFG enforced system-wide and that DisallowExploitProtectionOverride is set.	3.14.1 (Identify and correct system flaws)	PowerShell Get-ProcessMitigation -System; Windows Security app shows "managed by your organization."
Defender for Endpoint (EDR)	Win - Custom - ES - Defender for Endpoint Onboarding (manually created: onboarding blob is tenant-specific)	Verify Auto-onboard via Intune Connector is active.	3.14.3 (Monitor system security alerts and advisories)	MDE Device Inventory; Intune EDR Onboarding Status.
Defender Antivirus (AV Configuration)	Win - OIB - ES - Defender Antivirus - D - AV Configuration - v3.3	Verify Real-time protection: On, Cloud-delivered protection: High, scan schedule, and any role-specific exclusions.	3.14.2 (Provide protection from malicious code)	MDE Antivirus Report; Local Get-MpPreference.
Windows Firewall	Win - OIB - ES - Windows Firewall - D - Firewall Configuration - v3.1	Verify all three profiles (Domain, Private, Public) set to Block inbound with Outbound: Allow.	3.13.1 (Monitor, control, and protect communications at boundaries)	Intune Firewall Status Report; Local Get-NetFirewallProfile.
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 (Multi-Factor Authentication; Authenticator Management)	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 the 21-character passphrase, set rotation to 7 days, and manage the built-in Administrator account. For uniform Windows 11 24H2+ fleets that want Automatic Account Management and built-in Administrator disable, see Option B under Local administrator account options.	3.1.5, 3.5.7 (Least privilege; Password management)	Entra ID LAPS Audit Logs; Intune Device Local Admin status.
Local Administrators	Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7	Verify the policy is set to Replace mode and the Members list is restricted to the built-in Administrator (LAPS-managed, Option A default) plus your designated Tier 1 break-glass account. (Under Option B / (24H2+), the Replace member is WLapsAdmin instead, see Local administrator account options.)	3.1.5, 3.1.6, 3.1.7 (Least privilege; non-privileged account use; privileged functions)	Intune Profile Status; Local Get-LocalGroupMember -Group "Administrators".
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. The Layer 1 default keeps the built-in Administrator account enabled. For uniform Windows 11 24H2+ fleets that want it disabled (with a LAPS-managed custom admin replacement), see Option B under Local administrator account options.	3.1.9, 3.1.7, 3.13.15 (System Use Notification; privileged functions via UAC; session authenticity via SMB/NTLM hardening)	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 (Access Restrictions for Change)	MDE Security Center (Tamper Protection status).
Removable Media	Win - Custom - ES - Device Control / Removable Media (manually created: keyed to approved hardware IDs unique to each tenant)	Verify the policy denies all write access while allowing approved hardware IDs.	3.8.1, 3.8.7 (Media Storage; Media Use)	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 (Device 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 (Information Flow Enforcement)	Intune Profile Status.
Audit and Event Logging	Win - OIB - SC - Device Security - D - Audit and Event Logging - v3.7	Verify Object Access, Account Logon, and Privilege Use audit subcategories are enabled with both Success and Failure recording, and that maximum log size is sufficient (≥ 200 MB) for retention.	3.3.1, 3.3.2 (Create audit logs; Trace user actions)	Intune Profile Status; Local auditpol /get /category:*.

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, so 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.12 (Password management; Authenticator management)	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.

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 Ultra USB 3.0) 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 Ultra USB 3.0 (VID: 0781, PID: 5581).

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_5581</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 Ultra USB 3.0</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.

Application Control: App Control for Business

Restricting standard users to managed software (LAPS + Local Administrators, Layer 1) and monitoring what gets installed (Discovered apps) satisfies the baseline expectation for CM controls 3.4.8 (deny/permit-by-exception) and 3.4.9 (user-installed software). App Control for Business is the defense-in-depth upgrade: it turns "users shouldn't install unapproved software" into "unapproved software cannot run." It is the current name for Windows Defender Application Control (WDAC), and is supported in US Government clouds (Government cloud support).

This is a Layer 2 (defense-in-depth) item, not a Layer 1 compliance-mandatory policy, but for a CUI environment it is the single strongest control for application allow-listing, and the one a security-conscious customer will ask about.

The managed-installer model

Allow-listing has always foundered on maintenance: hand-authoring a rule for every approved binary is unsustainable. App Control for Business solves this with a managed installer: you designate the Intune Management Extension as a known-good deployment source, and every app Intune deploys is automatically tagged as trusted. The allow-list maintains itself: you approve software the way you already do (deploy it through Intune), and App Control trusts it.

1. Enable the managed installer. Intune admin center → Endpoint security → App Control for Business → Managed installer tab → Create, then enable Intune Management Extension as Managed Installer and assign to a device group. From this point, apps Intune deploys are tagged as installed by a trusted source (managed installers).

   • No retroactive tagging: apps installed before the managed installer was enabled are not tagged. Plan to redeploy or explicitly allow pre-existing apps, or they are blocked once enforcement is on.

2. Create the App Control policy: audit mode first. Endpoint security → App Control for Business → App Control for Business tab → Create Policy, using Built-in controls (no XML required):

   • Enable trust of Windows components and store apps → set to Audit only to start.
   • Trust apps from managed installers → trusts everything Intune deployed.
   • Optionally Trust apps with a good reputation (Microsoft Intelligent Security Graph) to reduce friction for common reputable apps.

3. Review, then enforce. In audit mode nothing is blocked: events log locally and surface in Microsoft Defender for Endpoint Advanced Hunting, so you can see exactly what would have been blocked. Once the audit set is clean (every legitimate app is either managed-installer-tagged or explicitly allowed), flip Enable trust of Windows components and store apps from Audit only to enforced.

Audit mode is mandatory before enforcement

Flipping App Control straight to enforce on a brownfield fleet will block legitimate line-of-business apps deployed before the managed installer existed, including, on a CMMC fleet, the legacy DoD applications users depend on. Run audit mode for at least 2–4 weeks, work the Advanced Hunting results to zero unexpected blocks, then enforce. Removing a misconfigured App Control policy also requires care: replace it with an Allow /* policy before deleting to avoid boot-stop failures (delete guidance).

How it maps to CMMC

Control	Layer 1 only	With App Control
3.4.8 (Authorized software: deny/permit by exception)	Policy + monitoring (Discovered apps); deny-by-default not technically enforced	Permit-by-exception enforced: only managed-installer-tagged or explicitly allowed apps run
3.4.9 (Control & monitor user-installed software)	Standard users can't machine-install; per-user installs caught only by monitoring	Per-user unapproved binaries are blocked from running, not just detected

App Control doesn't replace the Layer 1 controls: least privilege (no local admin) and Discovered-apps monitoring remain the baseline. It completes them: least privilege stops the install, monitoring sees what slips through, and App Control stops unapproved code from executing at all.

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 check expects, triggering false non-compliance.

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.