Intune Is Moving Windows Health Attestation to Azure Attestation — Update Your Firewall Before Devices Become Noncompliant

Watch this post — YouTube walkthrough

Intune Health Attestation Moves to Azure Attestation — Fix Your Firewall Before H1 2027

Endpoint Weekly

Watch on YouTube Subscribe at @EndpointWeekly

The problem: how a firewall gap becomes a Conditional Access lockout

Microsoft announced on 17 September 2026 that Intune will automatically migrate Windows 11 device health attestation from Device Health Attestation (DHA) to Microsoft Azure Attestation (MAA) in H1 2027. No admin opt-in is required. The migration happens in the background, and Intune will start routing attestation traffic to new regional endpoints instead of the legacy DHA service.

The risk is not the migration itself. It is what happens on the day a device in your estate tries to attest against an MAA endpoint for the first time, and your firewall has no rule to allow it.

Any Windows 10/11 compliance policy that evaluates these three settings uses the health attestation chain:

• Require BitLocker — whether the drive encryption key is TPM-bound and attestation-verified
• Require Secure Boot to be enabled — TPM-attested boot state, not a WMI query
• Require code integrity — whether the boot chain is signed and verified

None of these settings can be evaluated by the device directly. Intune sends the device's TPM-attested boot log to the health attestation service, the service validates it against its signing chain, and the resulting health certificate is what drives the compliance verdict. Break the path to the attestation service, and the compliance verdict goes to "Not compliant" — the policy cannot return "Compliant" for any of those three settings when it cannot reach the service to validate them.

In an estate where a Conditional Access policy requires a compliant device, a broken attestation chain is not just a reporting problem. It is an access problem.

Windows 10 devices and tenants in the GCCH (Government Community Cloud High) and DoD clouds are not affected — they remain on the DHA service. Only Windows 11 devices in commercial and GCC tenants will use MAA.

Why it happens: the DHA to MAA architecture shift

Device Health Attestation has been part of Windows since Windows 10. At compliance evaluation time, Windows runs HealthAttestationClientAgent.exe — a component in %windir%\System32\HealthAttestationClient\ — which collects a signed measurement of the boot sequence from the device's TPM and sends it to Microsoft's cloud attestation service. The cloud service validates the TPM-signed boot log against known good values for Secure Boot, BitLocker, and Code Integrity, and returns a signed health certificate that Intune can verify.

Until now, all commercial tenants have used the same shared DHA service at has.spserv.microsoft.com. Microsoft Azure Attestation (MAA) replaces this with a per-tenant, regionally hosted attestation service. Your Intune tenant will be assigned to an MAA endpoint in the Azure region closest to your tenant's home location — intunemaape1.attest.azure.net through intunemaape9.attest.azure.net, depending on region.

The attestation flow after migration:

1. HealthAttestationClientAgent.exe collects a TPM-attested boot log (same as before)
2. Instead of sending to has.spserv.microsoft.com, it sends to your tenant's MAA endpoint — e.g. intunemaape2.attest.azure.net
3. MAA validates the measurement log and returns a signed token
4. The Intune Management Extension (IME) collects the token and sends compliance evaluation results to Intune
5. Intune evaluates BitLocker, Secure Boot, and Code Integrity using the MAA-signed token

The change is transparent to the end user and to the device — except at the network layer. Any firewall rule that was written for has.spserv.microsoft.com will not match the new endpoint. And because the new endpoint is tenant-specific, a generic Microsoft 365 or Intune allowlist that has not been updated to include MAA will not cover it either.

When the MAA endpoint is unreachable, HealthAttestationClientAgent.exe cannot obtain a signed attestation token. After exhausting retries, Intune reports the health-attested compliance settings as unable to be verified — the affected settings surface as "Not compliant" in the Intune admin center and in any Conditional Access evaluation for that device. The compliance failure is reported through the standard Intune MDM compliance pipeline and appears in the device's compliance details in the Intune portal.

How to verify: find affected policies and test MAA reachability

Step 1 — Identify compliance policies that use health attestation

