This is the official release of Matrix42 Full Disk Encryption 26.1 and provides an overview of all relevant technical background and changes. With Full Disk Encryption 26.1, we are delivering the first public major release of a new Full Disk Encryption generation. This version concludes a long and deliberate development and validation journey that began with Full Disk Encryption 25.0 Update 1, which was introduced through a Controlled Rollout. Since then, we have implemented significant architectural changes, security‑critical updates, and a wide range of bug fixes and stability improvements—based on internal backlog items as well as extensive feedback from Controlled Rollout participants. Full Disk Encryption 26.1 consolidates all of this work into a stable, production‑ready public release. 

Before you Start

Before proceeding, we strongly recommend that you familiarise yourself with the key changes, improvements, and update procedures by reviewing the Release Notes in full. This is especially important given that there are now two available UEFI certificate variants on the Marketplace, each signed with a different Microsoft certificate. It is therefore recommended that you review the listed KB article in the corresponding section and the Recommended Approaches for Updating. Following these steps will help to ensure a smooth update and a proper understanding of all the changes included in this version.

Key Changes and Improvements

Key Fundamentals Introduced

• Full Secure Boot support
• Replacement of the previous SHIM‑based approach:
  • Introduction of a custom, Microsoft‑signed bootloader
  • Independence from expired or third‑party shim certificates
• Linux kernel upgrade from 5.1.4 to 6.6.9
• Activation of Linux IMA (Integrity Measurement Architecture) for improved boot‑time integrity
• Support for Windows 11 version 24H2
• 32‑bit platform support

These changes were essential to ensure long‑term security, compatibility, and maintainability of Full Disk Encryption.

Bootloader and Secure Boot Changes

System and Kernel Updates

Pre-Boot Authentication and User Capturing

We have improved support for user capturing during the PBA process:

Windows 11 24H2 Support

• User capturing is supported on Windows 11 version 24H2 and later
• This applies only to users not using Windows Hello for Business and not enforced Microsoft/Live ID accounts

Password Change Behavior

• When users change their Windows password, the new password is not captured immediately
• The PBA screen is temporarily bypassed until the next interactive Windows login
• After a successful login, the new password is captured and PBA is shown again on the following boot

Architecture and Packaging Changes

• 32‑bit support has been removed
• All 32‑bit binaries have been removed from the FDE deployment package
• Deployment is supported on 64‑bit systems only

Stabilization and Refinement During the Controlled Rollout

Following the Controlled Rollout that started with Full Disk Encryption 25.0 Update 1, a significant part of the engineering effort focused on stabilizing the new architecture and reaching functional completeness. The improvements listed below were developed, refined, and validated during multiple Controlled Rollout updates and are fully consolidated in Full Disk Encryption 26.1

User Capturing and Pre‑Boot Authentication (PBA)

Significant improvements ensure reliable and predictable user capturing across Windows versions and login scenarios:

• Fixed cases where users were not captured after incorrect password entries during initial login
• Improved handling of user switching during active User Capture, including the Windows “Other User” scenario
• Resolved password capture issues when:
  • New users were added via the Management Console
  • Single Sign‑On failed and no password was entered within the expected time frame
• Improved password synchronization for:
  • Password changes via CTRL + ALT + DEL
  • Password changes performed on other devices
  • Password changes initiated by administrators in Active Directory
• Correct synchronization when users are added to PBA without an initially known password

Additional Information: These changes align user capturing with the modern Windows Credential Provider (GetSerialization) and provide consistent behavior across Windows 10 and Windows 11. It is important to bear in mind that users need to enter their old password to pass the pre-boot authentication. Afterwards, Windows Authentication will fail due to the old password. Then, users can log in to their machine with the updated password, which will be in sync with the Pre-Boot Authentication the next time the machine boots. From then on, users can use their current password to pass the pre-boot authentication.

For adding first-time or additional users to Pre-Boot Authentication, the following scenario is supported:

• Adding users from Active Directory via the Management Console

The issue we addressed here applies when an administrator adds a new user from the Active Directory to pre-boot authentication. In most cases, the administrator would leave the password field empty because they do not know it. The newly added users will then need to enter an empty password to pass the pre-boot authentication. Windows Authentication will then fail due to the incorrect password. The user will then log in with their current credentials, at which point the issue occurs. Typically, you would expect that, after rebooting the system, the updated password would be synchronized with the pre-boot authentication. This was not the case in previous technical releases. This new version covers this use case, and the entered password is now synchronized with the pre-boot authentication immediately. 

Policy Builder and Configuration Stability

Administrative reliability was improved through targeted refinements:

• FDE log file paths are no longer reset when creating or modifying PBA policies
• User Capture settings in the Policy Builder are changed only when explicitly required
• Correct application of custom PBA background images