Already Windows 8.0 introduced a new possibility of evaluating the health of the boot process called Measured Boot, a recorded variant of the Secure Boot. But the suitable enterprise counter part for checking the health data and enforcing access control was not available at that time.

With Windows 10 1511 the technique was named as Windows Provable PC Health (PPCH) and later on with Windows 1607 and newer renamed to DHA. On Windows Server 2016 the counterpart is named Health Attestation Service (HAS).

But what does DHA exactly? It will combine Secure Boot, VBS, ELAM, and protection of your early-boot drivers and measures them with the help of your TPM 2.0. These measured boot data results are collected by the health attestation configuration service provider (CSP) and sent to a Remote HAS for verification/comparison against current policies:

The health attestation process will check your hardware boot components (for example, PCR values), OS boot components (for example, boot counter) and if Device Guard is enabled, current Device Guard policy. Further on the Windows kernel (for example, signing) will be checked, your ELAM compatible anti-malware will be launched as the first kernel mode driver and measured and last but not least all necessary early boot drivers will be measured.

The last 100 system boot logs and all associated resume logs will be stored in the %SystemRoot%\logs\measuredboot folder. You can control the amount of logs. Set a REG_DWORD named PlatformLogRetention under HKLM\SYSTEM\CurrentControlSet\Services\TPM. By default (if not configured) it is set to 100, but you can disable it with a value of 0x0, set it to a value between 1 and 65534 or keep all logs with 0xffffffff.

When your client is requesting access to a protected corporate resource, your client needs a valid health attestation. The health attestation CSP will send the collected data to the pre-provisioned URI. Currently the DHA service is designed to expect a Microsoft cloud service as HAS counterpart (has.spserv.microsoft.com). An on premises only variant is currently investigated and possibly available in a future release of Windows 10. The collected data is signed and contains your TPM log, the Attestation Identity Key (AIK) data (PCR values, boot counter, and so on) and the AIK certificate information.

The endorsement certificate inside a TPM is unique for each device. The usage of such a unique not changeable certificate for signing client health data would lead to privacy concerns due to the theoretically possible tracking. To avoid this privacy problem Windows 10 uses a derived intermediate key, which can be attested to an endorsement key. This new key is referenced as AIK and its certificate the AIK certificate. The AIK certificate is issued by the HAS service.

The remote device health attestation service verifies the certificate and compares the data against its configured values. If everything is within range, a device health token containing the health information together with a valid issuance time will be generated, encrypted, signed, and sent back to client. The client stores the health encrypted blob in its local store.

These steps are done after activation of health attestation and on every boot and redone as soon as the validity date of the health token expired. When accessing a high-value asset in your corporate environment, the client will send its valid health token to the identity provider and a conditional access decision will grant or deny access. When health criteria are not met or token is outdated no access is granted.

On client side you will need Windows 10 installed in UEFI mode with activated Secure Boot and TPM 2.0. With the current implementation of DHA you will need on backend side the HAS Microsoft cloud service, a MDM solution supporting DHA (for example, InTune) and Azure AD standalone or Azure AD with AD connector in hybrid mode.

Use of VBS, Credential Guard and Device Guard for further improving security is recommended.

The activation of health attestation on client side will be done as part of enrollment with the MDM provider. Without configuration health attestation will be disabled by default.

Further information about DHA and Office365 access control can be found at https://docs.microsoft.com/en-us/windows/device-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.

DHA is a consequent improvement over the discontinued Network Access Protection (NAP). It will provide an easy way to increase device security and integrity without boss around your users.