The fastest way to find every affected policy is to query the Graph API for Windows compliance policies and check their health attestation settings. You can do this with the companion script below, or with a quick Graph Explorer query.

In Graph Explorer (or via PowerShell), query all compliance policies and filter for Windows 10/11 policies with any of the three health-attested settings enabled:

# Connect to Graph with Intune read access
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

$policies = Invoke-MgGraphRequest -Method GET `
    "/beta/deviceManagement/deviceCompliancePolicies"

$affected = $policies.value | Where-Object {
    $_['@odata.type'] -eq "#microsoft.graph.windows10CompliancePolicy" -and (
        $_['bitLockerEnabled']       -eq $true -or
        $_['secureBootEnabled']      -eq $true -or
        $_['codeIntegrityEnabled']   -eq $true
    )
}

$affected | Select-Object displayName, bitLockerEnabled, secureBootEnabled, codeIntegrityEnabled | Format-Table -AutoSize

# Example output — healthy attestation chain:
# displayName               bitLockerEnabled  secureBootEnabled  codeIntegrityEnabled
# -----------               ----------------  -----------------  --------------------
# Win11 Compliance Baseline         True              True                 True
# BYOD Windows Policy               False             True                 False

Any policy returned here is affected by the MAA migration. Take note of the policy names — you will need them when you pilot the fix later.

Step 2 — Identify how many Windows 11 devices are in scope

Not every device in your Intune tenant is affected. Only Windows 11 devices with a health-attested compliance policy assigned are at risk. Use the Graph API to get the count:

# Count Windows 11 managed devices
$win11 = Invoke-MgGraphRequest -Method GET `
    "/beta/deviceManagement/managedDevices?`$filter=operatingSystem eq 'Windows' and osVersion startsWith '10.0.2'&`$count=true&`$top=1" -Headers @{'ConsistencyLevel'='eventual'}

Write-Host "Windows 11 managed devices in tenant:" $win11['@odata.count']

# Windows 11 OS versions start at 10.0.22000 (21H2) through 10.0.26xxx (25H2+)
# Windows 10 stays at 10.0.19xxx - not affected by MAA migration

Step 3 — Test MAA endpoint reachability from SYSTEM context

This step is where most administrators get caught. Running Test-NetConnection from a regular PowerShell window tests connectivity from your user account, using your user-level proxy settings. Health attestation runs under the SYSTEM account, which uses WinHTTP system-wide proxy settings — a completely separate proxy configuration.

A test that passes from a user session can still fail for HealthAttestationClientAgent.exe if your proxy is configured differently for the SYSTEM context.

To test MAA connectivity from the SYSTEM context, create a scheduled task that runs the connectivity test as SYSTEM and writes the result to a file:

# MAA endpoints to test (all 9 regional variants)
$endpoints = 1..9 | ForEach-Object { "intunemaape$_.attest.azure.net" }

$scriptBlock = @"
`$results = @()
`$endpoints = $(($endpoints | ConvertTo-Json -Compress))
foreach (`$ep in (`$endpoints | ConvertFrom-Json)) {
    `$test = Test-NetConnection `$ep -Port 443 -InformationLevel Quiet -WarningAction SilentlyContinue
    `$results += [PSCustomObject]@{ Endpoint=`$ep; TcpTestSucceeded=`$test }
}
`$results | Export-Clixml C:\Temp\maa-connectivity-test.xml
"@

# Create scheduled task running as SYSTEM
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($scriptBlock))
$action   = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NonInteractive -EncodedCommand $encoded"
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
Register-ScheduledTask -TaskName "MAAConnTest" -Action $action -Principal $principal -Force | Out-Null
Start-ScheduledTask -TaskName "MAAConnTest"
Start-Sleep -Seconds 15

# Read results
$results = Import-Clixml "C:\Temp\maa-connectivity-test.xml"
$results | Format-Table -AutoSize
Unregister-ScheduledTask -TaskName "MAAConnTest" -Confirm:$false

