What Is Device Health Attestation?
Device Health Attestation (DHA) is a Windows platform service that allows organisations to verify the security posture of endpoints at boot time. Rather than relying on software-based reports that malware could falsify, DHA uses hardware-rooted measurements collected by the Trusted Platform Module (TPM) and the Windows boot process to attest that a device booted securely, that BitLocker is active, that Secure Boot is enabled, and that no tampering occurred before the operating system loaded.
These boot-time measurements are stored in the TPM’s Platform Configuration Registers (PCRs) and signed by the TPM’s endorsement key. The DHA service validates these signed measurements against known-good values and issues a Health Certificate that MDM (Mobile Device Management) and compliance systems can consume to make access control decisions. If a device cannot prove it is healthy, policies can block it from accessing corporate resources.
DHA-Cloud vs DHA-On-Premises
Microsoft offers two deployment models for Device Health Attestation:
DHA-Cloud: Devices send their TPM measurements to the Microsoft-hosted DHA service at has.spserv.microsoft.com. This requires no on-premises infrastructure but means measurements leave your network perimeter. DHA-Cloud is the default configuration in Intune and is suitable for most organisations using Microsoft 365 E3/E5 or Azure AD-joined fleets.
DHA-On-Premises (DHA-Service): Microsoft provides the Device Health Attestation server role for Windows Server 2016 and later, including Windows Server 2022. This keeps TPM measurement data entirely within your infrastructure. The on-premises service replicates the Microsoft DHA cloud API, meaning the same MDM policies work against either endpoint. On-premises DHA is required for air-gapped environments or where data sovereignty rules prohibit sending device telemetry externally.
Prerequisites
Before deploying DHA, verify the following:
Client requirements: Managed devices must be running Windows 10 version 1507 or later, Windows 11, or Windows Server 2016 or later. Each device requires TPM 2.0 (TPM 1.2 is supported in a limited capacity for DHA-Cloud only). UEFI firmware with Secure Boot support is strongly recommended.
Server requirements (on-premises only): Windows Server 2016, 2019, or 2022 with at least 4 GB RAM, 2 vCPUs, and 20 GB disk. The DHA server must have HTTPS inbound access from managed devices on port 443. It also requires access to a SQL Server instance for its database (SQL Server 2012 SP4 or later, or SQL Server Express for small deployments).
Certificate requirements: A valid SSL/TLS certificate is required for the DHA server’s HTTPS endpoint. This should be issued by an internal CA trusted by all managed devices. You will also need a signing certificate for the Health Certificates the DHA server issues.
Verify TPM 2.0 presence on a client:
Get-Tpm
Expected output includes TpmPresent : True, TpmReady : True, and the TPM version listed under manufacturer info. You can also check in Device Manager under Security Devices.
Installing the DHA Server Role on Windows Server 2022
On your designated DHA server, open an elevated PowerShell console and install the Device Health Attestation feature:
Install-WindowsFeature DeviceHealthAttestation -IncludeManagementTools
After the role installs, confirm it is present:
Get-WindowsFeature DeviceHealthAttestation
The feature includes an IIS-based web service. Ensure IIS is running:
Get-Service W3SVC | Start-Service
Set-Service W3SVC -StartupType Automatic
Configuring the DHA Database
The DHA service requires a SQL Server database to store attestation records. If you are using SQL Server Express on the same machine, install it separately, then run the DHA configuration cmdlet specifying the connection string:
Initialize-DHASDatabase `
-DatabaseConnectionString "Data Source=localhostSQLEXPRESS;Initial Catalog=DHA;Integrated Security=True" `
-SkipDatabaseCompatibilityCheck
For a remote SQL Server:
Initialize-DHASDatabase `
-DatabaseConnectionString "Data Source=sql01.corp.local;Initial Catalog=DHADatabase;Integrated Security=True"
The DHA service account needs db_owner permissions on the DHA database. Grant this in SQL Server Management Studio or via T-SQL:
USE [DHADatabase]
CREATE USER [DOMAINDHAServerComputerAccount$] FOR LOGIN [DOMAINDHAServerComputerAccount$]
ALTER ROLE db_owner ADD MEMBER [DOMAINDHAServerComputerAccount$]
Configuring DHA Certificates
The DHA service requires two certificates: one for the HTTPS endpoint and one for signing issued Health Certificates. Both should be obtained from your internal PKI. You can request them using the Certificates MMC snap-in or via PowerShell against your CA:
# Request a web server certificate
$cert = Get-Certificate `
-Template WebServer `
-DnsName "dha.corp.local" `
-CertStoreLocation Cert:LocalMachineMy
# View the thumbprint
$cert.Certificate.Thumbprint
Once you have both certificates, configure the DHA service:
Set-DHASActiveSigningCertificate -Thumbprint "AABBCC..." -Force
Set-DHASActiveEncryptionCertificate -Thumbprint "DDEEFF..."
Bind the SSL certificate to the IIS site used by DHA (typically port 443):
netsh http add sslcert ipport=0.0.0.0:443 certhash=AABBCC... appid="{your-app-guid}"
Configuring DHA in Microsoft Intune
With DHA-Cloud (the default), configuration in Intune involves creating a Device Compliance Policy that evaluates DHA health measurements. In the Intune admin centre (endpoint.microsoft.com), navigate to Devices > Compliance policies > Create policy, select Windows 10 and later as the platform, then under Device Health configure the following settings:
- Require BitLocker: Yes
- Require Secure Boot to be enabled: Yes
- Require code integrity: Yes
For on-premises DHA, you additionally specify the DHA service URL. In Intune, under Endpoint security > Device health attestation (or via a configuration profile), set the DHA service URL to your on-premises endpoint, e.g., https://dha.corp.local/DeviceHealthAttestation.
Using PowerShell with the Intune Graph API:
# Example: query a device's compliance status using Microsoft Graph
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice `
-Filter "deviceName eq 'WORKSTATION01'" |
Select-Object DeviceName, ComplianceState, LastSyncDateTime
DHA Health Measurements Explained
The DHA service evaluates several boot-time measurements to construct the Health Certificate:
Boot Manager Hash: The TPM measures the Windows Boot Manager binary (bootmgfw.efi) and stores its hash in PCR4. Any modification to the Boot Manager (such as a bootkit) will produce a different hash, causing attestation to fail.
BitLocker Status: DHA reports whether BitLocker is active on the OS volume. The measurement is extracted from the BitLocker status stored in the TPM’s sealed blob. Devices without BitLocker enabled can be flagged as non-compliant.
Secure Boot: The DHA service checks whether UEFI Secure Boot was enabled throughout the boot sequence. This is stored in a separate PCR register and cross-checked against the UEFI firmware’s event log.
Code Integrity Policy: DHA can report whether Windows Defender Application Control (WDAC, formerly Device Guard) code integrity policies were active at boot time. This prevents unsigned drivers and executables from loading in kernel mode.
Integrating DHA with SCCM Compliance Policies
If you are using Microsoft Configuration Manager (SCCM/MECM) rather than Intune, Device Health Attestation can be evaluated through SCCM compliance rules. In the SCCM console, navigate to Assets and Compliance > Compliance Settings > Compliance Policies and create a new policy. Under Rules, add rules that query DHA health properties:
# SCCM WMI-based DHA query on a client to inspect reported health
Get-WmiObject -Namespace rootcimv2mdmdmmap `
-Class MDM_DeviceStatus `
-ComputerName CLIENT01 |
Select-Object HealthAttestationStatus
Devices that fail DHA checks can be automatically placed in a non-compliant collection and denied access to software distribution or configuration profiles.
Troubleshooting Device Health Attestation
On the DHA server, review the event logs under Applications and Services Logs > Microsoft > Windows > DeviceHealthAttestation. Common errors include certificate validation failures and database connection issues.
On the client side, query the local DHA status:
Get-WmiObject -Namespace rootcimv2mdmdmmap -Class MDM_HealthAttestation
To force a DHA re-evaluation on a managed Windows 10/11 client:
# Trigger a sync cycle in the MDM client
$session = New-CimSession -ComputerName CLIENT01
Invoke-CimMethod -CimSession $session `
-Namespace rootcimv2mdmdmmap `
-ClassName MDM_Client `
-MethodName "MDMClientSync"
If TPM measurements are failing, check that the TPM is cleared of stale attestation data using the TPM Management Console (tpm.msc) or:
Clear-Tpm
Note that clearing the TPM will destroy any existing TPM-protected keys, including BitLocker protectors. Save the BitLocker recovery key before clearing the TPM on a BitLocker-encrypted device.