Device Integrity Protection - How to ensure escrow of device recovery data (Data Encryption Key or DEK) has completed before the device is connected to any untrusted networks.

While SecureDoc performs an invaluable service ensuring that data is protected by encryption, and that user access to SecureDoc-protected devices is locked down and governed by permitting only specific users to authenticate at Pre-Boot, there are other risks that any security-conscious organization should be aware of and include in its overall security design.

Ensure escrow of device recovery data (Data Encryption Key or DEK) has completed before the device is connected to any untrusted networks.

In the vast majority of SecureDoc Enterprise Server-managed customer environments, the SecureDoc client software is installed while the device is on the implementing company's corporate LAN, or has access to it.

During the early stages of the implementation of the SecureDoc client, it will reach out across the network to the SES server (through SDConnex) and either transmit the Data Encryption Key (DEK) it has created locally, or request and receive a DEK created by the SES server.  
In either case, this encryption key will have been automatically escrowed in the SES database, stored in an encrypted field within the database.

In rare situations where network access to the SES server is not part of the deployment plan (such as for remote devices that have no network access back to SES, or devices that are not intended to participate on a network), then WinMagic recommends that the Machine Info File is created at the earliest possible opportunity and delivered for import into the SES Database before such devices are exposed to untrusted networks.

Further, as a best practice WinMagic recommends that any SecureDoc-protected device has an opportunity to complete its initial Full Disk Encryption (FDE) before being connected to any untrusted networks