Secure Windows Devices with Intune: BitLocker, Defender, LAPS and Baselines

Baselines or endpoint security policies: which one do you reach for?

Both end up as settings on the PC, and Intune does not rank them. A security baseline (Endpoint security > Security baselines) is a template of many Windows settings, pre-filled with the values Microsoft's security team recommends. Endpoint security policies (Disk encryption, Antivirus, Firewall, Account protection) are narrow: each covers one protection area and starts with most settings left as Not configured. A baseline is opinionated about everything at once. A focused policy only has an opinion about the thing you asked for.

The trouble starts when they overlap. Microsoft's guidance is that all Intune policy types carry equal weight, and when two assigned policies give one setting different values, that setting may not be applied and both policies report a conflict. Microsoft also says baseline defaults are, in almost all cases, the most restrictive option, so you should confirm they do not clash with other policy. A concrete example from Microsoft's BitLocker documentation: the Defender for Endpoint baseline can enable a TPM startup PIN or key, and that blocks silent BitLocker encryption because nobody is at the keyboard to type the PIN.

Our recommendation for a first pilot is to build the focused policies first, prove they work, and only then add a baseline to the same small group and reconcile the differences. A baseline is a well-informed opinion about your estate, but it is still an opinion, and it is easier to disagree with one deliberately than to untangle it afterwards. Use this map for where each control lives:

• BitLocker: Endpoint security > Disk encryption, profile BitLocker.
• Defender Antivirus: Endpoint security > Antivirus, profile Microsoft Defender Antivirus.
• Windows Firewall: Endpoint security > Firewall, profile Windows Firewall.
• Windows LAPS: Endpoint security > Account protection, profile Local admin password solution (Windows LAPS).
• Baseline: Endpoint security > Security baselines, then Security Baseline for Windows 10 and later (the name covers Windows 11).

What you need before you start

This chapter assumes the fictional lab from the earlier chapters: a pilot device group (we use the name Lab-Pilot-Windows-Devices) holding a single enrolled Windows 11 test PC. Everything below is assigned to that group and nothing else. If the test PC is a virtual machine, take a checkpoint first, because several changes here cannot be cleanly reversed from the portal.

• Licence: Intune Plan 1 covers security baselines and Windows LAPS policy. Windows LAPS works with the free tier of Microsoft Entra ID. Defender Antivirus and Firewall policy have no extra prerequisites on Windows. Tamper protection and endpoint detection and response need Microsoft Defender for Endpoint P1 or P2 and onboarding, which this chapter leaves out.
• Windows: Windows 11, edition Pro or above for BitLocker management. Windows 10 is still an allowed Intune version but passed end of support on 14 October 2025, so we do not cover it.
• For silent BitLocker: Microsoft Entra joined (or hybrid joined), TPM 1.2 or later, UEFI mode, Secure Boot on and WinRE configured. A virtual machine only qualifies if it presents all of these, including a virtual TPM.
• Intune role: Endpoint Security Manager covers creating the policies and baseline in this chapter.
• Entra roles: Cloud Device Administrator can switch on LAPS in Entra and read recovery keys and LAPS passwords. Helpdesk Administrator can also read BitLocker keys. Rotating a LAPS password from Intune needs a custom Intune role with Remote tasks: Rotate Local Admin Password, because no built-in role includes it.

Turn on BitLocker for the pilot device

BitLocker encrypts the disk so a lost or stolen laptop does not hand over its data. In Intune the policy decides how encryption is done, and, more importantly for support, makes sure a recovery key is stored in Microsoft Entra ID before the disk is encrypted. A key that exists only on the device it protects is no use on the day you need it.

Read the warnings first. Silent encryption works by switching off the warning that normally appears when another disk-encryption product is found. If such a product is present, BitLocker proceeds anyway, and Microsoft lists data loss, boot failures and messy recovery as possible results. Also, most BitLocker settings are applied when BitLocker is first turned on for a drive, and encryption is not restarted if you change the policy later. Get the settings right before you assign.

There is a genuine trade-off. Silent encryption requires TPM-only protection, with no startup PIN. The NCSC's Windows guidance recommends full disk encryption using a TPM with a PIN. A PIN needs user interaction, so it rules out silent enablement. For a laptop that leaves the building, weigh that choice deliberately rather than inheriting it from the silent-encryption recipe.

Encryption starts in the background after the device picks up the policy. How long it takes depends on the disk, how much data is on it and whether Windows uses used-space-only or full encryption; Microsoft does not give a fixed time.

