Win8: Security: Device wipe and device lock behavior across operating system versions and devices

Applies to: Surface RTWindows RTWindows 8


This article describes device wipe and device lock behavior for various operating system versions and devices.

Device wipe (also known as "remote wipe") is an Exchange ActiveSync (EAS) directive in which a user or administrator triggers a wipe of a device. Specifically, a user goes to Outlook Web App and then triggers the device wipe behavior, or a Microsoft Exchange administrator invokes device wipe.

Device lock behavior is triggered when the bad-password count exceeds the MaxDevicePasswordFailedttempts threshold. Device lock behavior in response to failed sign-in attempts differs, depending on operating system versions, device type, and whether the device is protected by BitLocker.

Device lock behavior includes the following:
  • A full wipe of the device and a return to default settings
  • The targeted deletion of application-specific data such the inbox, contacts, and calendar items for a mail application
  • Halting applications and logon sessions and invoking operating system restarts to stop in-memory attacks and network sessions
  • Putting the device in BitLocker recovery mode
Companion devices such as smartphones implement a wipe as a general practice. The nature of the phone’s physical storage, together with the companion nature of the device, makes this an appropriate design choice.

The EAS protocol does not dictate a device wipe or a dataset delete when the MaxDevicePasswordFailedAttempts threshold is reached. Because Windows-based computers are frequently a user’s primary device on which single instances of photos, documents, and other data exist, device wipe is an unfriendly option. This is especially true because device wipe is usually invoked when friends or family type an incorrect log-in. The situation in Windows is made even more complex by the multiple-user support that we offer. This contrasts with smartphones.

There is no security boundary on Windows-based computers that are not encrypted, although they will restart and close all active sessions if the threshold is reached.

Windows 8 and Windows 8 RT address the security and usability of the MaxDevicePasswordFailedttempts compliance action through the BitLocker feature set and the consequent locking of the device.

For encrypted computers, device encryption is enabled automatically when the first Microsoft account log-in that is a member of the local Administrators security group is used in the out of box experience (OOBE). This should include most Windows RT-based devices.

Exceeding the MaxDevicePasswordFailedAttempts threshold on BitLocker-protected Windows RT-based devices and Windows 8 business SKUs will result in the closing of all active logon sessions, a restart of the computer, and the requirement that the BitLocker (or Device Encryption) recovery key be provided to unlock the volume.

It is our stance that BitLocker or Device Encryption protection is equal to or greater than the protection that is offered by wipe behavior on other devices, because Windows protects the integrity of all bits on the drive, and because tools such as restore and deeper storage analysis cannot recover anything off the volume other than encrypted bits.

For users and administrators who want device wipe, that option remains available for standard users through the Outlook Web App (OWA) interface and in Exchange for those who have administrative permissions.

More Information

Remote wipe

Remote device wipe may be triggered when a standard user account uses OWA or when an administrator uses the Exchange administrator tools. The following screen shot shows the device wipe UI in Outlook Web App for a Windows Mobile phone. The UI is triggered by clicking the "device wipe" button (highlighted in red).

The screen shot showing the device wipe UI in Outlook Web App for a Windows Mobile phone

The following table shows the behavior of a mail app when the app receives a device wipe directive from a server.
BehaviorWindows Phone 7Windows Phone 8Windows 7Windows 8 RT
(Surface devices)
Windows 8
Wipes corporate email account (mail, calendar, and so on)YesYesNot applicableYesYes
Wipes saved attachmentsYesYesNot applicableNoNo
Wipes personal emailYesYesNot applicableNoNo
Wipes device and restores to factory defaultsYesYesNot applicableNoNo

The mail apps for Windows Phone 7 and Windows Phone 8 behave identically when a device wipe directive is received. In both cases, the whole device is wiped and restored to factory defaults.

