Last week in our article, we discussed onboarding best practices with Microsoft Intune. I’m happy to report that part one was a huge success with many people finding it to be super useful, which is great. This week, we move onto discussing security (which will actually be cut up into two parts). The security best practice items for this week can be seen below:

• Security Baselines
• Windows Autopatch
• Microsoft Defender for Endpoint (or other EDRs)
• BitLocker
• Personal Data Encryption
• Certificate Authentication Strategies
• Admin Account and Group Protection
• Device Compliance

We will cover some of the most complex technologies like App Control, Endpoint Privilege Management (EPM), App Patch Management, and Device Control in part three. This week we will stick to the core security best practices, which we will kick things off with security baselines.

Check out our previous articles:

• Onboarding
• Advanced Security
• User Experience

Windows 11 Security Baseline Best Practices

I covered some of the core concepts of security baselines back in April in my Workspace ONE Admin Guide to Intune: Security, but now we will focus on how we should be handling them. A few of the challenges we saw recently made me rethink the overall strategy of implementing the spirit of baselines. If you learn nothing else from this section learn this: THEIR. POLICY. IS. NOT. YOUR. POLICY! It’s incredibly important that you step through anything you implement and make sure the settings make sense for your users and environment.

For baselines we have:

• The Windows 11 OS Security Baseline
• Microsoft Defender for Endpoint (MDE) Security Baseline (Covered later on)
• Microsoft Edge Security Baseline
• Microsoft 365 Apps for Enterprise Security Baseline

Before discussing the baselines, I wanted to touch on the overall strategy. The most important thing to learn is DO NOT just implement all of the security baselines and think that is the best practice. It’s easy to make that mistake because it feels like that is the right thing. The overarching strategy is half finesse and half mindfulness.

I’ve decided to shift all of my baselines to the settings catalog (which in the near future it will be moving to), because replication/conflicts/updates do not play particularly well.

Some of the reasons are:

• Settings language on the baselines aren’t consistent with settings catalog
• Resolving conflicts can be problematic as the baselines don’t update/resolve conflicts quickly/easily
• Working with a consistent look and feel just makes management easier

Let’s discuss piece-by-piece so we can start getting to a healthier state.

Windows 11 OS Security Baseline

There are a few ways you can achieve at your ideal state. One option is to use fellow MVP, James Robinson’s baseline from his GitHub, which is exceptional. He’s spent hundreds of hours working on it, which does get you to a really strong state.

The strategy that I am using and consider to be a best practice is leveraging the GPO Objects from the Microsoft Security Compliance Toolkit to craft your group policy in the Settings Catalog. You can grab my versions of them from my GitHub:

• Windows 11 23H2 Security Baseline (Device)
• Windows 11 23H2 Security Baseline (User)

Check out the YouTube video below on how to import them:

Once you have imported and created your baseline settings catalog policy, we go through each setting piece-by-piece to see if it fits your strategy. You can access a spreadsheet of the default policy here:

With most policies, make sure you deploy it out to a small subset of users first. That is a critical part of all security policies that you implement. One last thing to point out, is don’t forget to use filters instead of dynamic groups, because they’re significantly faster and don’t rely on backend Entra processing.

Microsoft Edge Security Baseline

Edge is the one baseline that I will use directly inside of Endpoint Security. It works well, and I never see any conflict issues. The settings are pretty minimal so let’s cover them quickly:

You can find a copy of my Edge Security Baseline file here. This is the recommended security baseline for Edge by Microsoft. A few of the reasons I like moving it to the settings catalog are:

• You can have a single Edge policy that includes customizations, security settings, etc.
• Naming/setting consistency as I’ve mentioned with other policies.

Microsoft 365 Apps for Enterprise Security Baseline

One of the often-overlooked areas is the Microsoft 365 Apps Admin Center because its outside of Intune. When your team doesn’t manage Office, it becomes very helpful to shift roles and responsibilities back to that team. With the Microsoft 365 Apps Admin Center, you can delegate that responsibility with the Office Apps Administrator role, which lets them manage the overall Windows fleet.

One thing to be aware of are the licensing requirements:

• Education (M365 A3/A5)
• Business (M365 Business Standard/Premium)
• Enterprise (M365 E3/E5)

