Skip to main content

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 for CMMC​

CMMC Level 2 doesn't ask for "Intune deployed." It asks for a documented, enforceable, evidence-producing configuration baseline that maps cleanly to 110 NIST SP 800-171 Rev. 2 practices. 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 CMMC-specific changes are needed (banner text, lock screen timeout, removable-media control scoped to CUI), the modify-by-customization workflow blurs which settings came from Microsoft and which from you — a problem when an assessor 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 a CMMC overlay typically shows tens of conflicted settings per device — each one a discussion with the assessor.

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 NIST 800-171 Rev. 2 practices; an assessor walks the table and confirms coverage row-by-row.

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 CMMC-relevant reasons:

  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.

What an assessor asks​

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

One GCC-High wrinkle to know 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. For CMMC Level 2 specifically, only ≈21 of these are strictly mandatory — 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 a CMMC L2 engagement can deliver the audit-defensible minimum without scope-creeping into discretionary hardening.

Layer 1 — CMMC-Mandatory Baseline (21 policies)​

Every CMMC L2 environment needs these. Each policy maps to a specific NIST SP 800-171 Rev. 2 control; absence of any is a finding during a C3PAO assessment. The policies below correspond directly to the CMMC Control Mapping Matrix further in this chapter.

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.

Phishing-resistant MFA implementation choice

The list below uses Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration 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.

Configuration policies (17)​

Endpoint Security and Settings Catalog policies. Both surface under Devices → Configuration in the Intune admin center.

PolicyNIST 800-171 controlSource
Win - Custom - ES - Defender for Endpoint Onboarding3.14.3 (alert monitoring)Manual (tenant-specific onboarding blob)
Win - Custom - ES - Device Control / Removable Media3.8.7 (removable media control)Manual (Reusable Settings + Device Control profile)
Win - Custom - ES - Exploit Protection3.14.1 (flaw remediation)Manual (Settings Catalog — Exploit Guard category)
Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2)3.4.6 (least functionality)OIB Settings Catalog
Win - OIB - ES - Defender Antivirus - D - AV Configuration3.14.2 (malicious code protection)OIB Settings Catalog
Win - OIB - ES - Defender Antivirus - D - Security Experience3.4.5 (Tamper Protection — restrict nonessential programs)OIB Settings Catalog
Win - OIB - ES - Encryption - D - BitLocker (OS Disk)3.13.11 / 3.8.6 (cryptographic protection of CUI)OIB Settings Catalog
Win - OIB - ES - Local Group Membership - D - Local Administrators3.1.5 (least privilege)OIB Settings Catalog
Win - OIB - ES - Windows Firewall - D - Firewall Configuration3.13.1 (boundary protection)OIB Settings Catalog
Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration3.5.3 (multi-factor authentication)OIB Settings Catalog
Win - OIB - ES - Windows LAPS - D - LAPS Configuration3.1.5 (least privilege)OIB Settings Catalog
Win - OIB - SC - Device Security - D - Audit and Event Logging3.3.1 / 3.3.2 (audit events)OIB Settings Catalog
Win - OIB - SC - Device Security - D - Local Security Policies3.1.9 (banner) + general security hardeningOIB Settings Catalog
Win - OIB - SC - Device Security - D - Login and Lock Screen3.1.10 (session lock)OIB Settings Catalog
Win - OIB - SC - Device Security - U - Power and Device Lock3.1.10 (session lock)OIB Settings Catalog
Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust3.5.3 (multi-factor authentication — hybrid SSO trust to on-prem AD; skip if cloud-only)OIB Settings Catalog
Win - OIB - SC - Windows Update for Business - D - Reports and Telemetry3.1.3 (control flow of CUI — restrict telemetry)OIB Settings Catalog

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.

PolicyNIST 800-171 controlSource
Win - OIB - Compliance - U - Defender for Endpoint3.14.3 (alert monitoring)OIB Compliance
Win - OIB - Compliance - U - Device Health3.13.11 / 3.8.6 (cryptographic protection)OIB Compliance
Win - OIB - Compliance - U - Device Security3.13.1 + 3.14.2 (boundary protection, malicious code)OIB Compliance
Win - OIB - Compliance - U - Password3.5.7 / 3.5.8 (password complexity, reuse)OIB Compliance

