Enable BitLocker on every Windows PC remotely

A stolen laptop without encryption is a near-guaranteed data breach — and, if personal data is involved, a GDPR violation to report to regulators within 72 hours. A device encrypted with BitLocker, by contrast, makes the disk unreadable to anyone without the credentials: stolen hardware is no longer a data breach. The difference between a minor incident and a crisis comes down to a well-applied encryption policy, across the whole fleet and not just on a handful of machines.

The problem is that enabling BitLocker device by device doesn't scale: you can't visit every machine, verify the key was backed up, and then prove it during an audit. Microsoft Intune lets you deploy BitLocker across the whole fleet with a single policy, with automatic key backup. You just need to know the settings that matter and the pitfalls to avoid, because a poorly prepared rollout can make a device inaccessible.

What a good BitLocker policy enforces

Good configuration isn't just ticking 'enable BitLocker'. It defines precisely what to encrypt, how, and how to guarantee the key will be recoverable. Here are the settings that separate real protection from a gamble.

• System-drive encryption enabled automatically at startup, silent for the user.
• XTS-AES 256-bit encryption method for fixed drives, stronger than the legacy AES-CBC.
• Automatic recovery-key backup to Entra ID, before encryption begins.
• Encryption required for removable media via BitLocker To Go.
• Denial of writes to unencrypted removable media, to prevent USB-key leaks.

The vital point: the recovery key

This is the most expensive mistake in practice. Without a recovery-key backup, a simple event — a firmware update, a TPM reset, a hardware change, a boot-order modification — can trigger a key prompt at startup. If no one has it, the device and its data become permanently inaccessible. The key must be escrowed to Entra ID, where an administrator can retrieve it on demand.

A good policy therefore requires the key backup to succeed before allowing encryption. This is an explicit setting in Intune, too often left aside, that separates a safe deployment from a risky gamble. Verifying that keys actually appear in Entra ID, and not just that the policy is assigned, is a step you should never skip.

Deploy cleanly, step by step

1. 1Check prerequisites: TPM present and enabled, Windows Pro or Enterprise, devices enrolled in Intune.
2. 2Create the encryption policy with XTS-AES 256-bit and key escrow to Entra ID.
3. 3Require the key backup to succeed before starting encryption.
4. 4Assign the policy to a pilot group first to validate behavior.
5. 5Verify that keys actually appear in Entra ID for the pilot devices.
6. 6Extend the assignment to the whole fleet, then monitor encryption status over time.

A concrete example: encrypting fifty laptops

A company has fifty Windows laptops, about fifteen bought recently and a handful of older models. The administrator creates an encryption policy and assigns it first to a pilot group of five machines. Checking Entra ID, they find four keys have arrived correctly, but that one older device, with no TPM enabled in the BIOS, has not started encrypting.

They fix that device's BIOS, confirm its key arrives, then extend the policy to the whole fleet. Within a few days, all fifty machines encrypt in the background without a single user reporting any disruption. The five oldest models, without a TPM, are scheduled for replacement. The result: a fully encrypted fleet, keys safely stored, and dated evidence ready for the next audit — all with no physical visit to any desk.

Don't forget removable media

Encrypting the system drive is essential, but not sufficient. A significant share of data leaks goes through USB keys and external drives, often carried around carelessly and easy to lose. BitLocker To Go extends encryption to these media: a removable drive used on a managed device is encrypted, and becomes unreadable to anyone who picks it up without the credentials.

Best practice is to deny writes to unencrypted removable media. In concrete terms, the user can still read a USB key received from outside, but can only copy work data to it after it is encrypted. This closes a discreet leak channel without blocking legitimate use, and complements system-drive protection to cover all data at rest.

Track the real encryption status

An assigned policy is not an applied policy. Some devices may be waiting for a restart, blocked by a hardware prerequisite, or mid-encryption. You therefore need to track the real status, device by device, and handle exceptions rather than assume everything is encrypted. It is this monitoring that turns an intention into demonstrable coverage.

Common mistakes

• Encrypting without requiring key backup: the first hardware event makes a device inaccessible.
• Forgetting BitLocker To Go: the system drive is encrypted, but data leaks via USB keys.
• Assigning to an incomplete group: old or newly enrolled devices escape encryption.
• Ignoring TPM-less devices: they need a specific configuration or a replacement.
• Not tracking real status: an assigned policy is not a policy applied everywhere.

Deploy it risk-free with AuPoint

In AuPoint, 'Disk encryption' is a ready-made control, described in plain English. It configures BitLocker, the XTS-AES 256-bit method and key escrow to Entra ID, then assigns it to the group of your choice. Before applying, the impact preview shows exactly which devices are affected, avoiding surprises. If needed, the policy is reversible in one click, with no leftover configuration.

On the compliance side, disk encryption maps directly to ISO 27001, NIS2 and GDPR Article 32 requirements. AuPoint maps the control to these frameworks and includes it in your exportable compliance report — you protect the fleet and produce dated evidence in the same move. If a device is later lost, that evidence can make the difference between a notifiable breach and a non-event.

FAQ

Will the user notice the encryption?

No. Encryption at startup is silent and runs in the background. The user keeps working normally while the disk encrypts, with no forced restart and no perceptible performance loss.

Where do I find the recovery key when needed?

In Entra ID, associated with the corresponding device. An administrator retrieves it on demand, for example when a user sees the BitLocker recovery screen after a hardware change or a firmware update.

What about devices without a TPM?

They need a specific configuration (such as an alternative unlock method) or, ideally, replacement with hardware that has a TPM 2.0, now standard on every recent professional machine.

Connect your tenant to AuPoint, preview the affected devices and enable BitLocker encryption across your whole fleet in minutes — with keys safely escrowed in Entra ID and a compliance report to prove it. Start free today.