Share via

Device Encryption


Device encryption refers to the ability to protect local device data from offline hardware attacks by employing encryption. This is achieved by employing a file-based encryption filter. The master key for the encryption is protected with the user’s device lock PIN. When device encryption is enabled, during bootup the user is prompted to enter the PIN. Until the PIN is entered, bootup is suspended and the only device functionality available is the ability to make emergency calls. After the correct PIN is provided, bootup continues and the device functions as normal. Encryption/Decryption is on demand and is transparent to both applications and the end user.

Device encryption is enabled through XML policy. The following table shows the data that is encrypted when device encryption is enabled.

Description Example location

User documents

\My Documents

Sync email


PIM data


Sync email stream properties


Sync email attachments


Temporary internet cache

\windows\profiles\guest\Temporary Internet Files

Additional files and directories can be encrypted by providing appropriate XML through XML policy.

Adapting applications to work with device encryption

When device encryption is enabled, bootup is suspended until the PIN is provided. During this time encrypted data cannot be accessed. Applications or services that start early during the boot process and access encrypted data will need to be modified. Following are some guidelines.

  1. Enable device encryption and make sure that your service/application behaves correctly with encryption enabled. The following registry key can be set to help troubleshoot issues:
    Key Name - HKLM\Comm\Security\SDP
    Value name - EnableCallerLogging
    Value type – DWORD
    1 – enabled
    When logging is enabled and encrypted data is accessed prior to boot unlock, then a Watson log is generated. This log can be inspected to narrow down code path where encrypted data is being accessed.
  2. If a service or application accesses encrypted data early during boot, then modifications must be made for the service or application to function properly when device encryption is enabled. This can be achieved in one of the following ways:
    • If an application is a service, the following registry key can be set during service configuration to delay loading the service until encrypted data is accessible:
      For example:
    • For non-service applications that are in the boot order, a dependency to sdpready.exe can be added to delay the start of the application until encrypted data is accessible.
  3. A service or application can block for the SDP_DATA_AVAILABLE event. This event is signaled once encrypted data is accessible:


  • The DeviceEncryption configuration service provider allows for additional files and directories to be encrypted through policy. Such policies should first be tested to ensure proper device functionality because if key files needed for the system to boot up are specified in the encryption list, then the device will cease to function correctly. For example, the path \...\* encrypts all files on the device including files needed for the system to boot up. This is not a valid policy and testing prior to deployment of custom policies will help catch such issues.
  • Device encryption is supported only when the default Microsoft device lock solution is deployed. Currently there is no support for third-party device lock solutions.
  • Prior to switching to a third-party device lock solution, if device encryption was enabled, it should be turned off through policy.
  • Device encryption can be enabled through XML policy only. There is no user control panel for device encryption.

See Also

Other Resources

Security for Windows Mobile Devices
DeviceEncryption Configuration Service Provider