Total: 21 policies — 17 Configuration (14 OIB Settings Catalog imports + 3 manual creations) and 4 Compliance (OIB Compliance imports). This is the consultant-deliverable for a CMMC L2 baseline engagement.

Optional advanced posture — (24H2+) LAPS + LSP, deployed as a matched pair

The Layer 1 default above manages the built-in Administrator account on every device. For uniform Windows 11 24H2+ fleets that want a stronger posture, OIB ships a coupled pair of (24H2+) variants:

  • Win - OIB - ES - Windows LAPS - D - LAPS Configuration (24H2+) uses the Automatic Account Management feature (introduced in Windows 11 24H2) to create and manage a custom local administrator account on each device.
  • Win - OIB - SC - Device Security - D - Local Security Policies (24H2+) correspondingly disables the built-in Administrator, since LAPS has provisioned a replacement that's password-rotated and Entra-backed.

Treat the two as a matched pair. Do not deploy LSP (24H2+) without also deploying LAPS (24H2+) on the same device — disabling the built-in Administrator without a LAPS-managed replacement leaves the device with no local admin account for emergency recovery. Recovery from that state requires WinRE console or re-enabling the account through a separate Intune policy after the fact.

For mixed fleets (some pre-24H2 devices), assign each (24H2+) policy with osVersion >= 10.0.26100 and let the Layer 1 default cover the older endpoints. See Appendix B § Windows LAPS (24H2+) and Appendix B § Local Security Policies (24H2+) for the full settings.

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

Recommended hardening above CMMC minimums but not required for assessment pass. 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)
  • 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:

PolicySkip if...
Win - OIB - SC - Internet Explorer (Legacy) - D - SecurityYou don't have IE-mode site requirements
Win - OIB - SC - Device Security - D - Windows Subsystem for LinuxWSL is not allowed
Win - OIB - SC - Device Security - U - Windows SandboxSandbox is not allowed
Win - OIB - ES - Encryption - U - Personal Data EncryptionBitLocker alone meets your encryption posture
Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (Audit Mode)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 PrivacyYou're already managing this elsewhere
Win - OIB - SC - Device Security - U - Windows Spotlight and Org MessagesSpotlight is already disabled by other means
Win - OIB - SC - Microsoft Edge - U - User ExperienceBrowser cosmetics aren't in scope
Win - OIB - SC - Microsoft Store - U - ConfigurationUsers have no Store access
Win - OIB - SC - Windows User Experience - U - CopilotCopilot is not in use

For a CMMC L2 baseline engagement: deploy Layer 1 only (21 policies; 20 if your tenant is cloud-only and skips Cloud Kerberos Trust). The remaining OIB policies are out of scope for CMMC and 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).
  1. 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

Step 4 — Sign in and grant consent​

  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.
  1. 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.
  2. 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 the policies for your deployment scope. For a CMMC L2 baseline engagement, 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
