EN - Full Disk Encryption Deep Dive: Pre-Boot & Ch...

jorgeluiznim

Article 10 of the Harmony Endpoint Deep Dives series · A note on management: Harmony Endpoint is cloud-managed (Infinity Portal / Web Management) in most deployments today. FDE is configured under Policy > Data Protection > Full Disk Encryption. Where an on-premises Management Server behaves differently, that is called out.

Purpose

Full Disk Encryption is the blade with the highest stakes: get it wrong and you either leave data exposed or lock users out of their own laptops. This article demystifies FDE: the two engines (Check Point vs BitLocker), the pre-boot model, the six-stage Deployment Phase, encryption algorithms, SED hardware encryption, the E89.25 firmware compatibility gate, and the recovery paths that save you when a machine will not boot.

Audience

[x] Endpoint Administrators
[x] Security Engineers
[x] Beginners
[ ] SOC Analysts
[x] Experts

Prerequisites

Data Protection policy basics in the Web Management console
The FDE component installed via the client package (remember: FDE cannot be removed during an upgrade)

What FDE Actually Does

Full Disk Encryption combines two protections:

Component	What it does
Disk Encryption	Automatically, fully encrypts all volumes and hidden volumes (system files, temp files, even deleted files) in the background, with no noticeable performance loss. The encrypted disk is inaccessible to unauthorized people.
Pre-boot Protection	Requires users to authenticate before the computer boots, defeating authentication-bypass tools and alternative boot media that would sidestep OS-level security.

You choose an Encryption Engine per group of computers, configured in Policy > Data Protection > Full Disk Encryption (a pre-defined Default Policy rule already applies to the whole organization):

Check Point Full Disk Encryption: Check Point's own engine
BitLocker Management (Windows): Check Point manages Microsoft BitLocker via the Check Point BitLocker Management Windows service (uses Windows APIs)
FileVault (macOS): Check Point manages Apple FileVault encryption on Mac clients

The Deployment Phase: From Install to Enforcement

The Deployment Phase is the window between installing an FDE package and the Pre-boot actually opening. To cross from deployment to enforcement, seven requirements must be met, and if the client can talk to the server and meets the client requirements, they complete automatically:

Client to server communication exists
Client receives FDE and user policies
Users are acquired per policy
At least one user account is configured
Client sends a recovery file to the server
The System Area is created and boot records updated (Pre-boot activated)
The device meets the FDE client requirements

The client shows six statuses in order on its Main Page:

Note: with Check Point FDE users reboot twice (once to bring up the Pre-boot before encryption, once to validate credentials). With BitLocker they reboot once during installation.

User Acquisition is the step people forget: users are acquired when they log on to Windows on the FDE machine, and their accounts must have passwords that satisfy the password rules. FDE only activates after the required number of users is acquired.

Encryption Algorithms & SED

For Check Point FDE, the cloud policy offers three volume encryption algorithms:

Algorithm	Notes
AES-CBC (256-bit)	Default
XTS-AES (256-bit)	Modern, strong
XTS-AES (128-bit)

Note: older on-premises FDE offered additional legacy algorithms (Blowfish, Cast, 3DES). The current cloud policy standardizes on the AES family above.

By default all detected drives and visible volumes are encrypted. You can also use Self-Encrypting Drives (SED), OPAL-standard drives that encrypt and decrypt in hardware:

Go to Advanced Settings > Encryption > Allow Self-Encrypting Drives (SED) hardware functionality
If a compatible system and disk are detected, FDE uses the hardware encryption on the disk instead of software encryption
The volume name shows SED in the client UI and in the Computers view (Full Disk Encryption details)

Pre-Boot: Required, Conditional, or Bypassed

Pre-boot is where most real-world FDE questions live. The base choice:

Authenticate user before OS loads (Pre-boot): the secure default
Do not authenticate user before OS loads (Not recommended): disables Pre-boot; security drops below the encryption strength

But you rarely want a hard binary. FDE offers temporary bypass and conditional models:

Feature	Behavior
Allow bypass when connected to LAN	On a machine reaching an Endpoint server over Ethernet, the client authenticates securely over the network, with no manual Pre-boot. Falls back to manual Pre-boot if network auth is not possible. UEFI + Mac supported
Unlock Pre-boot user on successful OS login	A user locked out of Pre-boot (bad logons) is unlocked at the next on-LAN OS logon
Temporary Pre-boot Bypass (formerly Wake on LAN)	Admin disables Pre-boot temporarily (on demand, once, weekly, or via script), for example for maintenance or patching

