SecureDoc V9.0 SR3


Release Notes

View All


SecureDoc Support

WinMagic strongly recommends that you install the most recent software release to stay up-to-date with the latest functional improvements, stability fixes, security enhancements and new features.

Please visit Knowledge Base Article 1397 for more information on End of Life and End of Support timelines for SecureDoc software releases.


About This Release

This document contains important information about the current release. We strongly recommend that you read the entire document.

Recommended – WinMagic recommends this service release for all environments. Apply this update at your earliest convenience.


Release/EOL Dates

Details / Build Information

9.0 SR3

March 2, 2023
EOL: Mar 1, 2026

New Features, Improvements, and fixes (server/client)
Build# 9.0.300.118 (Server, all other clients), Build# 9.0003.103 (macOS)

9.0 SR2

December 9, 2022
EOL: Dec 8, 2025

New Features, Improvements, and fixes (server/client)
Build# (Server, all other clients), Build# 9.0002.198 (macOS)

9.0 HF1

September 7, 2022
EOL: Mar 30, 2025

Hotfix containing improvements (see release notes)
Build# (Windows client installer only)

9.0 SR1

July 21st, 2022
EOL: Jul 21, 2025

New Features, Improvements, and fixes (server/client)
Build# (Server, all other clients), Build# 9.0001.73 (macOS)


March 31, 2022
EOL: Mar 30, 2025

New features, improvements and fixes (server/client)
Build# (Server, all other clients), Build# 9.000.1030 (macOS)

8.6 SR1

September 8th, 2021
EOL: Sep 7, 2024

New features, improvements and fixes (server/client)
Build# (Server, all other clients), Build# 8.6001.85 (macOS)


December 8th, 2020
EOL: Dec 7, 2023

New features, improvements and fixes (server/client)
Build# (Server, all other clients), Build# 8.6000.594 (macOS)

8.5 SR2

June 11th, 2020
EOL: Jun 10, 2023

New features, improvements and fixes (server/client)
Build# (Server, all other clients), Build# 8.5001.632 (macOS)

8.5 SR1

April 8th, 2020
EOL: Apr 7, 2023

New features, improvements and fixes (server/client)
Build# (Server, all other clients), Build# 8.5001.632 (macOS)


December 5th, 2019
EOL: Dec 4, 2022

New features, improvements and fixes (server/client)
Build# (Server, all other clients), Build# 8.5001.448 (macOS)


NOTE: End of Life date for Hotfixes is the same as the Version or Service Release upon which they are based.

Download the latest release notes for each version listed within Knowledge Base Article 1756.

System Requirements
If using features that use the TPM (e.g., MagicEndpoint, or other TPM-based authentication such as TPM protection for Key Files), devices must have TPM 2.0 – TPM 1.2 or earlier are not supported.

For server and client system requirements: For supported devices, drives, smartcards, and tokens:

Note: It is strongly recommended to initially install Full-Text Indexing feature (Full-Text Search) into the Database Engine, before performing an SES installation.
More information is available here:

During the installation of SES, if Full-Text Indexing has not been installed, a message will appear indicating the absence of the Full-Text Indexing. This message will not allow the user to stop the installation of SES which will require retrofitting Full-Text Indexing into an existing SQL Server.

Note: Use of the SES Console will require the user to have at least local admin rights on the server or client device (e.g., Admin desktop) on which it runs for the console to function properly.

Client OS Support

Devices utilizing MagicEndpoint authentication must have Windows 10 or 11 – Windows 7 is not supported.
For a detailed view of which specific versions of SecureDoc are supported under various versions of Windows, macOS or Linux: See:

Mobile Token-based authentication using Bluetooth is not supported on any pre-Windows 10 Operating Systems


The KnownConfigs.XML File

Customers are strongly advised to download the most current KnownConfigs.XML file, then replace the current version (if older) in the SES Application folders and Installation Packages.