SymptomCauseFix
"No policies found" or empty import listSelected 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 openShorten 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 filesRun 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 formatDownload the latest version of both the IntuneManagement tool and OIB
"Insufficient privileges" errorAccount lacks required role or consent was not grantedEnsure 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 policyOIB JSON references a setting or template not available in your tenant's cloud or license tierSkip that policy and create it manually using the OIB JSON as a reference
Duplicate policy namesYou ran the import twiceDelete the duplicates from Intune before re-importing
MSAL / token errors in GCC HighSovereign cloud not selected before sign-inClose the tool, reopen, verify Azure US Government is set in File → Settings → MSAL, then sign in again
Consent prompt does not appearBrowser popup blocked or consent already grantedCheck 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 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).

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 ScopeProfile Source / FilenameCritical Setting VerificationNIST 800-171 ControlAudit Method
Attack Surface Reduction - DWin - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7Ensure "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 ProtectionWin - 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.3Verify 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 FirewallWin - OIB - ES - Windows Firewall - D - Firewall Configuration - v3.1Verify 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.7Verify 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 - DWin - 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 LAPSWin - OIB - ES - Windows LAPS - D - LAPS ConfigurationConfigure Windows LAPS. Enable backup to Entra ID, enforce 14+ characters, set rotation to 30 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 the optional (24H2+) matched pair under Layered Deployment Strategy.3.1.1, 3.1.5 (Limit access; Least privilege)Entra ID LAPS Audit Logs; Intune Device Local Admin status.
Local AdministratorsWin - OIB - ES - Local Group Membership - D - Local AdministratorsVerify the policy is set to Replace mode and the Members list is restricted to Administrator (LAPS-managed) plus your designated Tier 1 break-glass account.3.1.5 (Employ the principle of least privilege)Intune Profile Status; Local Get-LocalGroupMember -Group "Administrators".
Local SecurityWin - OIB - SC - Device Security - D - Local Security PoliciesEdit 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 the optional (24H2+) matched pair under Layered Deployment Strategy.3.1.9 (Provide privacy and security notices)Local Registry: HKLM\SOFTWARE\...\Policies\System\LegalNoticeText.
Security ExperienceWin - OIB - ES - Defender Antivirus - D - Security Experience - v3.3Ensure Hide Windows Security Notification Area and Enable Tamper Protection are enforced.3.4.5 (Restrict nonessential programs)MDE Security Center (Tamper Protection status).
Removable MediaWin - 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 ScreenWin - 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 TelemetryWin - OIB - SC - Windows Update for Business - D - Reports and Telemetry - v3.0Set "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 LoggingWin - OIB - SC - Device Security - D - Audit and Event Logging - v3.7Verify 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 PolicyWhat it validates
Win - OIB - Compliance - U - Password - v3.1Password complexity and length requirements
Win - OIB - Compliance - U - Device Security - v3.1Firewall, Antivirus/Antispyware, Secure Boot
Win - OIB - Compliance - U - Device Health - v3.1BitLocker encryption, device health attestation
Win - OIB - Compliance - U - Defender for Endpoint - v3.1MDE 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 SectionSetting NameRequired ValueNIST SP 800-171 Rev. 2 (CMMC)Non-Compliance Action
Device HealthRequire BitLockerRequire3.13.11, 3.8.6 (FIPS-validated cryptography; Protect CUI on portable storage)Mark non-compliant immediately.
Device HealthRequire Secure BootRequire3.14.1 (Identify and correct system flaws)Mark non-compliant immediately.
System SecurityMinimum OS version10.0.22631.xxxx (Current - 2 N)3.14.1 (Flaw remediation)Grace period: 3 days.
System SecurityFirewallRequire3.13.1 (Monitor, control, and protect communications)Mark non-compliant immediately.
System SecurityAntivirus / AntispywareRequire3.14.2 (Provide protection from malicious code)Mark non-compliant immediately.
System SecurityRequire a password to unlock mobile devicesRequire (Minimum length: 8, Block simple passwords)3.5.7, 3.5.8 (Password complexity; Prohibit password reuse)Mark non-compliant immediately.
Defender for EndpointMachine Risk ScoreMedium or lower3.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.

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.

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 PolicyWhat it validates
Win - OIB - Compliance - U - Password - v3.1Password complexity and length requirements
Win - OIB - Compliance - U - Device Security - v3.1Firewall, Antivirus/Antispyware, Secure Boot
Win - OIB - Compliance - U - Device Health - v3.1BitLocker encryption, device health attestation
Win - OIB - Compliance - U - Defender for Endpoint - v3.1MDE 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 SectionSetting NameRequired ValueNon-Compliance Action
Device HealthRequire BitLockerRequireMark non-compliant immediately. (Blocks access to protected resources immediately)
Device HealthRequire Secure BootRequireMark non-compliant immediately.
System SecurityMinimum OS version10.0.22631.xxxx (Current - 2 N)Grace period: 3 days. (Allows time for patching)
System SecurityFirewallRequireMark non-compliant immediately.
System SecurityAntivirus / AntispywareRequireMark non-compliant immediately.
System SecurityRequire a password to unlock mobile devicesRequire (Minimum length: 8, Block simple passwords)Mark non-compliant immediately. (Enforces NIST 3.5.7 & 3.5.8)
Defender for EndpointMachine Risk ScoreMedium or lowerMark 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​