# BLOCKED - output looks like:
# Endpoint                          TcpTestSucceeded
# --------                          ----------------
# intunemaape1.attest.azure.net     False
# intunemaape2.attest.azure.net     False
#
# HEALTHY - output looks like:
# Endpoint                          TcpTestSucceeded
# --------                          ----------------
# intunemaape1.attest.azure.net     True
# intunemaape2.attest.azure.net     True

If any endpoint shows TcpTestSucceeded: False from SYSTEM context, you have a firewall or proxy block that will cause attestation failures after the MAA migration. Proceed to the fix section.

Also check the current WinHTTP proxy configuration to understand what SYSTEM is routing through:

Step 4 — Check MDM compliance events on a representative device

There is no standalone HealthAttestation event log channel on Windows 11. The attestation client (HealthAttestationClientAgent.exe) runs in SYSTEM context as part of the MDM compliance evaluation pipeline — it is an executable agent, not a Windows service, so it does not appear in services.msc or respond to Get-Service.

Attestation failures surface in two places. First, in the Intune admin center on the device's compliance detail page — the health-attested settings (BitLocker, Secure Boot, Code Integrity) will show as "Not compliant" or "Error" with a message indicating the compliance result could not be retrieved. Second, general MDM compliance events appear in the Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin log in Event Viewer:

For deeper diagnostics — particularly if devices are reporting "Error" rather than "Not compliant" — use MdmDiagnosticsTool.exe to collect a full MDM diagnostic bundle:

MdmDiagnosticsTool.exe -area Autopilot;TPM;DeviceProvisioning;DeviceEnrollment -cab C:\Temp\MDMDiag.cab

Windows components reference: what is actually installed

The health attestation stack on Windows 11 is file-based. There is no standalone HealthAttestation Windows service. The files installed in %windir%\System32\HealthAttestationClient\ handle the entire attestation flow:

Additionally, %windir%\System32\AttestationWmiProvider.dll exposes a WMI v2 interface so the MDM client can query attestation state, and hgattest.dll handles the low-level TPM interaction for collecting the signed boot measurement.

The fix: firewall rules, SSL inspection bypass, and piloting

Step 1 — Add the MAA endpoints to your firewall allowlist

Microsoft requires outbound HTTPS (port 443) to the following endpoint pattern for all Windows 11 devices managed by Intune in public cloud:

For network devices that do not support wildcard FQDN rules, list all nine endpoints explicitly. You do not need to know in advance which one your tenant will use — allowlisting all of them is the correct approach. The individual endpoints that do not match your tenant's assigned MAA instance will simply not receive traffic.

Step 2 — Exclude MAA endpoints from SSL/TLS inspection

Microsoft's networking documentation for Intune explicitly states that MAA endpoints must not have SSL inspection performed on them. This is not optional guidance. The health attestation flow uses TPM-attested tokens that are signed by the device's TPM and verified by the MAA service. An SSL-inspecting proxy that presents its own certificate instead of the MAA service's certificate will cause the attestation flow to fail, even if the proxy allows the traffic through.

The bypass configuration process varies by proxy product:

Step 3 — Configure WinHTTP proxy bypass on devices (Intune)

If your devices use a WinHTTP proxy and you cannot modify the proxy's SSL inspection rules, you can configure the bypass on the device side. The WinHTTP proxy bypass list tells the SYSTEM account to connect directly to the listed endpoints without routing through the proxy. This is the device-level equivalent of a "no decrypt" rule on the proxy itself.

Deploy this via Intune Settings Catalog or Group Policy:

Intune Settings Catalog path:

Group Policy path (equivalent GPO for hybrid-managed devices):

1. Open gpmc.msc and create or edit a GPO linked to the OU containing your Windows 11 devices.
2. Navigate to Computer Configuration › Administrative Templates › Windows Components › Internet Explorer › Internet Control Panel › Connections › Proxy Settings.
3. Enable Do not use proxy server for addresses beginning with and add *.attest.azure.net.
4. Alternatively, use the OMA-URI custom profile in Intune: ./Device/Vendor/MSFT/NetworkProxy/ProxySettingsPerUser set to 0 (system-wide proxy, not per-user) and ./Device/Vendor/MSFT/NetworkProxy/Exceptions containing *.attest.azure.net.