WinMagic strongly recommends that you seek out the most up-to-date version of the KnownConfigs.XML file and incorporate it into your SES implementation on a regular basis (e.g., monthly). This will help ensure your SES Version will take advantage of new client installation override settings that have been added since the version of the KnownConfigs.XML file that came with your version of SES. This will improve installation success on any new device makes/models you might purchase since installing SES, utilizing the new special settings available in newer versions of this file.
Customers are advised to look to the SecureDoc Knowledge Base for a link to the available KnownConfigs.XML files, then check that document (e.g., on a monthly basis) for updates to this file, then use the new version to replace all versions of the KnownConfigs.XML file in their SES Implementation folder structure. For example:

  1. Position Windows Explorer to: c:\Program Files(x8)\WinMagic\SDDB-NT, then
  2. Search for files like *.xml.
  3. Sort the resulting search list by name
  4. In each directory where a KnownConfigs.XML file is found, replace it with the new one that you have downloaded from the WinMagic Knowledge Base article.

Additional information can be found here: Installing or updating the KnownConfigs.xml file (Applies to SES from Version 7.5 onward).


The latest versions of the KnownConfigs.XML files can be found at the following links:

    • SecureDoc Device KnownConfigs.XML File for SES V8.2 And Later- Download the

latest version of this here: File-for-SES-V8-2-Download-the-latest-version-of-this-here

    • SecureDoc Device KnownConfigs.XML File for SES V7.5 - Download the latest

version of this here: SES-V7-5-Download-the-latest-version-of-this-here


The contents of the KnownConfigs.XML file are reserved to be developed and advanced by WinMagic solely. While customers might consider enhancing it, WinMagic cannot be held responsible for issues that might arise from such modifications and may (at its sole discretion) levy an additional support charge to any customers that encounter support issues that can be traced back non-sanctioned customer-initiated changes to KnownConfigs.XML.
WinMagic welcomes customer ideas and suggestions on how KnownConfigs.XML can be extended and improved, but WinMagic reserves the sole right to test, approve and to publish any changes to KnownConfigs.XML that it deems to be in the broader customer interest, and makes no commitment to act upon or publish all, or indeed any customer-recommended changes. 

Version 9.0 SR3


For customers deploying 9.0SR3 to devices containing Self Encrypting Drives (SEDs),  if you encounter any unexpected messages indicating that SecureDoc Installation is not proceeding on such a device, please contact WinMagic Support for assistance. 

The Windows Essentials Profile and Installation Package types are no longer supported

Issue: The Windows Essentials licensed client type is being discontinued.  Windows Essentials was a slimmed down version of the SecureDoc Windows client which supported management of BitLocker encryption while including several key SecureDoc features.  Lack of uptake of this client type in the market necessitates its removal to streamline product offerings.

Solution: The Windows Essentials profile and Installation Package types are no longer supported, and these profile/package types will no longer be available to create or deploy to endpoints.
Note: Due to the extent of the documentation that is affected, documentation relating to this Profile and Installation Package type will still exist in this version but will be fully removed in the V9.1 documentation coming later this year.  Customers are asked to ignore any references to Essentials in the documentation in the meantime.

Affected Tickets: SD-43817 

Which customers should upgrade to 9.0SR3?
Version 9.0SR3 is a Service Release upgrade to the SecureDoc Enterprise Client and Server.
All customers are recommended can safely upgrade to 9.0SR3.
Why upgrade?

NOTE: Any customers wishing to use Microsoft Azure AD (as opposed an on-premises Active Directory) must upgrade to V9.0 (or higher). Azure AD is not supported on earlier versions of SecureDoc Enterprise Server. 

Any Azure AD-joined Devices must be either initially installed using V9.0, or any existing devices that will be joined to an Azure AD must be upgraded to the V9.0 (or later) client software before being joined to the Azure Active Directory.

NOTE: SecureDoc installer now no longer supports installation on macOS Mojave. Version 9.0SR2 ends support for macOS Mojave, and as a result the macOS Mojave target has been removed from the SecureDoc executables framework, installation, and run-time scripts.

IMPORTANT: For customers wishing to utilize SecureDoc’s Bluetooth Low Energy mobile device-based authentication at Pre-Boot:
1 - The device Profile must specify the Linux-based Pre-Boot for UEFI devices – termed as PBLU in this documentation.  Phone-based authentication (whether using Bluetooth Low Energy communication or network-based communication) does not work with
2 – Bluetooth must be enabled in the endpoint computer’s hardware configuration (BIOS or UEFI settings), as use of Bluetooth Low Energy mobile device-based authentication is a compelling security feature.,