1. On the test PC, open PowerShell as an administrator and run the two read-only checks below. Get-Tpm should report a present and ready TPM, and Confirm-SecureBootUEFI should return True. Also look in Installed apps for any third-party disk-encryption product. If you find one, stop and use a different test device.
   powershellCopy

   Get-Tpm
   Confirm-SecureBootUEFI

2. In the Microsoft Intune admin center, go to Endpoint security > Disk encryption > Create Policy. Set Platform to Windows and Profile to BitLocker, then select Create. Give it a plain name such as LAB-Win11-BitLocker-Pilot.
3. On Configuration settings, set Require Device Encryption to Enabled and Allow Warning For Other Disk Encryption to Disabled. Only disable that warning because step 1 showed the device is clean. After you do, Allow Standard User Encryption appears; set it to Enabled if the person using the PC is a standard user.
4. Under Operating System Drives, set Require additional authentication at startup to Enabled. Then set the three TPM options that allow a startup PIN, a startup key or both to Do not allow, and set Configure TPM startup to Allow TPM or Require TPM. Make sure the policy saves recovery information to Microsoft Entra ID and requires that before enabling BitLocker; Microsoft's key-rotation prerequisites name these as Save BitLocker recovery information to Microsoft Entra ID = Enabled and Store recovery information in Microsoft Entra ID before enabling BitLocker = Required. Consider Configure Recovery Password Rotation too.
5. On Assignments, add only Lab-Pilot-Windows-Devices. Do not use All devices. Select Next, then Create on Review + create.
6. To avoid waiting for the next scheduled check-in, go to Devices > All devices, open the test PC and select Sync. Leave the PC powered on and online while it encrypts.

Prove the disk is encrypted without opening the key, and know how to back out

There are two questions: did Windows encrypt, and could we get back in if it asked for the recovery key tomorrow? You can answer both without displaying a single recovery key. Reading a key is an audited event and, once displayed, it is a secret that has been on someone's screen, so do it only for a real recovery. Never paste a recovery key into a ticket, chat or this lab's notes.

Intune can take up to 24 hours to report encryption status, because that figure includes the time Windows spends encrypting plus the time the device takes to report back. A blank report on day one is not a failure.

Treat encryption as a one-way door in the lab. We have not verified what unassigning the policy does to a disk that is already encrypted, and the Microsoft pages we checked do not describe a policy-driven decrypt, so do not assume removal returns the device to where it started. If you must go back, decrypt on the device itself as a deliberate, separate decision.

One trap deserves a plain warning. Microsoft states that deleting the Intune object for a Microsoft Entra joined device protected by BitLocker triggers a sync that removes the key protectors on the operating system volume and leaves BitLocker suspended. Do not tidy up lab devices in the portal casually.

If a recovery key is ever displayed or read out, rotate it. Intune has a BitLocker key rotation device action on the device page (under the ellipsis menu if it is not visible). It needs the Rotate BitLockerKeys (preview) right, held by the Help Desk Operator and Endpoint Security Administrator roles, and the policy must have client-driven recovery password rotation enabled, as listed in the settings step above. Microsoft marks that right as preview, so recheck the wording before relying on it.

1. In Intune, open the encryption report. Microsoft's pages give it as Devices > Monitor > Encryption report in one article and as the Monitor tab under Devices > Manage devices > Configuration, then Device encryption status, in another. The portal layout moves around, so use whichever your tenant shows. Select the test PC and check Encryption readiness (Ready), Encryption status and the Status details field, which lists reasons such as a missing TPM, WinRE not configured or recovery key backup failed.
2. Go to Devices > All devices, open the test PC and, under Monitor, select Recovery keys. A healthy device lists a BitLocker Key ID and Drive Type. If you see No BitLocker key found for this device, the key has not reached Entra ID and you should not treat the device as recoverable. Leave Show Recovery Key alone for now.
3. On the PC, open an elevated Command Prompt or PowerShell window and run the status command below. Look at Conversion Status (Used Space Only Encrypted or Fully Encrypted) and Protection Status. Avoid manage-bde commands that list protectors in full, because those can print the recovery password onto your screen and into your clipboard history.
   cmdCopy

   manage-bde -status c:

Defender Antivirus and Windows Firewall policies

Microsoft Defender Antivirus is built into Windows, and Intune can set how it behaves without any extra licence on Windows. Windows Firewall blocks unwanted network connections. Neither profile has to be clever to be useful; the point of the pilot is a deliberate, written-down configuration that is the same on every managed PC.