Step 4 — Deploy as an Intune Proactive Remediation

Before the H1 2027 migration fires, use the companion detect script to find every device in your fleet where MAA endpoints are currently unreachable from SYSTEM context. Deploy it as a Proactive Remediation to get a count without taking any action on the devices.

1. Sign in to the Intune admin center.
2. Go to Devices › Scripts and remediations › Proactive remediations.
3. Select Create and give it a name, e.g. "MAA Endpoint Reachability — Pre-migration audit".
4. On the Settings page, paste Detect-MAAConnectivity.ps1 into Detection script file.
5. Leave the Remediation script file blank (this is an audit-only deployment).
6. Set Run this script using the logged-on credentials to No — it must run as SYSTEM to test the correct network context.
7. Set Enforce script signature check based on your environment's requirements.
8. Assign to your pilot Windows 11 device group first, then expand to all Windows 11 devices once you have confirmed the expected result.
9. Set the schedule to Daily and select Next › Create.

Any device where the detect script exits 1 cannot reach MAA endpoints from SYSTEM context. Those are your at-risk devices. The Proactive Remediation report in Intune gives you a count and a device list — export it and use it to target your network fix rollout.

Step 5 — Pilot compliance evaluation after the network fix

Once you have added the MAA endpoint rules to your firewall and SSL inspection bypass, verify the fix is working before the migration date by triggering a manual compliance evaluation on a pilot device:

# Trigger Intune device sync (forces compliance re-evaluation)
$session = New-CimSession
Invoke-CimMethod -Namespace "root\ccm" -ClassName "SMS_Client" -MethodName "TriggerSchedule" -Arguments @{sScheduleID="{00000000-0000-0000-0000-000000000121}"} -ErrorAction SilentlyContinue

# If ConfigMgr client not present, use Intune Management Extension sync:
Get-ScheduledTask -TaskName "Schedule #3" -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
  Start-ScheduledTask

# Or trigger via Company Portal: Settings -> Sync -> Sync now
# Wait 3-5 minutes, then check compliance in Intune admin center

Proof it worked: clean attestation and compliance confirmation

After applying the firewall rules and SSL inspection bypass, run the SYSTEM-context connectivity test again. Every MAA endpoint should now return TcpTestSucceeded: True:

Endpoint                          TcpTestSucceeded
--------                          ----------------
intunemaape1.attest.azure.net     True
intunemaape2.attest.azure.net     True
intunemaape3.attest.azure.net     True
intunemaape4.attest.azure.net     True
intunemaape5.attest.azure.net     True
intunemaape6.attest.azure.net     True
intunemaape7.attest.azure.net     True
intunemaape8.attest.azure.net     True
intunemaape9.attest.azure.net     True

# All 9 endpoints reachable from SYSTEM context.
# HealthAttestationClientAgent.exe will successfully reach MAA after migration.

After verifying connectivity, trigger a compliance re-evaluation on the pilot device. In the Intune admin center, navigate to the device and use Sync to force an immediate compliance check. Wait 5–10 minutes for the policy cycle to complete, then refresh the compliance detail page.

In the Intune admin center, navigate to the pilot device and confirm all three health-attested compliance settings return to "Compliant":

Once the pilot device is confirmed compliant, expand the Proactive Remediation to the full Windows 11 device population. Any device that was previously exit-1 (blocked) should move to exit-0 (reachable) as the network changes propagate. Monitor the Proactive Remediation report in Intune for 48 hours after the network changes are applied to confirm the fleet-wide result.

References

Microsoft official documentation for this migration and the required networking changes:

• Windows Message Center — Intune health attestation migration announcement (17 September 2026)
• Network endpoints for Microsoft Intune — includes MAA endpoint requirements
• Windows compliance policy settings in Intune — device health attestation settings reference
• What is Microsoft Azure Attestation? — MAA service overview
• Control the health of Windows devices — DHA architecture reference

Microsoft MVP community deep-dives