Intune health attestation is moving to Azure Attestation: prepare before compliance breaks

Three of the most common Windows compliance settings, Require BitLocker, Require Secure Boot to be enabled on the device and Require code integrity, don't read the device's state directly: they rely on a health attestation service in the cloud. Microsoft is moving that evaluation for Windows 11 from the Device Health Attestation (DHA) service to Microsoft Azure Attestation (MAA). If your firewall or proxy doesn't allow the new endpoints, those settings fail and Conditional Access does the rest. Here is what changes and how to get ahead of it.

What is changing#

When a Windows compliance policy requires BitLocker, Secure Boot or code integrity, the device produces TPM-backed boot measurements and Intune has them validated by an attestation service; the result drives the compliance verdict. Today that service is DHA, reachable at has.spserv.microsoft.com. Microsoft Intune will migrate Windows Health Attestation compliance evaluation from DHA to Microsoft Azure Attestation. There is nothing to switch on in the admin center; the change happens on the service side.

The Intune network endpoints page already documents the new behaviour: with any device health setting enabled, Windows 11 devices use an MAA service chosen by the Intune tenant's location, while Windows 10 devices and GCC High/DoD environments continue to use the existing DHA endpoint and aren't affected.

Who is affected#

• Windows 11 devices assigned a compliance policy that sets any of Require BitLocker, Require Secure Boot to be enabled on the device or Require code integrity to Require.
• Organisations with restrictive outbound rules or TLS inspection, where *.attest.azure.net traffic isn't allowed today.
• Not affected per Microsoft: Windows 10 devices, and tenants in GCC High and DoD, which stay on DHA.

Note that Require encryption of data storage on device under System security is a different check that doesn't use health attestation. Only the three Device Health settings are in scope.

What breaks if you do nothing#

Microsoft's wording is direct: if the required Azure Attestation endpoints aren't reachable, Windows 11 devices with assigned compliance policies using any of the device health settings will fall out of compliance after the migration completes. For most tenants that means Conditional Access blocks sign-in from those devices, and the per-setting view in the device's compliance report shows the three health settings as Not compliant. Nothing about the devices will have changed, which makes this one hard to recognise if you haven't read the announcement.

What to do now#

1. Find the policies that use the health settings#

In the admin center, open each Windows policy under Devices › Compliance › Policies and look at the Device Health section. With more than a handful of policies, let Microsoft Graph PowerShell do it:

Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
$uri = 'https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies'
$policies = (Invoke-MgGraphRequest -Method GET -Uri $uri).value
$policies |
    Where-Object { $_.'@odata.type' -eq '#microsoft.graph.windows10CompliancePolicy' } |
    Where-Object { $_.bitLockerEnabled -or $_.secureBootEnabled -or $_.codeIntegrityEnabled } |
    Select-Object displayName, bitLockerEnabled, secureBootEnabled, codeIntegrityEnabled

Check each policy's assignments so you know which device groups are exposed.

2. Look up your tenant location#

Go to Tenant administration › Tenant status › Tenant details and read Tenant location. The required endpoints depend on it.

3. Allow the endpoints and exclude them from TLS inspection#

Microsoft asks for outbound HTTPS on port 443 to the endpoints for your tenant location, with no SSL traffic inspection on them. The names below are copied from the Intune network endpoints page on Microsoft Learn; the Azure region code in each name (eus, cus, wus, scus, ncus, neu, weu, jpe) shows which tenant-location group it belongs to:

Keep has.spserv.microsoft.com allowed as well: Windows 10 devices still need it, and the same Learn page says TLS inspection isn't supported for the DHA endpoints either.

4. Test from a device#

Run the test in the system context (for example through PsExec with -s), because the attestation client is a system component and uses the machine's proxy configuration rather than the signed-in user's:

$h = 'intunemaape7.neu.attest.azure.net'   # pick one for your tenant location
Test-NetConnection -ComputerName $h -Port 443 | Select-Object ComputerName, TcpTestSucceeded

$tcp = New-Object Net.Sockets.TcpClient($h, 443)
$cb  = [Net.Security.RemoteCertificateValidationCallback]{ $true }
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(), $false, $cb)
$ssl.AuthenticateAsClient($h)
(New-Object Security.Cryptography.X509Certificates.X509Certificate2($ssl.RemoteCertificate)).Issuer

TcpTestSucceeded should be True, and the certificate issuer should be a Microsoft CA. If the issuer is your proxy's internal CA, the host is still being inspected.

5. Pilot before the target date#

Put the firewall change in place well before Q1 2027 ends, then watch a pilot group's compliance report for a few weeks. Because the health state is only measured at boot, restart pilot devices after the network change before you judge the result.

How to verify#

• In Devices › Compliance, open a pilot device and confirm the three Device Health settings show Compliant after a restart and a sync.
• The connectivity test above passes from the system context on every network path your devices use, including VPN and remote offices.
• After the migration date, repeat the check on a sample of Windows 11 devices and watch the noncompliant-device count in Reports › Device compliance for an unexplained jump.

Timeline#

• 16–17 September 2026: MC1473156 and MC1473600 published; Learn endpoints page documents the MAA endpoints.
• Now until early 2027: inventory policies, change firewall and proxy rules, test and pilot.
• End of Q1 2027 (target): Intune switches Windows 11 health attestation evaluation to Azure Attestation automatically.

References#

• Network endpoints for Microsoft Intune (section: Migrating device health attestation compliance policies to Microsoft Azure attestation)
• Device compliance settings for Windows in Intune
• MC1473600: Intune: Windows Health Attestation Migration to Microsoft Azure Attestation (Microsoft 365 admin center › Message center, published 17 September 2026)