How to Manage BitLocker With Hexnode

TL;DR. Hexnode does not encrypt anything. Windows does. Hexnode tells BitLocker which cipher to use, which protector to bind to (TPM, TPM+PIN), and where the 48-digit recovery password should land. Get the prerequisites right (TPM 2.0, Secure Boot, Pro/Enterprise/Education edition), pick XTS-AES 256-bit, escrow the key to the Hexnode portal, and verify the escrow before you trust the dashboard. The “we encrypted but never escrowed” story is the one that ends careers.

What does Hexnode BitLocker management actually do?

It manages native BitLocker. Microsoft writes the crypto. Hexnode writes the policy and stores the recovery key.

That distinction matters. Every MDM that “does BitLocker” (Hexnode, Intune, Workspace ONE, the Bitdefender FDE module) is doing the same thing: pushing a configuration profile to the Windows MDM channel, which the OS hands to the BitLocker subsystem. The encryption runs in manage-bde.exe and the kernel. The MDM’s job is policy and key custody.

What Hexnode specifically gives you, in console terms:

• A Windows Encryption policy under Policies → New Policy → Windows → Security → Encryption.
• Per-drive controls for OS drives, fixed data drives, and removable drives.
• Cipher selection: AES-CBC 128, AES-CBC 256, XTS-AES 128, XTS-AES 256.
• Protector selection: TPM only, TPM with startup PIN, TPM with startup key, or password.
• Recovery options: 48-digit recovery password, 256-bit recovery key, or both.
• A BitLocker Recovery Keys view under the device record.
• Optional rotation policies (recovery password rotation after recovery use).

Nothing exotic. The cipher and protector choices map one-to-one to the underlying BitLocker CSP, Microsoft’s Configuration Service Provider that every Windows MDM hooks into. No Hexnode-only magic. No Hexnode-only failure.

Prerequisites

BitLocker has hardware requirements that catch out at least one device per fleet rollout. Get them right before you write the policy.

TPM 2.0. Required for the TPM and TPM+PIN protectors. Most business-grade hardware shipped after 2016 has it, but it has to be enabled in firmware and not in a “discrete” mode that Windows can’t see. The signal: tpm.msc reports “Ready for use” with spec version 2.0. If it says 1.2, the device falls back to a software protector and your Hexnode policy will fail on apply.

Secure Boot on, with UEFI mode. Legacy BIOS / CSM mode means BitLocker can’t bind to the platform measurements properly. Devices in legacy mode either refuse to encrypt under a TPM protector or encrypt but fall into recovery on every reboot. Convert to UEFI before enrolment, not after. mbr2gpt.exe handles the disk side; the firmware switch is OEM-specific.

Windows 10 1809+ or Windows 11, Pro / Enterprise / Education. Home edition does not support BitLocker (only “Device Encryption”, a stripped-down variant with no MDM hooks). If a single Surface in the fleet shipped with Home, you have to upgrade the SKU before policy applies. Check against the asset register before you push.

Hexnode agent installed and enrolment complete. BitLocker policy applies through the Windows MDM channel, not the Hexnode agent itself, but the agent has to be on the device for the enrolment certificate and policy sync to land. Co-managed devices (Intune + Hexnode through the same MDM channel) are not supported. One MDM owns BitLocker. Pick.

A boring last one: enough free space on the system drive. Used-space-only encryption needs roughly 64 MB. Full-drive encryption tolerates a couple hundred MB.

Setting up the BitLocker profile in Hexnode

This is the part that gets clicked through too fast on first deployment. Slow down here.

Cipher. Pick XTS-AES 256-bit for OS and fixed drives. It is the Microsoft default for Windows 10 1511 and later, performs well on modern CPUs, and is what auditors expect in 2026. AES-CBC variants exist for backwards compatibility with Windows 7 / 8.1 fleets, irrelevant to almost every business now. For removable drives, AES-CBC 256 is sometimes still the right call if you need to read the drive on legacy hardware. Treat that as the exception.

Protector for the OS drive. TPM-only is the default and gets you transparent encryption: the user signs in, BitLocker unlocks the disk, no extra prompt. TPM+PIN adds a pre-boot PIN entry. Stronger against attackers with physical access who can extract the disk, and the only protector that defeats DMA-style attacks on the running TPM. For laptops that leave the office, TPM+PIN is worth the user friction. Minimum PIN length 6 digits in the Hexnode policy; shorter PINs are brute-forceable with hardware.

Protector for fixed data drives. Auto-unlock, tied to the OS drive’s protector. Don’t ask users to type a second PIN.

Protector for removable drives. Password protector. Some fleets ban removable drives outright via a separate policy and skip this section. If you allow them, set a minimum complexity that matches your AD password policy, or users pick Password1 and laugh at you in the morning meeting.

Recovery options. Generate a 48-digit recovery password, escrow it to the Hexnode portal, and do not allow the user to skip escrow. The Hexnode encryption policy has a checkbox labelled something like “Save recovery information to Hexnode portal”. That is the load-bearing setting on the entire profile. Tick it. Tick “Do not enable BitLocker until recovery information is stored” if it’s offered. Untick “Allow user to choose to enable BitLocker (manual)” unless you have a very specific reason.

