Posted in

Intune health attestation moves to Azure Attestation: the proxy check to run now

by ailona•

Microsoft Intune will move Windows health attestation compliance evaluation from the Device Health Attestation (DHA) service to Microsoft Azure Attestation (MAA). Message Center posts MC1473600 and MC1473156 call it a service-side change that happens automatically, targeted at the end of the first quarter of 2027. Nothing on the device changes and no policy needs rebuilding. What changes is which endpoints a Windows 11 device has to reach to prove it booted cleanly.

If a firewall or an inspecting proxy blocks the Azure Attestation endpoints your tenant uses, devices with Device Health settings assigned drop out of compliance. That compliance value is what Conditional Access reads, so the symptom arrives as blocked mail and files rather than as an error that names attestation.

Who is actually affected

The scope is narrower than “all Windows devices”. Windows 11 devices with a compliance policy that sets any Device Health option – BitLocker, Secure Boot, Code Integrity – evaluate against MAA. Windows 10 devices and GCC High/DoD tenants keep using DHA at has.spserv.microsoft.com and are not part of this migration. Microsoft states the consequence of getting it wrong without much cushioning:

If unaddressed, Windows 11 devices with assigned compliance policies using any of the device health settings (BitLocker, Secure Boot, Code Integrity) will fall out of compliance.

Windows 11 devices began using the Azure Attestation path in Microsoft’s August 2023 endpoint update, so Intune health attestation is not new client behavior arriving next year. The 2027 change makes compliance evaluation depend on a path that some networks have been quietly getting away with blocking. That is the useful part of the timeline: you can test it today rather than discover it in March 2027.

The endpoints follow your tenant, not the device

The hosts are regional and chosen by your Intune tenant location, so a laptop in London belonging to a North America tenant talks to a North America host. Microsoft’s network endpoints article lists them, all HTTPS on 443:

  • North America: intunemaape1.eus, intunemaape2.eus2, intunemaape3.cus, intunemaape4.wus, intunemaape5.scus, intunemaape6.ncus
  • Europe: intunemaape7.neu, intunemaape8.neu, intunemaape9.neu, intunemaape10.weu, intunemaape11.weu, intunemaape12.weu
  • Asia Pacific: intunemaape13.jpe, intunemaape17.jpe, intunemaape18.jpe, intunemaape19.jpe

Find your tenant location under Intune admin center > Tenant administration > Tenant status > Tenant details, then allow that region’s host. Allowing every host in the list is a reasonable hedge if you would rather not maintain a regional mapping.

An open port 443 is not enough

Two things break this path while looking perfectly healthy in a firewall console.

The first is TLS inspection. Microsoft requires that SSL traffic inspection is not applied to these endpoints, the same rule that already covers *.manage.microsoft.com, *.dm.microsoft.com and the DHA endpoints. A proxy that breaks and re-signs that traffic will happily complete the handshake, log a success, and still leave devices non-compliant, because the attestation request never produces a usable result.

The second is how the allowlist got built. Microsoft now says the older PowerShell scripts that pulled Intune endpoint IPs and FQDNs from the Office 365 Endpoint service no longer return accurate data, and points to the consolidated list in the endpoints article instead. Teams that generate firewall rules from that feed will not see the intunemaape* hosts in their output, no matter how recently they regenerated it.

What to do before the end of Q1 2027

  • Look up your tenant location and note which intunemaape* hosts match it.
  • Confirm outbound TCP 443 to those hosts from your managed network ranges, VPN pools and any guest or branch paths that carry managed devices.
  • Check that no break-and-inspect policy covers that traffic. If your proxy works from category exclusions, add *.attest.azure.net to the exclusion list.
  • If your rules are generated from the Office 365 Endpoint service, add the attestation hosts by hand and note why, so the next regeneration does not silently drop them.
  • Sync a Windows 11 test device that has a Device Health compliance policy assigned, then read the proxy or firewall log for the intunemaape* host. A working attestation shows a request carrying an Entra token; a blocked one shows nothing arriving at all.
  • Brief the service desk on the shape of the ticket: “my device is non-compliant and I cannot get to email”, with no client-side message about attestation. Compliance triage should test network access to the attestation endpoints before it wipes or reimages anything.

Two pointers on the research behind this, both third-party rather than Microsoft. Rudy Ooms traced the client side and shows HealthAttestationClientAgent.exe posting TPM evidence to a regional intunemaape host with an Entra bearer token, which is the request your proxy log should contain. He and Patch My PC also found Intune portal code hinting that MAA can carry claims DHA could not evaluate – ELAM, firmware protection, memory integrity, memory access protection and VBS – but that is an observation from reading portal code, not a Microsoft commitment. The Message Center posts promise the same three settings, evaluated somewhere else.

Sources