Keep two limits in mind. First, Antivirus exclusions lower protection, so add none unless you can name the file you are excluding and why. Second, tamper protection and the preview Controlled Configuration setting (which makes Intune the sole authority over Defender settings and overrides Group Policy and local changes) need Defender for Endpoint onboarding or carry preview caveats, so leave both out of this first pilot. Attack surface reduction rules also require Defender Antivirus to be the primary antivirus, so check no other antivirus product is active before you go further.

On the firewall, the NCSC baseline is to block traffic on Public and Private networks, then add explicit allow rules for the services you need. Blocking inbound connections can break anything that connects to the PC, such as Remote Desktop, file sharing or remote support tools. Test those on the pilot device before you extend the policy.

Microsoft's firewall guidance is to apply one Windows Firewall profile to a device. A second Windows Firewall profile, or firewall settings from a device configuration profile, that sets a different value for the same setting produces a conflict. Windows Firewall rules profiles behave differently: they merge, but contradictory rules for the same thing (allow and block the same program) are both delivered and conflict on the device.

1. Go to Endpoint security > Antivirus > Create Policy. Set Platform to Windows and Profile to Microsoft Defender Antivirus, then select Create. Name it, then on Configuration settings enable only the protections you want enforced, such as real-time monitoring and cloud-delivered protection. Skip exclusions. Assign it to Lab-Pilot-Windows-Devices.
2. Go to Endpoint security > Firewall > Create Policy. Set Platform to Windows and Profile to Windows Firewall, then select Create. Configure the Domain, Private and Public network sections to keep the firewall on and unsolicited inbound traffic blocked. The settings follow the Windows Firewall CSP, so confirm the exact labels in your portal. Assign it to the same pilot group only.
3. Sync the test PC from Devices > All devices. Then open the device, select Device configuration and check both policies show Succeeded.
4. For firewall, open Endpoint security > Firewall > Summary and Reports > Firewall > MDM Firewall status for Windows. The test PC should be Enabled and should not appear in the report called MDM devices running Windows 10 or later with firewall off.
5. For antivirus, open Endpoint security > Antivirus > Unhealthy endpoints. That page only lists devices with detected problems, so the test PC being absent is good news but is not proof on its own. Confirm on the PC with the read-only commands below, run in PowerShell (an elevated window is the safe default): AntivirusEnabled and RealTimeProtectionEnabled should be True, and each firewall profile should show Enabled as True.
   powershellCopy

   Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled
   Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

Windows LAPS: unique local administrator passwords

Windows LAPS gives each PC its own random password for a local administrator account, rotates it on a schedule and backs it up to Microsoft Entra ID. It stops one shared local admin password turning a single compromised PC into access to every PC. Intune does not create accounts for this: it manages an account that already exists, with one exception. On Windows 11 24H2 and later, automatic account management can create a custom account or enable and rename the built-in one.

Decide which account you are managing before you build the policy. If you leave Administrator Account Name blank, the policy manages the built-in administrator account, found by its well-known identifier rather than its name. Out of the box that account is normally disabled, in which case a perfectly good rotated password unlocks nothing until the account is enabled or you use automatic account management or a named account that exists. If you name an account that does not exist on a Windows 11 23H2 or earlier device, nothing is managed and no error is raised.

Intune's LAPS policy takes precedence over Group Policy or legacy Microsoft LAPS, so an older arrangement will be overwritten rather than politely coexisting. Microsoft recommends assigning one LAPS policy per device and using device groups, because user-group assignments can change which configuration applies each time a different person signs in. The device must be Microsoft Entra joined or hybrid joined; workplace-joined devices are not supported.

Post-authentication actions can reset the password, sign out the account or power the device down after the password expires. Leave the defaults on the pilot unless you have deliberately chosen otherwise.

1. Enable LAPS for the tenant. In the Microsoft Entra admin center, as at least a Cloud Device Administrator, go to Identity > Devices > Overview > Device settings, set Enable Local Administrator Password Solution (LAPS) to Yes and select Save. This lets devices post passwords to Entra; nothing changes on a PC until a policy tells it to.
2. In Intune, go to Endpoint security > Account protection > Create Policy. Set Platform to Windows and Profile to Local admin password solution (Windows LAPS), then select Create.
3. On Configuration settings, choose the Backup Directory as Microsoft Entra ID. Then set the password age, length and complexity you want and, if needed, the Administrator Account Name. A directory that does not match the device's join type is accepted without error but cannot work.
4. Assign the policy to Lab-Pilot-Windows-Devices only, then select Create. Policy processing runs roughly hourly, so on the test PC open an elevated PowerShell window and run the command below to process it now. Then open Event Viewer, go to the Windows LAPS operational log under Applications and Services Logs and look for event 10029, which records a successful password update in Microsoft Entra ID.
   powershellCopy

   Invoke-LapsPolicyProcessing