Encryption mode. Used-space-only is faster and fine for new devices. Full-drive encryption is the right call for any device that’s been in use before MDM enrolment, because used-space-only doesn’t touch blocks that were used and have since been freed. Old data lives in those blocks. Pick by device history, not speed preference.

Pre-boot keyboard layout. Easy to forget. The pre-boot environment doesn’t load the user’s Windows keyboard layout. A South African user typing a PIN with a # symbol on a US layout enters the wrong character and locks themselves out. For PIN protectors, restrict the character set to digits only, or document the expected pre-boot layout per device.

How does the recovery key actually flow?

Every recovery story is a variation on a step in this chain. Know it.

1. Hexnode policy applies to the device through the Windows MDM channel.
2. Windows generates a 48-digit numerical recovery password and a 256-bit recovery key (if both are configured). The password is the human-friendly one. The key is the binary blob you’d inject from a USB.
3. BitLocker encrypts the volume. Used-space-only or full, depending on policy.
4. The Hexnode agent picks up the recovery information from the local BitLocker subsystem and pushes it to the Hexnode cloud over TLS.
5. The Hexnode portal stores the key against the device record, queryable by helpdesk under Manage → Devices → [device] → BitLocker Recovery Keys.
6. On a recovery event (BIOS update, motherboard swap, BCD corruption, the user mistyping the PIN ten times), the user sees the BitLocker recovery prompt with a Key ID. Helpdesk looks up the device, copies the matching 48-digit password, reads it down the phone.

The failure point is step 4. If the Hexnode agent is offline, broken, or not yet installed when encryption starts, the key is generated and used by Windows, but never escrowed. The device is encrypted. The recovery password exists only on the device itself. If anything happens to the device before that escrow completes, the data is gone.

This is why “Do not enable BitLocker until recovery information is stored” matters. It blocks the encryption start until escrow has succeeded, which is annoying for users and the right call for the business.

Rotation. Once a recovery password has been used to unlock a drive, rotate it. Anyone who heard helpdesk read it down the phone now knows the key. Set “auto-rotate after use” in the encryption policy. The new key escrows back to Hexnode within minutes.

Hexnode vs Intune for BitLocker management

Which one to use depends entirely on what you’re already paying for.

Intune wins when you have qualifying licences (M365 Business Premium, E3, E5, or standalone Intune). BitLocker recovery keys auto-escrow to Entra ID, which is where helpdesk and admins already live. Conditional Access reads BitLocker compliance state directly. Autopilot bundles encryption into the out-of-box flow and the user never sees a configuration step. If you’re a Microsoft shop, the Intune story is unbeatable for Windows BitLocker.

Hexnode wins when you’re not on a qualifying M365 SKU, when your fleet is mixed Apple / Windows and you want one console for both, when ChromeOS is in scope, or when your IT team is small and the Intune Endpoint Manager UI is too much console for the team you have. Hexnode’s BitLocker UI is simpler, the recovery-key view is one click instead of a portal hop, and the policy model doesn’t require Entra ID expertise.

The piece that does not exist in Hexnode: native Conditional Access. If you want sign-in to Outlook to depend on BitLocker compliance state, that signal builds out of Entra ID and Intune. Hexnode has SAML / SCIM integrations that get you part of the way, but it isn’t the same product.

For the deeper read on this, see the comparison piece at FDE: Bitdefender vs Intune (and Why MDM Matters), and the MDM page covers the Hexnode-vs-Intune fit decision generally.

Enabling BitLocker on existing Windows 10/11

Force-encrypt via policy is straightforward. The user experience around it is what catches people.

Push the Hexnode encryption policy to a target group of already-enrolled devices. On policy receipt, Windows runs through pre-checks: TPM ready, Secure Boot on, free space sufficient, no competing encryption product. If the pre-checks pass, encryption begins on next reboot. If any fail, the device flips to “non-compliant” in Hexnode and surfaces the reason in the device record.

The user sees, in this order:

• A toast notification that BitLocker is starting (depending on Windows build).
• A request to set a PIN, if TPM+PIN is the protector. The PIN entry UI is Microsoft’s, not Hexnode’s. Document this for the helpdesk so users know what to expect.
• A reboot prompt.
• After reboot, the encryption progress runs in the background. Used-space-only on a 256GB SSD finishes in under thirty minutes. Full-drive on a 1TB spinning disk takes the better part of a working day.

Three user-experience things to plan for. First, performance during encryption is degraded. Modern NVMe drives barely notice. Older SATA SSDs and any spinning disk run noticeably slower for the duration. Schedule encryption for a Friday or overnight where possible. Second, battery life on laptops drops during the encryption pass. Plug in. Third, the pre-boot PIN prompt confuses users on first reboot. They expect Windows; they get a black screen with a numeric prompt. Communicate this in the rollout email or you’ll get help-desk calls about “the laptop won’t start”.