Scripted bypass (SCCM / patch windows)

:: In your script (e.g., SCCM), before a reboot that must skip Pre-boot:
FDEControl.exe set-wol-on
:: ... reboot happens; Pre-boot is skipped so the script continues ...
FDEControl.exe set-wol-off

Warning: the Temporary Pre-boot Bypass script can only run during the timeframe configured in the Temporary Pre-boot Bypass Settings. The bypass window is policy-governed, not a free-for-all.

Extra hardening available: TPM-based Pre-boot integrity measurement, two-factor authentication, and a Hardware Hash (derived from BIOS + CPU data) that detects if the disk was moved to a different computer.

Smart Pre-boot (E89.05 and later)

Smart Pre-boot is the modern pre-boot experience, GA since E89.05. It adds Self-Unlock and Mobile Login using simple MFA through a smartphone, plus clearer login instructions and Wi-Fi setup guidance when the pre-boot needs network for server communication. Two documented limitations to plan for: SmartCard authentication is not supported in Smart Pre-boot, and a secondary external display via a docking station is experimental and depends on hardware and firmware. Moving from Classic Pre-boot to Smart Pre-boot may require a restart.

FDE Firmware Compatibility (E89.25 and later)

Starting with E89.25, Check Point FDE supports only devices that boot Windows through the standard UEFI boot order. Devices that load the Windows Boot Manager directly are not supported until the manufacturer provides a BIOS/UEFI update. This has real deployment impact, so treat it as a gate before any E89.25 rollout on encrypted machines.

Impact on affected devices:

FDE upgrades are blocked, and new installations do not encrypt the disk.
A Blade Status message notifies limited functionality and asks for the administrator's consent to automatically switch the policy from Check Point Encryption to BitLocker Management on those specific machines until the firmware is compatible.
Installing FDE in FAST_INSTALL or ATM mode (isATM=1) may render the device unbootable and require the FDE USB recovery procedure.

Required actions before upgrading to E89.25:

Verify device compatibility with BootModeReport.ps1 (sk185123).
Disable hibernation on affected FDE devices to prevent corruption of the EFI System Partition during the Microsoft Secure Boot Update process.

Recovery: When a Machine Will Not Boot

FDE without a recovery plan is a liability. Three tools:

Tool	Use
Full Recovery with Recovery Media	Boot the failed machine from CD/DVD/USB/REC, authenticate with username + password, the disk decrypts using the partition keys in the Recovery Media
Drive Slaving Utility	Access an encrypted drive attached to another machine
Dynamic Mount Utility	Mount an encrypted volume for data access

Recovery Media flow: the client sends recovery files to the management service once during initial deployment, the admin creates recovery media when needed, boots the failed computer, authenticates, the disk decrypts, and files are restored as decrypted (the OS then runs without Pre-boot). Afterward, the admin must reinstall FDE on that computer.

For locked-out users on the road, Remote Help provides challenge-response recovery, and the Self-Help Portal lets Active Directory users reset their own password.

Switching Engines: Check Point FDE and BitLocker

You can change engines by policy. The client decrypts with the old engine and re-encrypts with the new one:

Check Point FDE to BitLocker: change the Encryption Engine action to Use BitLocker Management, then Save and Install Policy. The client shows a message, the user clicks Reboot and decryption starts, then a message appears again and the user clicks Reboot to start BitLocker encryption.

BitLocker to Check Point FDE: change to Use Check Point Full Disk Encryption, then Save and Install. BitLocker decrypts, then Check Point FDE encrypts, and the user clicks Lock so FDE can collect credentials.

Best Practices

Best Practice: keep the default AES-CBC 256-bit (or XTS-AES 256-bit) unless you have a specific requirement. The cloud policy already standardizes on the AES family.

Best Practice: confirm your password policy is enforceable before rollout. User Acquisition silently stalls if user accounts do not meet the password rules.

Best Practice: before an E89.25 rollout on encrypted machines, run BootModeReport.ps1 (sk185123) to catch firmware-incompatible devices, and disable hibernation on affected FDE devices.