RingScopeQuality DeferralFeature DeferralRestart Behavior
IT & DevIT staff, administrators0 days30 daysRestart prompt after install
PilotEarly adopters, department leads3 days60 daysMaintenance window restart
General OpsCity Hall and office staff7 days90 daysMaintenance window restart
Critical OpsPublic Safety, 24/7 services10 days180 daysMaintenance 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 NameAssigned Group
WUR - IT and DevUpdate Ring - IT Dev
WUR - PilotUpdate Ring - Pilot
WUR - General OpsUpdate Ring - General Ops
WUR - Critical OpsUpdate Ring - Critical Ops

Intune Configuration​

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

IT & Dev Ring​

SettingValueRationale
Quality update deferral period (days)0IT staff are the canary — they see patches immediately
Feature update deferral period (days)30Enough time to read release notes and test critical apps
Microsoft product updatesAllowPatches Office and Edge alongside Windows
Windows driversAllowIT can absorb driver instability; helps surface hardware issues early
Automatic update behaviorAuto install and restart at scheduled timeIT machines can restart on a defined schedule
Active hours start8 AM
Active hours end7 PM
Deadline for quality updates2 daysEnsures stragglers are patched within 48 hours
Deadline for feature updates5 days
Grace period0 days
Auto reboot before deadlineYesIf device is idle at login screen, reboot
Option to pause Windows updatesEnableAllow IT staff to pause during a critical incident

Pilot Ring​

SettingValueRationale
Quality update deferral period (days)33-day soak after IT/Dev validates
Feature update deferral period (days)60
Microsoft product updatesAllow
Windows driversAllow
Automatic update behaviorAuto install and restart at maintenance time
Active hours start8 AM
Active hours end7 PM
Deadline for quality updates5 days
Deadline for feature updates7 days
Grace period1 day
Auto reboot before deadlineNo
Option to pause Windows updatesDisablePilot users should not be pausing patches

General Ops Ring​

SettingValueRationale
Quality update deferral period (days)7Full week soak; covers any delayed Microsoft issue reports
Feature update deferral period (days)90
Microsoft product updatesAllow
Windows driversAllow
Automatic update behaviorAuto install and restart at maintenance time
Active hours start7 AM
Active hours end7 PM
Deadline for quality updates7 days
Deadline for feature updates14 days
Grace period2 days
Auto reboot before deadlineNo
Option to pause Windows updatesDisable

Critical Ops Ring​

SettingValueRationale
Quality update deferral period (days)1010-day soak; patch is validated by all other rings before it arrives
Feature update deferral period (days)180Major OS changes require explicit coordination with command staff
Microsoft product updatesAllow
Windows driversAllow
Automatic update behaviorAuto install and restart at maintenance timeRestart occurs in the maintenance window (see active hours)
Active hours start6 AM
Active hours end11 PMMaintenance window is 11 PM–6 AM — during shift overlap or low activity
Deadline for quality updates14 daysHard deadline: device will restart within the next maintenance window after day 14
Deadline for feature updates30 days
Grace period3 days
Auto reboot before deadlineNo
Option to pause Windows updatesEnableAllows 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

SettingWPA2-Personal (Shared Secret)WPA2/WPA3-Enterprise (802.1X)
Wi-Fi typeBasicEnterprise
Wi-Fi name (SSID)The network name devices should connect toSame
Connect automaticallyYesYes
Connect when network is not broadcastingYes (if the SSID is hidden)Yes (if hidden)
Security typeWPA/WPA2-PersonalWPA/WPA2-Enterprise
Pre-shared keyEnter the shared passwordN/A
EAP typeN/APEAP or EAP-TLS
CertificateN/AReference a SCEP or PKCS certificate profile deployed via Intune
Trusted root CAN/AReference 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 ProfileSSIDAssigned toFilter / Group
Wi-Fi - Police D1 MDTCPD-MDT-SecureAll DevicesFilter: device.deviceName -startsWith "CPDM-1"
Wi-Fi - Police D2 MDTCPD-MDT-SecureAll DevicesFilter: device.deviceName -startsWith "CPDM-2"
Wi-Fi - CFD BattalionCFD-ApparatusAll DevicesFilter: device.deviceName -startsWith "CFD-"
Wi-Fi - City GeneralCityNet-CorpAll DevicesNo 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.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.