NOTE: These release notes are presented in a new format compared to prior releases. A) Rather than leading with the ticket number(s), these will include the ticket(s) at the end of each release note; b) Issues and improvements will be grouped into meaningful groups that discuss specific aspects of the product (e.g., Authentication, Server, client, and other groupings).


How to Install/Upgrade

Customers with an active support plan should contact to receive the latest download link for their SecureDoc upgrade. 


New Features


SecureDoc now offers an alternate Multi-Factor Authentication at Pre-Boot using Mobile Token using communication with the Mobile Device via Network (as opposed to Bluetooth Low Energy)

Issue: Where customers cannot use or do not wish to use Bluetooth communication between the device and the user's Mobile Device (phone), an alternative means of communicating with the phone's WinMagic Authenticator app would permit such customers to still have such strong Multi-Factor Authentication.

Solution: Using appropriate settings in the Device Profile, Administrators can configure that such devices can be accessed over a network connection, either in addition to Bluetooth (e.g. if Bluetooth is disabled or otherwise not working), or instead of Bluetooth. Such network- based communication and data transfer can be used to unlock the phone-protected key file.

NOTE: Neither Phone/network-based nor Phone via Bluetooth Authentication work with PBConnex network-brokered authentication, because with PBConnex authentication the User Key File for the device is transmitted from the server upon successful authentication (even if the user has a local key file), whereas Phone via Bluetooth or Phone/network-based Authentication unlock the user’s LOCAL key file stored on the device.

Affected tickets: SD-42802, SD-42903 


This Service Release provides support for macOS Ventura builds 13.2 (22D49) and 13.2.1 (22D68).



SecureDoc for Linux now supports the newly released RHEL 8.7 kernel

Issue: SecureDoc needs to constantly evolve to support enterprise and other Linux environments as the Linux kernel and distributions evolve.

Solution: SecureDoc for Linux now supports the newly released RHEL 8.7 kernel (Kernel 4.18.0-425.3.1.el8.x86_64)
Affected tickets: SD-43435 

This Service Release now supports Ubuntu 22.04

Issue: Previous versions did not fully support Ubuntu 22.04 due to numerous Kernel and support library changes required.

Solution: This Service Release now support Ubuntu 22.04 and has been tested on both Desktop and Server versions.
Affected tickets: SD-41652 

SaaS – Software as a Service




SecureDoc Console or SESWeb Console

Selection of Root Folder as 'Null' when filtering Devices list in previous version has been fixed