A practical sequencing tip: enrol first, run a Hexnode action to report BitLocker status without enforcing, fix the pre-check failures (TPMs not enabled, Secure Boot off, Home SKUs in disguise), then push the enforcing policy. Never push enforcement to a fleet you haven’t audited.

Pre-encryption for new devices

For devices that haven’t been deployed to users yet, the goal is encryption before first sign-in. Two paths, depending on stack.

Autopilot wins for M365 shops. Windows Autopilot can include the BitLocker enrolment step in the Enrollment Status Page, blocking the user out of the desktop until encryption has started and the recovery key has escrowed to Entra ID. The device is encrypted before the user has finished typing their password. This is the cleanest zero-touch encryption flow Windows has, and it requires Intune and an Autopilot profile. Hexnode is not in this picture.

Hexnode pre-stage for non-M365 shops. Hexnode’s Windows enrolment supports provisioning packages and bulk enrolment tokens. The shape: IT receives the device, joins it to Hexnode pre-shipment via a provisioning package, the BitLocker policy applies during that pre-stage, encryption starts, the key escrows to Hexnode, the device ships to the user already encrypted. Not as elegant as Autopilot (there is a manual hand-off step), but it works for organisations not on M365.

If you’re mixed (some Autopilot devices, some Hexnode-managed), pick the path per device class. Don’t try to make Hexnode replicate the Autopilot flow on M365-licensed hardware. You’re paying for both Intune and Hexnode at that point. Use each for what it’s best at.

Common pitfalls

The recurring failure modes, ordered by how often we see them.

TPM not enabled in BIOS. Top of the list. The user buys a Pro-spec laptop, Windows reports TPM 2.0 in the spec sheet, but the firmware ships with TPM disabled or in a hidden state. BitLocker policy applies, pre-check fails, device sits non-compliant. Fix at the firmware level, per OEM, before deployment. Some enterprise OEM images now ship with TPM enabled by default, but verify, don’t assume.

Secure Boot misconfig. Either off entirely, or on with a custom keyset that Windows doesn’t trust. BitLocker treats this as an integrity failure and can fall into recovery on every reboot. Check msinfo32 for “Secure Boot State: On” and “BIOS Mode: UEFI”. Both have to be true.

Mismatched recovery keys after reimage. A device is reimaged (Windows reinstalled, MDM re-enrolled) and the new device record in Hexnode doesn’t get linked to the old one. The old recovery key is still in the portal under the old device entry, the new device generates a fresh key. If the old entry is deleted before someone realises, the recovery key is gone. Hexnode’s device-record cleanup policy should retain decommissioned device records (and their keys) for at least 90 days. Longer if compliance asks.

The “we encrypted but never escrowed the keys” nightmare. A policy that doesn’t enforce “Do not enable BitLocker until recovery information is stored” lets encryption proceed even when key escrow fails (network blip, agent crash, time skew on the device clock). Devices end up encrypted with keys that exist only on the device itself. Six months later, a motherboard swap puts the device into recovery, and there’s no key to read. The data is gone. We’ve seen this kill thousands of dollars of professional services data on a single laptop. Audit the escrow status weekly: every encrypted device should have a key in the portal. If the count of encrypted devices is greater than the count of escrowed keys, fix that gap now.

Pre-boot PIN keyboard layout. Mentioned above, worth repeating. Users on non-US layouts type a PIN with a special character that maps differently in pre-boot. They lock themselves out. Restrict PIN to digits only, or document the layout.

Policy conflicts with another encryption tool. If Bitdefender’s FDE module is already active on the fleet and you push a Hexnode BitLocker policy on top, recovery-key escrow becomes a race. Whichever agent escrows first wins. The other reports non-compliant forever. Pick one tool, document it, and switch the other off. The FDE comparison article goes into this in detail.

Reimaging without first decrypting. A device is reimaged from a USB stick without a clean BitLocker decrypt-first step. The new image installs over an encrypted volume; sometimes Windows handles it cleanly, sometimes it doesn’t. Always suspend or fully decrypt BitLocker before reimaging.

One more: clock skew. If the device clock is more than a few minutes off real time, MDM enrolment certificate validation fails, policy doesn’t apply, BitLocker doesn’t start. NTP. Not optional.

Where this sits

The Mac equivalent is How to Manage FileVault With Hexnode: same pattern, different OS, same recovery-key-custody logic. Platform context for both lives in the Hexnode page and the MDM page. If you’re deciding whether BitLocker should be owned by your MDM or an endpoint security tool, FDE: Bitdefender vs Intune covers that decision.

Get a managed BitLocker audit

OSH runs a managed BitLocker audit for organisations that have already rolled encryption out and want to know how bad the gaps are. We check recovery-key escrow against the encrypted-device count (the gap is almost always non-zero), TPM coverage, firmware state, cipher and protector choices, and flag devices that look encrypted but have no escrowed key. Output is a one-page risk register and a fix list ordered by blast radius. See our services page for the engagement shape, or skip to a consult and we’ll scope it from there.