Among the various things you can do with the M365 Apps Admin Center are:

See your devices and get insights on their device information (This replaced the old telemetry server):

Security Update Status (shows you the status on monthly security updates):

Your OneDrive sync health which is super important:

You also have the cloud Office Customization Tool, which lets you build your configuration.xml files, which makes life much easier with Office deployments/changing channels:

The reason we’re covering this portal is because they have shifted/made available security baselines inside of this portal known as “Cloud Policies.” These policies you can scope at a tenant-wide, group wide, and even documents that are accessed anonymously via the web.

In the event that I don’t want to punish everyone, below is an export of all 137 Office baseline settings:

Windows Autopatch

Recently I wrote all about patching here. When it comes to patching, Windows Autopatch is the unequivocal best practice. You can check out this video on configuring Autopatch:

Overall, you can read my article if you want to go really deep into it. The key takeaways are:

• Requirements are:
  • Windows 10/11 E3+
  • Entra ID P1/P2
  • Entra Join or Hybrid Join
  • Intune-managed devices
  • Co-management requirements (if applicable):
    • Intune cloud-attached
    • Windows Update, Device Config, and Office C2R workloads are Intune-managed
• Setup your Windows Autopatch Device Registration group to capture all devices to ensure people onboard properly
• Don’t go crazy on Autopatch Groups. You should always use the out-of-the-box groups if possible. You only want to create groups if it’s necessary. Simpler is always better

As I mention in my article, this is what Autopatch manages:

The last thing that I want to mention is the Autopatch Group Service which you can see in this diagram below. It shows how patches are sliced up into the rings to ensure automated management of your patch strategy:

Microsoft Defender for Endpoint

The best place to start here is by sharing my MDE settings catalog policies that you can use:

• MDE Baseline
• MDE Attack Surface Baseline

these baselines are largely based on the great Nathan McNulty. You can find his GitHub here.

Similarly with OS baselines, we chose to pull them out to more effectively manage conflicts, language differences, and get better consistency.

The settings of the baseline are:

These are the settings on my Attack Surface Baseline:

BitLocker

Your BitLocker strategy is pretty easy overall. We create a policy inside of Endpoint Security and these are the settings that I use today:

One thing that I do strongly recommend is implementing Network Unlock, which is slightly out of scope for this article.

Network Unlock eases the pain of PIN enforcement by letting users bypass the PIN when on the corporate network for the OS volume. The UEFI firmware must have a DHCP driver, which shouldn’t be a difficult thing to achieve. The requirements overall are:

• Supported OS with UEFI DHCP drivers to serve as a Network Unlock client
• TPM chip and at least one TPM protector
• Internal server running Windows Deployment Services (WDS) role
• BitLocker Network Unlock optional feature installed on the server
• DHCP server
• Public/private key configuration setup
• Settings deployed as above in the BitLocker policy
• Deployed public certificate for Network Unlock via Intune
• Network stack enabled in UEFI

Basically, the way it works is:

1. Windows Boot Manager detects Network Unlock in the BitLocker config
2. PC uses its DHCP driver in the UEFI to get a valid IP address
3. PC broadcasts a vendor-specific DHCP request with a network key (256-bit intermediate key) and AES-256 session key for the reply (this is all encrypted with the 2048-bit public key of the Network Unlock certificate you deployed via Intune)
4. Network Unlock on your WDS server recognizes the request and decrypts it with the private key
5. WDS sends back the network key encrypted with the session key (also an intermediate key) using a vendor-specific DHCP reply to the PC
6. This request, coupled with a local 256-bit intermediate key only decryptable by the TPM will be used to create the AES-256 key which can unlock the volume

Personal Data Encryption (PDE)

Introduced in Windows 11 22H2 was PDE, which provides file-based data encryption in Windows. PDE uses Windows Hello for Business (which we will cover in later parts of this series) to link data encryption keys with user credentials. Once a user authenticates, it allows the user to decrypt files, which is a great enhancement on BitLocker and NOT a replacement (which is a common misconception).

This reduces the effort for accessing encrypted content and provides additional protections beyond BitLocker itself. One of the caveats with it is that you can only use it with Cloud Native devices (e.g. Hybrid cannot use PDE). It’s also good to point out it is only supported in Windows Enterprise and Windows Education A3/A5.