5. In Intune, go to Devices > All devices, select the test PC and, under Monitor, select Local admin password. You should see the account name, its security ID and the last and next password rotation times. The password itself stays hidden. Choosing Show reveals it and is logged, so skip it unless you genuinely need to sign in with it.
6. Optional: test a rotation. On the device page, open the ellipsis menu, select Rotate local admin password and confirm. Device actions status moves from Pending to Complete, which can take a few minutes. The device must be online, and your account needs the custom role mentioned earlier. A manual rotation resets the clock for the next scheduled one.

Add a security baseline last

The baseline is the broad sweep. Adding it last means that when something changes on the test PC you can tell the baseline did it. Read it as a list of decisions to accept or reject rather than a switch to flip. Microsoft's current Windows baseline list, as we checked it on 4 November 2026, shows version 26H2 as the newest. Recheck that when you build the policy, because only the newest version can be used to create a new baseline profile.

One behaviour matters for safety: as soon as you select Create on an assigned baseline, Intune pushes it to the group. Make sure the assignment is the pilot group before you press the button. Also note that the Defender for Endpoint baseline needs Defender for Endpoint licensing and onboarding, and Microsoft does not recommend it for virtual machines, so leave it out of a VM-based lab. Edge and Microsoft 365 Apps baselines are separate topics.

Rollback is the awkward part. Microsoft says removing a baseline assignment, or setting a baseline setting to Not configured, may not return a device to its previous state, because each setting is delivered through a CSP that may handle removal differently. The reliable undo on a lab VM is the checkpoint you took at the start. On a physical test PC, record the values you care about before you assign, so you can put them back by hand.

The first report can take time. Microsoft notes that data can take up to 24 hours to appear after you first assign a baseline.

1. Go to Endpoint security > Security baselines, select Security Baseline for Windows 10 and later and select Create policy. Name it, for example LAB-Win11-Baseline-Pilot.
2. On Configuration settings, expand every group and read it against the four policies you have already built. Wherever the baseline and one of your policies disagree - BitLocker startup authentication, firewall behaviour, Defender settings, local account rules - decide which policy owns that setting. Change the baseline value to match, or set it to Not configured, so only one policy gives a value.
3. On Assignments, select Select groups to include and choose Lab-Pilot-Windows-Devices only. If a setting you need is user-scoped, Microsoft notes you may need a second baseline assigned to a user group. Select Create.
4. Go to Endpoint security > Security baselines > Security Baseline for Windows 10 and later > Profiles, select your profile and then View report under Device and user check-in status. Select Generate report if the page is empty. Then open the Per setting status tile and look at the Error and Conflict columns. Succeeded across the board means the settings were applied.

When two policies disagree, and what this walkthrough does not cover

Conflicts are the usual price of layering, and Intune will not usually fix them for you. The pattern to remember is one owner per setting. If the baseline, a device configuration profile and an endpoint security policy all want to control firewall state, pick one and set the others to Not configured. LAPS has its own flavour: two policies naming different accounts for the same device conflict, and until that is resolved the device's account cannot be managed.

This article has not been tested on a real device or tenant. The portal paths, setting labels and behaviours come from Microsoft's current documentation and the NCSC guidance, and every command is read-only and standard, but none has been run for this article. Check each label in your own portal, because Intune moves things.

Deliberately left out: compliance policies and Conditional Access (the next steps in the series), attack surface reduction, endpoint detection and response and tamper protection, the Edge and Microsoft 365 Apps baselines, Personal Data Encryption, Windows 10, and Graph or PowerShell automation. The lab outcome to carry forward is one pilot PC that is encrypted with its key backed up, has Defender and firewall policy applied, has its LAPS password backed up and a baseline whose conflicts you have read and resolved.

1. In Intune, go to Devices > All devices, open the test PC and select Device configuration. Open any policy showing Conflict or Error and select the affected setting. The Settings details pane lists every Source Profile that sets it with a different value.
2. Open each source profile, choose Properties and edit one so only a single policy sets that value, or unassign the profile that should not be involved. Sync the device and check the status again.
3. If the portal does not explain it, create the Windows MDM diagnostic report on the PC: Settings > Accounts > Access work or school, select the work account, then Info > Advanced Diagnostic Report > Create report and Export. Look for the setting in the Enrolled configuration sources and target resources section or the Unmanaged policies section. The report describes your device and tenant configuration, so keep it internal rather than attaching it to a public forum post.