Best Practice: test the Full Recovery flow (and store recovery media securely) before you need it. Recovery is the difference between a reimage and a data-loss incident.

Best Practice: for patch automation on encrypted fleets, use scripted Temporary Pre-boot Bypass within a policy-defined window rather than disabling Pre-boot outright.

Common Mistakes

Mistake	Impact	Solution
Disabling Pre-boot for "convenience"	Security drops below the encryption strength	Use LAN bypass / SSO instead of turning Pre-boot off
Rolling out FDE with weak/mismatched password rules	User Acquisition never completes; FDE never activates	Align password policy first
Upgrading to E89.25 on a device that loads Windows Boot Manager directly	FDE upgrade blocked or disk not encrypted	Run BootModeReport.ps1 (sk185123) first; update BIOS or switch that machine to BitLocker Management
Installing FDE in FAST_INSTALL / ATM mode on E89.25-affected hardware	Device may become unbootable	Verify firmware compatibility first; keep the FDE USB recovery procedure ready
No tested recovery media	A non-booting encrypted disk becomes unrecoverable	Create + test recovery media; verify the recovery file reached the server
Trying custom volume encryption on SED	Silently overridden by the client	Accept AES + full-volume settings on SED
Expecting to remove FDE during an upgrade	Not supported	Plan FDE removal as a separate change
`FDEControl.exe` bypass outside the window	Fails with code 13	Run within the policy-allowed timeframe

Troubleshooting

Symptom: FDE stays in the Deployment Phase and never starts encrypting Environment: Windows client, Check Point FDE engine Root Causes & checks:

User Acquisition incomplete: the required number of users has not logged on, or accounts do not meet password rules
No client-to-service communication: the recovery file cannot reach the management service (step 5). Check connectivity
Client requirements not met: verify the device meets FDE client requirements
Firmware gate on E89.25: if upgrades stopped encrypting after moving to E89.25, check for the Blade Status firmware message and run BootModeReport.ps1 (sk185123)
On the client: system tray lock icon > Display Overview > Full Disk Encryption > check the current status against the six-stage list

FAQ

Q: What's the default encryption algorithm? A: AES-CBC (256-bit). The cloud policy also offers XTS-AES (256/128).

Q: How many reboots during deployment? A: Check Point FDE = twice; BitLocker = once.

Q: Can I skip Pre-boot on machines inside the office? A: Yes. Allow bypass when connected to LAN authenticates securely over Ethernet without manual Pre-boot (UEFI + Mac supported), falling back to manual Pre-boot if needed.

Q: A disk was moved to another computer, is that detected? A: Yes. The Hardware Hash (from BIOS + CPU) detects the move.

Q: We upgraded to E89.25 and some machines stopped encrypting with Check Point FDE. Why? A: E89.25 requires the standard UEFI boot order. Devices that load the Windows Boot Manager directly are gated until a BIOS update. You can consent to switch those machines to BitLocker Management in the meantime, and you should verify hardware with BootModeReport.ps1 (sk185123).

Q: What happens after a Full Recovery? A: The disk ends up decrypted and the OS runs without Pre-boot, so the admin must reinstall FDE on that computer.

References

Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal), Configuring the Data Protection Policy > Full Disk Encryption (engines, algorithms, Pre-boot, Temporary Pre-boot Bypass, SED, recovery)
Check Point SecureKnowledge sk184929, Enterprise Endpoint Security E89.25 Windows Clients (FDE firmware compatibility, EPS-63819; Smart Pre-boot limitations)
Check Point SecureKnowledge sk185123 (BootModeReport for FDE firmware compatibility)

Revision History

Date	Version	Author	Changes
2026-07-16	1.0	Jorge Luiz	Initial version
2026-07-30	2.0	Jorge Luiz	Cloud-first revalidation of the FDE configuration path, engines, algorithms, SED and recovery
2026-09-15	2.1	Jorge Luiz	Added the E89.25 FDE Firmware Compatibility gate (EPS-63819) and a Smart Pre-boot (E89.05 GA) note; related Common Mistakes, Troubleshooting, FAQ and References; removed emoji and dashes for a cleaner read

Supported Versions: Harmony Endpoint cloud management (Infinity Portal / Web Management); Check Point FDE / BitLocker (Windows) / FileVault (macOS); FDE firmware compatibility gate applies from E89.25 Last Updated: 2026-09-15

Are you a member of CheckMates?