Microsoft provides this table below shows the two potential levels of protection you can leverage with PDE which uses AES-CBC and a 256-bit key to protect your content:

A few fun facts to be aware of:

• If you use your password instead of PIN, you cannot access your files
• Files are not accessible via several remote methods like UNC paths or Remote Desktop
• Non-owners of the content cannot access it when logged into the machine
• Decryption keys are discarded one minute after the lock screen is engaged or at user sign out
• You need to be careful and make sure content is backed up. There have been situations a PIN reset could make PDE content inaccessible
• The next release of PDE, will let you configure folder level protection to Known Windows Folders (Desktop, Documents, Pictures)

The recommended way to create this policy currently is using the Graph APIs: (I recommend just using Graph Explorer to create your PDE policy)

POST https://graph.microsoft.com/beta/deviceManagement/configurationPolicies
Content-Type: application/json
{ "id": "00-0000-0000-0000-000000000000", "name": "PDE Policy", "description": "", "platforms": "windows10", "technologies": "mdm", "roleScopeTagIds": [ "0" ], "settings": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_admx_credentialproviders_allowdomaindelaylock", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_admx_credentialproviders_allowdomaindelaylock_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_errorreporting_disablewindowserrorreporting", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_errorreporting_disablewindowserrorreporting_1", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_windowslogon_allowautomaticrestartsignon", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_windowslogon_allowautomaticrestartsignon_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_memorydump_allowcrashdump", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_memorydump_allowcrashdump_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_memorydump_allowlivedump", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_memorydump_allowlivedump_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "user_vendor_msft_pde_enablepersonaldataencryption", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "user_vendor_msft_pde_enablepersonaldataencryption_1", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_power_allowhibernate", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_power_allowhibernate_0", "children": [] } } } ] }

One final note that I want to mention, I am a bit on the fence if we should implement this before the PDE locations are configurable, but I would suggest at least looking at it. It’s a great move for the enhanced privacy of users but may not be a good fit in many environments.

Certificate Authentication Strategies

Certificate authentication is an interesting conversation overall. Many companies are moving away from on-prem infrastructure, which does lighten the load for certificates. At a minimum, you are likely using certificate authentication/EAP-TLS for your wireless network connections.

In some scenarios, we are now seeing people use certificates in new and fun ways like certificate-based authentication in Entra ID.

The strong recommendation today is to decouple your certificate infrastructure from your internal CAs. I wrote recently about Microsoft Cloud PKI, which is one of two recommended options. I strongly recommend either:

• Cloud PKI
• SCEPman

Both of these solutions, achieve the same end result. You basically put your client-side PKI in the DMZ/Azure infrastructure, etc. By doing this, if someone does compromise a certificate it can only be used on the device and not to access anything internally.

You can see what that architecture looks like below:

The goal today isn’t to discuss which solution is better, but to clearly point out that if you do have use cases for certificates, please separate them. This is one of the core principles of InfoSec and is very easily achievable with different solutions.

Check out this video to see how easy it is to deploy Microsoft Cloud PKI today:

Admin Account and Group Protection

The Microsoft Local Admin Password Solution (LAPS) is the new gold standard for securing local administration access and should 100% be used everywhere.

Essentially, LAPS will take over ownership of a local administrator account, rotate the password, and manage those credentials. As a best practice, we store those credentials in Entra ID, like we do with BitLocker. The setup in Intune is super simple, as seen below:

Additionally, we lockdown the local administrator groups to ensure only the groups we want in place for the local administrator group overall.

• Replace and Update can’t co-exist. Replace will always win out.
• Specify Entra users like AzureAD\[email protected] and groups with their SID (which you can get from the graph API). Oliver also wrote a cool script here to conversion if needed.
• SIDs are not resolved, so there’s no error checking there so be careful.
• Check Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin to look for errors.

Check out my demo from my other blog article on how to set that up:

One last best practice to mention is disabling that delightful new feature that makes all global admins local admins: (that is in Entra Device Settings)

Device Compliance

The last section to cover is device compliance. From a best practice perspective, I recommend using the following ones:

