Applying DISA STIG Settings with Microsoft Intune: Overcoming Native Limitations

ChrisVetter

Microsoft

Oct 15, 2025

Advanced Methods for Enforcing Security Baselines in Modern Endpoint Management

Introduction

The Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) are essential for organizations requiring stringent security compliance, especially within federal and defense environments. While Microsoft Intune offers a robust set of device management policies, not all STIG-recommended settings are natively available. My previous blog covered creating/importing configuration profiles for settings already available in the Intune UI which you can find here. This blog post explores creative and effective approaches for applying non-native DISA STIG settings using Intune, including PowerShell Desired State Configuration (DSC) as a Win32app, custom OMA-URI profiles, and PowerShell Remediation scripts.

Understanding the Challenge

Intune’s built-in Configuration Profiles and Security Baselines cover many common security controls, but gaps remain when aligning with the comprehensive requirements of DISA STIGs. These gaps arise because some settings are either not yet exposed in the Intune UI or require advanced configuration mechanisms (hopefully the amount of these will decrease as time goes on). To ensure compliance, administrators must leverage alternative deployment and configuration strategies. This blog is assuming you have sufficient knowledge on building Intune win32apps, PowerShell DSC, Custom OMA-URI profiles and Remediation scripts and will not go over those features in detail.

Method 1: Deploying PowerShell DSC as a Win32app

PowerShell Desired State Configuration (DSC) allows administrators to define and enforce configuration states on Windows devices. By packaging DSC scripts as Win32apps, organizations can deploy complex configurations that Intune does not natively support. For STIG settings DISA has already done this for you and supplied DSC Scripts to be packaged that will cover most of the settings noted in their spreadsheet

Step 1: Create the DSC Configuration Script: Create a DSC script that configures required STIG settings (e.g., registry keys, system services, audit policies).

Step 2: Package as a Win32app: Use the Microsoft Win32 Content Prep Tool to package your DSC script and any dependencies into a .intunewin file.

Step 3: Deploy via Intune: Upload the packaged app to Intune and assign it to your target devices. The DSC script will run and enforce the configurations on the endpoints.

This method is effective for complex or multi-step configurations and provides robust reporting on compliance status via DSC logs.

Method 2: Custom Configuration Profiles with OMA-URI Strings

For settings that can be configured via Windows MDM but are not exposed in the Intune UI, custom configuration profiles using OMA-URI (Open Mobile Alliance Uniform Resource Identifier) allow direct application of these controls.

Step 1: Identify the MDM Setting: Review the STIG documentation and map the required setting to its corresponding CSP (Configuration Service Provider) and OMA-URI path. For this example, I will use the “The number of allowed bad logon attempts must be configured to three or less” STIG Setting which can be found in the DeviceLock CSP

Step 2: Create a Custom Profile: In Intune, create a new Device Configuration Profile of type “Custom” and input the OMA-URI string, data type, and value.

Step 3: Assign the Profile: Target the profile to the appropriate device groups.

This approach is ideal for registry changes, policy tweaks, or settings accessible via MDM but not surfaced in Intune’s UI.

Method 3: PowerShell Remediation Scripts

Intune’s Endpoint Analytics feature supports proactive remediation scripts, which can be used to detect and remediate configuration drift or enforce settings continuously.

Step 1: Write Detection and Remediation Scripts: Upload the scripts into an Intune remediation script. The detection script checks if the device is compliant with a specific STIG setting, while the remediation script applies the necessary change if non-compliant. For this example, we will use remediation scripts to make sure Windows PowerShell 2.0 is disabled.

Step 2: Deploy via Intune: Create a new Proactive Remediation in Endpoint Analytics and upload both scripts. Schedule the remediation to run at regular intervals to maintain compliance.

Remediation scripts are especially useful for settings that might be reverted or altered by users or other processes, ensuring persistent compliance.

Best Practices and Considerations

Testing: Test, Test, and Test again! You should always test custom configurations in a non-production environment to avoid unintended consequences.

Documentation: Maintain detailed documentation of custom policies, scripts, and mapping to STIG requirements.

Monitoring: Use Intune reporting, DSC logs, and Endpoint Analytics to monitor compliance and troubleshoot issues.

Updates: Regularly review both Intune and STIG updates to leverage new native settings and retire custom solutions when possible.

Conclusion

While Intune continues to evolve, organizations can achieve full DISA STIG compliance by leveraging PowerShell DSC, OMA-URI custom profiles, and proactive remediation scripts. These methods empower security teams to enforce advanced security baselines and meet regulatory requirements, bridging the gap until native UI settings become available.

Disclaimer

All screenshots and folder paths are from a non-production lab environment and can/will vary per environment. All processes and directions are of my own opinion and not of Microsoft and are from my years of experience with the Intune product in multiple customer environments

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Resources