The mail apps for Windows 8 and Windows RT also both behave in the same manner. The mail app will delete everything in the application's app container that was associated with the account that was remotely wiped. If files were manually stored outside the app container by the user, those files will not be deleted. (For example, this is true if an attachment was saved.)

The philosophy behind moving away from a full wipe in Windows 8 was to make sure that no personal data (personal documents, pictures, and so on) is deleted if a device wipe directive is issued by an administrator.

For more information, go to the following Microsoft TechNet blog:
The "Remote Wipe" section of this link reads as follows:

"Mail supports the Exchange ActiveSync remote wipe directive, but unlike Windows Phones, the data deleted by this directive is scoped to the specified Exchange ActiveSync account. The user's personal data is not deleted. For example, if a user has an account for personal use and a account for work use, a remote wipe directive from the server would impact Windows 8 and Windows Phone 7 as follows:"
DataWindows Phone 7Windows 8 Mail email DeletedDeleted contacts DeletedDeleted calendars DeletedDeleted email DeletedNot deleted contacts DeletedNot deleted calendars DeletedNot deleted
Other documents, files, pictures, etc. DeletedNot deleted
Full device wipe and return to factory defaultsYesNo

Device lock

Device lock behavior for Windows Surface RT

Philosophy changes around device wipe in Windows 8
The Windows Phone 7 device lock behavior consisted of all user data being completely deleted and the device being reset to factory defaults. This behavior was losing its appeal for the following reasons:
  • Toddlers, family, and friends were triggering accidental device wipes on corporate-joined phones even though there was no legitimate security threat.
  • Although phones are single-user devices, Windows 8 and Windows 8 RT devices are multiuser devices that host data on behalf of multiple users.
  • Phones and mobile devices are increasingly used for originating and storing significant personal and corporate data. Although contacts, calendar, and inbox are already backed up by a user's Exchange server, such originating data was frequently not backed up off the device.
  • Windows 8 and Windows RT devices that support BitLocker could effectively protect data instead of deleting data that was potentially not backed up.
  • Remote wipe is a push operation and requires that the remote device establish a connection with remote servers. Changing the user's password breaks the device wipe. The inability to reset the password until the device wipe event occurs potentially put resources on the corporate network at risk.
  • Tight integration between the hardware, operating system, Microsoft account, and cloud services enables the invocation of BitLocker recovery mode. This is a feature differentiator that protects both the information owner and the device owner.
BitLocker and device wipe
  • By default, there is no local device wipe or bad-password threshold defined.
  • The local hard disk is BitLocker encrypted but not BitLocker protected.
  • If "Number of sign-in failures before device is wiped" is exceeded in Exchange ActiveSync policy, mail, contacts, and calendar data is deleted from the account according to the scheme that is outlined in the first table.
  • The first logon of a Microsoft account that is a member of the local computer's Administrative security group BitLocker-encrypts the local drive. A restart is required to complete the operation.
  • The BitLocker recovery key is put on that user's OneDrive share. However, the presence of that key is not reported on the OneDrive share.
  • Exceeding the bad-password limit that is defined in Exchange ActiveSync Device policy invokes BitLocker recovery mode from that point forward.
  • Users must connect to to obtain the BitLocker recovery key. This BitLocker enable and recovery workflow is described in the following article in the Microsoft Knowledge Base:
    2803767 Win8: BitLocker: BitLocker device encryption workflow in Windows 8 RT

Related content

LinkSynopsis table of Exchange ActiveSync clients. This includes device wipe support for Windows Mobile 6.1 through Windows Mobile 7.5 and third-party devices from Apple, Nokia, Android, and other companies.
Exchange blog post that compares device wipe behavior on Windows Phone 7 devices and on Windows 8 mail clients.
Managing Windows Phone 8 with Microsoft Intune
The following screen shot of the Exchange ActiveSync Device Policy (in this case, from Office 365) includes the Number of sign-in failures before device is wiped option.

The screen shot showing the Exchange ActiveSync Device Policy