• Secure Boot
• BitLocker
• Code Integrity
• TPM
• Antivirus
• Firewall
• Anti-Spyware
• Defender Risk Score: Low
• Microsoft Defender Antimalware Security Intelligence Up to Date
• Defender Real-Time Protection

That should cover compliance needs in most environments, but some people will want to look at a newer feature with custom compliance scripts. Basically, a custom compliance script will be a PowerShell script that checks for a value, and you pair that with a JSON script to help evaluate the compliance itself.

The people at PatchMyPC wrote a nice one here. Basically, they use a PowerShell script to check the name and the version of Google Chrome with this code here:

## make sure to enter the exact display name shown in Add Remove Programs.
## While you can use wildcards to search for software, the exact display name discovered in appwiz.cpl will be used as the Setting Name for the json compliance check rule
[array]$applicationName = @("Google Chrome","Test App")
# --------------------------------------
# DO NOT EDIT THE LINES BELOW
# --------------------------------------
# Search HKLM for a system-wide app install
[array]$myAppRegEntries = Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue | Select-Object DisplayName, DisplayVersion
[array]$appInfo = ForEach ($application in $applicationName) {    
    #[array]$myAppRegEntries = Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue | Where-Object { $_.DisplayName -like $application } | Select-Object DisplayName, DisplayVersion
    # Flag to indicate if the application is installed
    $appInstalled = $false
    If ($myAppRegEntries) {
        # Check if the app exists in $myAppRegEntries
        Foreach ($myAppReg in $myAppRegEntries) {
            if ($myAppReg.DisplayName -eq $application) {
                $appInstalled = $true
                [string]$displayName = $myAppReg.DisplayName
                [string]$displayVersion = $myAppReg.DisplayVersion
                break  # No need to check further once found
            }            
        }
    }
    if (-not $appInstalled) {
        # App not installed, set the display name and version accordingly.
        # If not setting this and the app is not installed, the version check would be null, causing the compliance check to error out.
        # this way, if the software is not installed at all, forcing it to be listed as compliant.
        $displayName = $application
        $displayVersion = "0.0.0.0"
    }
    # Create a custom object and add it to the array
    @{
        $displayName = $displayVersion                    
    }
}
# adding loop to convert the $appInfo array into a single custom object named $objectJSONoutput
# doing this because we want a single object with all the apps and versions listed as key-value pairs in the JSON output, instead of an array with separate objects for each app. Intune no likey that.
$objectJSONoutput = @{}
foreach ($app in $appInfo) {
    $objectJSONoutput += $app
}
$hash = $objectJSONoutput
return $hash | ConvertTo-Json -Compress

Their matching JSON tells it what to look for and mark a device if not compliant:

{
    "Rules":[
        { 
           "SettingName":"Google Chrome",
           "Operator":"GreaterEquals",
           "DataType":"Version",
           "Operand":"116.0.5790.110",
           "MoreInfoUrl":"https://www.liviubarbat.info",
           "RemediationStrings":[ 
              { 
                 "Language": "en_US",
                 "Title": "Google Chrome x64 is outdated.",
                 "Description": "Make sure to patch Google Chrome"
              }
           ]
        },
        { 
           "SettingName":"Test App",
           "Operator":"GreaterEquals",
           "DataType":"Version",
           "Operand":"116.0.5790.110",
           "MoreInfoUrl":"https://www.liviubarbat.info",
           "RemediationStrings":[ 
              { 
                 "Language": "en_US",
                 "Title": "Test App is either outdated or not installed.",
                 "Description": "Make sure to install or update it."
              }
           ]
        }
     ]
}

As you can see, these capabilities create a ton of possibilities to meet your specific compliance requirements.

Final Thoughts

Hopefully overall people enjoyed the content today in the first part of Windows 11 Security Best Practices. It surprised me how much I have covered already on best practices and how they align with the key technology running in the Microsoft Cloud. We are relying heavily on the modern CSPs, and core components within Intune to secure Windows 11 effectively. In the next chapter, we will be covering some complicated products, which many struggle to get right. Things like EPM, App Control, and Device Control aren’t 100% required for everyone, but they strengthen your security strategy. I hope everyone enjoys and feel free to join me/connect to drive the conversation further as we work toward our ideal state in Windows 11.