Issue: In previous versions, where filtering to show any devices that might reside in the Root Folder of the Device Folder structure, one would have to choose "Null" (since the Root Folder is the only folder that has a null identifier.

Solution: In this version, this has been corrected, and when selecting the folder for which the device list is to be filtered, the Root folder will appear with the more self-explanatory description "Root Folder".

Affected tickets: SD-44165 

Report filtering can appear to hang due to unlimited result set data fetch.

Issue: Reports typically fetch 50 rows at a time to be displayed (page size), but when filtering data the SQL statement has no limit for the result set size, so can appear to hang - when in fact it is simply busy while it fetches all possible results that match the filter specified.

Solution: Filtering will now adhere to the same rules as a report, returning the typical 50 rows at a time.

Affected tickets: SD-44148 

The SES Installation Package now permits configuration of a specific Group to which Device can be added when registered

Issue: To aid Administrators in organizing Linux/Cloud devices early in their SecureDoc life-cycle, just as it has been possible to determine in which Folder devices should be placed upon registration, it would be beneficial to similarly place devices into specified Groups during the course of SecureDoc Installation.

Solution: With this improvement, through changes to the Installation Package Administrators can define into which group devices are to be placed during SecureDoc installation and initial device registration.

Affected tickets: SD-36531 

SecureDoc Client - Linux


SecureDoc Client - Windows


SecureDoc Client - macOS



No WIFI available in the SecureDoc Linux-based Pre-Boot for UEFI devices after disconnecting wired connection, re-booting and using WIFI.

Background: This issue was detected in the SecureDoc Linux-based Pre-Boot for UEFI devices after disconnecting wired connection, re-booting and using WIFI. Affected devices included HP ProBook 445 G8 models that have the MediaTek MT7961 Network Interface Card (NIC). This model of NIC had been working as expected in SecureDoc D 8.6 SSR1 at PBLU, but issue connecting to access points occurs in SD 9.0 SR2 after unplugging ethernet then rebooting switching to Wi-Fi.

Issue: The customer reports that the NIC is functioning as expected in SD 8.6 SSR1 in the SecureDoc Linux-based Pre-Boot for UEFI devices, but issues connecting to access points occurred starting in SecureDoc 9.0 SR2 after unplugging a wired ethernet connection then rebooting, switching to Wi-Fi.

Solution: This issue has been resolved in this version; Customers can disconnect from Ethernet, reboot the device and successfully boot with WIFI support.
Affected tickets:  SD-43972 

Pre-Boot authentication using Bluetooth Low Energy-based Passwordless Authentication is now possible when device contains a Self-Encrypting Drive (SED)

Issue: Previously Bluetooth connection was not supported when the device has a Self-Encrypting Drive. This limitation meant that users would not be be able to use SecureDoc/MagicEndpoint Passwordless 1-step login feature at Pre-Boot and at Windows with hardware-encrypted endpoint devices.

Solution: With this change, the above limitation has been resolved so that MagicEndpoint Bluetooth Low Energy-based authentication can be deployed and used on systems having Self-Encrypting Drives.

Affected tickets:  SD-43104 

The new Hardware Authentication Profile configuration panel allows configuration of password-less login using Mobile Token-based authentication with communication via Network (versus Bluetooth)

Issue: Configuration of password-less login using Mobile Token-based authentication with communication via Network (versus Bluetooth) is now an aspect of Hardware Authentication. The new Hardware Authentication Profile configuration panel allows configuration of use of network phone (also referred to as OOB - Out of Band, though this terminology is being phased out as not self-explanatory or clear enough).

Solution: The Hardware Authentication configuration panel (in the Windows Profile) now contains two new options:
1 - Allow passwordless login using OOB network phone; and its sub-option
2 --- Use OOB network phone as default login method

Affected tickets: SD-43090 

When using Bluetooth Low Energy communication, the approval prompt now appears on the phone more rapidly than in previous versions, improving authentication speeds

Issue: When using Bluetooth Low Energy communication, in previous versions the approval prompt could take several seconds to appear on the user's phone. WinMagic strives to provide as rapid an authentication solution as possible.

Solution: The approval prompt now appears on the phone more rapidly than in previous versions, improving authentication speeds for end users and providing a better, speedier user experience.

Affected tickets: SD-43000 

A 32-character limit on the length of the WIFI password has been upgraded to 64 characters

Issue: Where customers were keying very long WIFI Passwords into the SES Console settings, only 32 characters were being stored in the SES Database and resulting profiles.

Solution: This issue has been corrected, and the WIFI password can now be up to 64 characters in length.

Affected tickets: SD-42892 

SecureDoc Pre-Boot code now utilizes Linux kernel version 5.15.30

Issue: To keep pace with available drivers, security patches and other elements necessary for SecureDoc to remain modern and up-to-date, the Linux kernel on which the SecureDoc pre-boot authentication stage is built must be updated to utilize the best available Linux kernel.

Solution: SecureDoc's Pre-Boot code now utilizes Linux kernel ver. 5.15.30

Affected tickets SD-41861 

Authentication - Recovery




Resolved Issues



Issue with Microsoft Surface Pro 8 detachable Keyboard and touchscreen are not working at Pre-Boot

Issue: This issue arose where SecureDoc 9.0 SR1 was installed on a Microsoft Surface Pro 8 using the Surface installer; In this profile, PBLU and PBConnex were enabled. Upon booting the device to the SecureDoc pre-boot authentication. Microsoft surface detachable Keyboard and touchscreen were not working. However, an external USB keyboard and mouse did work, and wireless networking and PBConnex were working.

Solution: This issue has been corrected; Pre-boot works fine on the Microsoft Surface Pro 8 with detachable keyboard and touchscreen.

Affected tickets: SD-SD-43146




IMPORTANT: Mobile Token-based authentication using Bluetooth is not supported on any pre-Windows 10 Operating Systems.


SES Console or SESWeb Console


MacOS Devices



Lenovo ThinkPad L14 Gen 3 AMD devices unable to perform Bluetooth phone-based login at Pre-boot - error "BT device not found" appears

Issue: The wireless Network Interface Card (NIC) ID installed in these Lenovo devices is 14c3 ("MEDIATEK Corp."), device: 0616 ("MT7922 802.11ax PCI Express Wireless Network Adapter") also incorporates the Bluetooth functionality.
The SecureDoc Pre-Boot Kernel does not support this hardware in the Linux versions used in V9.0SR3 and prior.

WinMagic will strive to incorporate this into the Kernel in a build after 9.0SR3 as it encompasses a complex and substantial Pre-Boot Linux kernel change.

Work-Around: If possible, customers who wish to use PBConnex with Bluetooth-enabled mobile device-based authentication should consider purchasing a compatible USB-pluggable Bluetooth adapter capable of Bluetooth Low Energy communication, and disabling the internal Bluetooth adapter in the device BIOS. WinMagic recognizes that some devices have unsupported Bluetooth hardware and is beginning validation of USB-connected Bluetooth adapters.
One such adapter is: ORICO-BTA-608 Bluetooth 5.0 (Realtek driver - RTL8761B), which has passed our QA testing. More information available at:

Affected tickets: SD-43363 

Remotely Auto-booting a device using an account that relies on a token (including Mobile Device-based authentication via Bluetooth or via Network) will not permit a user to authenticate at SecureDoc Credential Provider on a device that has been so remotely auto-booted. 

Issue:  Where an Administrator sends down a command to remotely Auto-boot a device and chooses a user account that normally relies upon a token (e.g., Mobile Device-based authentication via Bluetooth or Network), once the device gets to the SecureDoc Credential Provider login for Windows, it will not permit that user (or any user relying on Mobile Device-based Bluetooth/network-based authentication) to authenticate at SecureDoc Credential Provider.  Instead, the SecureDoc Credential Provider screen will keep re-loading, and the authorization request will not be sent to (nor appear) on the user's mobile device. 

Solution: To perform remote auto-boot, utilize only accounts that rely on a Password and never use any User Key File that has been converted to using any form of token for authentication (including Mobile Device Bluetooth or network-based authentication).  Ideally, create a specialized account/key file for this rather than selecting any specific user's key file.  

Use of a Key File that relies on a token defeats the intention of remote autoboot (which is unattended boot of the device to Windows).  This issue is further explained in Knowledge Base article 1972.  

Affected tickets: SD-44409

Deleting then re-adding an existing User Account from the SES User Database can disrupt the user's ability to log in to an endpoint device using a short user name, and may necessitate logging in with a UPN user id.

Issue: An issue arose where a user record had been deleted from Active Directory, which automatically causes that user's user record to be moved into the SES recycle bin, blocking said user from being able to use PBConnex network-brokered authentication, or from logging in at SecureDoc pre-boot since the user's local key files would be removed from all affected devices if so configured.

In this scenario, the same user ID was added back into Active Directory. When re-synchronized via SecureDoc ADSync into the SES User table, since there was a user with exactly the same short name in the recycle bin, ADSync will generate a unique user ID by appending the domain to the user name (since it cannot tolerate duplicate short user names).
This re-created User record in AD did not have the same GUID as the original user record had, and is treated as a completely different user (despite the same user name and short user name).
The user knows his short user name had worked in the past, and tried to log in with that, but it would not work since the user record with that short user name resides still in the recycle bin and so is prevented from authenticating.
However, when the user entered the long-form User ID (e.g. johndoe@domain) he was able to log in.

Work-Around: Before adding a previously-deleted User Account back into AD, first check that the old user record does not still exist in the SES Recycle Bin. If it does: 1) Delete it fully from the SES database Recycle Bin, and only then 2) Add the user information into the Active Directory. In this way, there is no remnant of the old User record blocking the potential for this net-new AD User account to be synchronized into SES using the short user name the user will prefer to use.

Affected tickets: SD-41902 

Two-factor authentication prompts user to authenticate to remote desktop when using RDP where both devices have the "Enforce Multi-Factor Authentication for native Windows Logon" option enabled.

Scenario: This issue was encountered in a device utilizing a profile/package combination that specifies hardware encryption, use of the Linux-based Pre-Boot for UEFI devices, SecureDoc Credential Provider and that the Key File supports both Password and Token-based protection/authentication, though other configurations could reflect this behavior.
On the first device, the user is asked to switch from password to token protection. The token type selected is Phone Token(Bluetooth), with protection method selected: Use token ECC keys. Further options selected in the profile are: Enforce Multi-Factor Authentication for SecureDoc Windows Logon; Enforce Multi-Factor Authentication for native Windows Logon; Enforce Multi-Factor Authentication for Remote Desktop connections to SecureDoc-protected devices; Add SecureDoc Login enhancement to Remote Desktop Client; Authenticate to Remote Desktop using MagicEndpoint -requires no user action

Issue: The first Client device was joined to Azure AD, SecureDoc was deployed successfully and was converted to use Bluetooth phone-based authentication successfully. MagicEndpoint was linked to SecureDoc successfully. The second (remoted-to) Client device was similarly joined successfully to Azure AD. On the first client, an RDP (Remote Desktop) session was opened to the IP address of the second client device.

At this point the expectation is that the 2-Factor Authentication prompt would not appear due to the configuration applied to the two devices. However, the 2-Factor Authentication dialog does appear, prompting the user to confirm the RDP login session using his/her Phone app, after which RDP to the second client is successful.

Work-Around: Until WinMagic has developed a solution for this unexpected requirement to authenticate, customers are requested to complete authentication using the Phone app when using RDP to remote endpoint.

Affected tickets: SD-44092, SD-43430  

Authentication – Remote Desktop



Contacting WinMagic

5770 Hurontario Street, Suite 501
Mississauga, Ontario, L5R 3G5
Toll free: 1-888-879-5879
Phone: (905) 502-7000
Fax: (905) 502-7001
Human Resources:
Technical Support:
For information:
For billing inquiries:


This product includes cryptographic software written by Antoon Bosselaers, Hans Dobbertin, Bart Preneel, Eric Young ( and Joan Daemen and Vincent Rijmen, creators of the Rijndael AES algorithm.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (

WinMagic would like to thank these developers for their software contributions.
© Copyright 1997 – 2023 by WinMagic Corp. All rights reserved.

Printed in Canada Many products, software and technologies are subject to export control for both Canada and the United States of America. WinMagic advises all customers that they are responsible for familiarizing themselves with these regulations. Exports and re-exports of WinMagic Inc. products are subject to Canadian and US export controls administered by the Canadian Border Services Agency (CBSA) and the Commerce Department’s Bureau of Industry and Security (BIS). For more information, visit WinMagic’s web site or the web site of the appropriate agency.

WinMagic, SecureDoc, SecureDoc Enterprise Server, Compartmental SecureDoc, SecureDoc PDA, SecureDoc Personal Edition, SecureDoc RME, SecureDoc Removable Media Encryption, SecureDoc Media Viewer, SecureDoc Express, SecureDoc for Mac, MySecureDoc, MySecureDoc Personal Edition Plus, MySecureDoc Media, PBConnex, SecureDoc Central Database, SecureDoc Cloud Lite, MagicEndpoint and MagicEndpoint FIDO Eazy are trademarks and registered trademarks of WinMagic Inc., registered in the US and other countries. All other registered and unregistered trademarks herein are the sole property of their respective owners. © 2023 WinMagic Corp. All rights reserved.

© Copyright 2023 WinMagic Corp. All rights reserved. This document is for informational purpose only. WinMagic Corp. makes NO WARRANTIES, expressed or implied, in this document. All specification stated herein are subject to change without notice.