Compliance Intune Under Windows s 11: Certification Will Be Handled by Microsoft Azure Certification

On September 17, 2026, Microsoft announced in the Windows message center a change affecting the compliance of Windows 11 devices managed by Intune. The Windows Health Attestation assessment—which checks BitLocker, Secure Boot, and code integrity—will automatically transition from the Device Health Attestation (DHA) service to Microsoft Azure Attestation (MAA). Microsoft expects this change to take place in the first half of 2027 but has not provided a specific migration date.

The administrator's work focuses on the network. Devices running Windows , and 11 will communicate with Microsoft services Azure Certificates selected based on the tenant’s location Intune, rather than at the endpoint has.spserv.microsoft.com from the Device Health Attestation service. A firewall, a proxy , or SSL inspection that prevents them from connecting to these instances causes the affected devices to be marked as non-compliant. Where a conditional access policy requires a compliant device, these devices may then lose access to the organization’s resources.

Retrieved on September 29, 2026 from Microsoft documentation.

Windows 11 will be transferred to Microsoft Azure Attestation: Windows 10 remains on Device Health Attestation

Intune uses Microsoft attestation services to verify that a device has booted in a trusted state. The Network Endpoints page inIntune describes the new behavior: if a Device Health setting in the Windows compliance policy is enabled, Windows 11 devices use a Microsoft Azure Attestation service that depends on the tenant’s location Intune. This page describes the intended behavior without specifying a date; the announcement from September 17, 2026, provides the timeline.

Windows 10, and the GCC High and DoD environments continue to use the endpoint has.spserv.microsoft.com of the Device Health Attestation service, and Microsoft states that they are not affected by this change. Windows 10 reached its end of support on October 14, 2025, but it remains an authorized version in Intune : devices running this version can still enroll and use eligible features, though functionality is not guaranteed. A mixed fleet therefore maintains two attestation workflows—the old one for " Windows 10" and the new one for " Windows 11."

On the Windows side, the HealthAttestation CSP explains what happens on the device. Windows 11 adds nodes that allow the provider MDM to rely on the Microsoft Azure Attestation. Upon request from the MDM, the device gathers its attestation evidence (boot logs, TPM audit trails, and TPM certificate) and transmits it to the Microsoft Azure Attestation instance that the provider MDM has configured, and then receives a signed report that it stores in local cache. The provider’s attestation request MDM includes the full address of the instance to be used: this is howIntune can specify the instance specific to the tenant’s location.

The three Device Health settings in the compliance policy Windows

In a Windows compliance strategy, the “Device Health” section includes three settings under “ Windows Health Attestation Service evaluation rules”: “Require BitLocker,” “Require Secure Boot to be enabled on the device,” and “Require code integrity.” Each is set to “Not configured” by default and is therefore not evaluated. The endpoints page requires that the following be enabled to proceed to Microsoft Azure Attestation on the activation of at least one of these settings.

A related setting can be confusing. “Encryption of data storage on a device,” in the “System security” section, generically checks whether encryption is enabled on the system drive. The documentation explicitly distinguishes this from “Require BitLocker,” which relies on Device Health Attestation to validate the status of “ BitLocker ” at the TPM level.

There are already two causes of non-compliance related to these settings, independent of the network, and it’s worth ruling them out before looking at the firewall. The “ BitLocker ” status is measured only at startup: a device that has just completed encryption must restart to become compliant. And Microsoft notes that “Require Secure Boot to be enabled on the device” appears as “Not Compliant” on devices that do not support TPM 2.0 or later.

A blocked attestation endpoint causes the device to fail compliance with Windows s 11

The endpoints page is clear: if firewall rules prevent access to the new Microsoft service Azure Certification ofIntune, devices running Windows s 11 that have a compliance policy with any of the Device Health settings (BitLocker, Secure Boot, Code Integrity) will become non-compliant because they cannot reach the endpoints for their location.

This non-compliance status is tracked in Microsoft Entra ID. A conditional access policy with the access control setting “Require device to be marked as compliant” uses this to grant or block access to email and other organizational resources. The principle of conditional access, which relies on the compliance status indicated by Intune, is described in our article on the role of conditional access.

The time between a failure and a block depends on the actions taken in the event of noncompliance. Each compliance strategy includes the “Mark device as noncompliant” action, which is set to zero days by default: the device is marked as noncompliant as soon as the rule fails. Changing this timeframe creates a grace period during which the device is not yet marked as noncompliant.

Find the tenant's location Intune

The path is specified in Microsoft Intune admin center, under Tenant Administration > Tenant status, Tenant Details, in the Tenant "location." The value is formatted like "North America 0501," and it is the region—the first part of the value—that specifies which list to open. The endpoints page publishes three lists: North America, Europe, and Asia Pacific.

Access to Tenant the administration section, which includes Tenant status, requires the permissions Intune Organization.Read, ManagedDevice.Read, and ManagedApp.Read, which are granted by the built-in role Intune Read Only Operator.

The Six Microsoft Endpoints Azure Certification of a tenant located in Europe

For a tenant located in Europe, the page lists six addresses:

https://intunemaape7.neu.attest.azure.net https://intunemaape8.neu.attest.azure.net https://intunemaape9.neu.attest.azure.net https://intunemaape10.weu.attest.azure.net https://intunemaape11.weu.attest.azure.net https://intunemaape12.weu.attest.azure.net

The same six host names appear, without the prefix https://, in the consolidated list of FQDNs at the bottom of the page. Microsoft requires that no firewall rules block outbound HTTPS traffic on port 443 to these endpoints, and that no SSL inspection be applied to them.

If the fleet still includes Windows 10 devices with Device Health settings, has.spserv.microsoft.com must remain available to them.

SSL inspection is not supported on these endpoints

The Endpoints pageIntune indicates that SSL traffic inspection is not supported for .manage.microsoft.com, for .dm.microsoft.com nor for the attestation endpoints in the compliance section, which refers to the Microsoft Azure Attestation. The section on migration repeats this for addresses specific to the tenant’s location.

An SSL inspection exclusion has already been set for has.spserv.microsoft.com does not cover new hostnames: it must be extended to include the addresses in the list corresponding to the tenant's location—the six addresses listed above for a tenant located in Europe.

Test from the device, using the SYSTEM account

In the HealthAttestation CSP, the nodes added for Windows 11—such as TriggerAttestation and AttestStatus—are declared for the Device scope, not the User scope. For its own diagnostic tool, Test-IntuneAFDConnectivity.ps1, Microsoft distinguishes between running under the logged-in user and running under the Local System account—which it refers to as the “Device context”—and specifies this second context to test the device’s own connectivity. We therefore test under SYSTEM. Microsoft obtains this context using Sysinternals’ PsExec from a Command Prom PowerShell e opened as an administrator:

.\psexec.exe -accepteula -i -s powershell.exe

This Microsoft script checks the resolution DNS of the service's endpoints Intune, TCP connections on ports 80 and 443 to the IP addresses ofAzure Front Door, and HTTPS validation to the service Intune. For the tenant location certificate addresses, a direct check runs in the same SYSTEM window. The following script, which we wrote for Windows PowerShell 5.1 and which Microsoft does not provide, lists the six addresses for a tenant located in Europe; for another location, the list $hotes is replaced with the one from the corresponding tab on the endpoints page. It opens an HTTPS connection to each address using the proxy settings from the current context, then displays the response code and the issuer of the received certificate:

# Tenant situé en Europe : les six adresses de l'onglet Europe. # Autre emplacement : remplacer par la liste de l'onglet correspondant. $hotes = 'intunemaape7.neu.attest.azure.net','intunemaape8.neu.attest.azure.net', 'intunemaape9.neu.attest.azure.net','intunemaape10.weu.attest.azure.net', 'intunemaape11.weu.attest.azure.net','intunemaape12.weu.attest.azure.net' [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 foreach ($h in $hotes) { $req = [Net.WebRequest]::Create("https://$h/") $req.Timeout = 10000 try { $req.GetResponse().Close(); $etat = 'HTTP 200' } catch { $e = $_.Exception.InnerException; if (-not $e) { $e = $_.Exception } if ($e.Response) { $etat = "HTTP $([int]$e.Response.StatusCode)" } else { $etat = "$($e.Status) $($e.Message)" } } if ($req.ServicePoint.Certificate) { $emetteur = $req.ServicePoint.Certificate.Issuer } else { $emetteur = '(aucun certificat)' } '{0} | {1} | {2}' -f $h, $etat, $emetteur }

An HTTP code accompanied by a certificate issuer indicates that a TLS connection to a server was successful; since the script checks the root of each address—which is not theAPI certificate—a 404 error does not indicate a problem in this case. However, behind an explicit proxy , a 407 or a 403 error originates from proxy , which is rejecting the tunnel: the script then displays it as a standard HTTP code, and any certificate issuer shown on that line does not constitute proof of a connection to the endpoint. An error without an HTTP code (name resolution failure, timeout, connection refused, or trust relationship established) indicates that the connection failed. This leaves the sender on a line where the connection succeeded: if it is the certificate authority for your proxy or your firewall, the traffic is inspected, even if the connection succeeds.

AttestStatus, AttestErrorMessage, and GetServiceCorrelationIDs: The log of the most recent attestation

Three nodes in the HealthAttestation CSP provide information about the last session. AttestStatus stores the success or failure code for the last attestation session, which is cleared before each call to the service: 0 for success, otherwise an HRESULT code, for which Microsoft provides the following example: 0x80072efd, WININET_E_CANNOT_CONNECT. AttestErrorMessage stores the error message from the last session, when the attestation service returns one; it is available starting with Windows s 11 version 22H2 with KB5046732 and version 24H2 with KB5046617. Finally, `GetServiceCorrelationIDs` returns the service’s correlation IDs: a successful attestation involves two calls between the client and Microsoft Azure Attestation, and their two GUIDs are separated by a semicolon.

A boot code like the one in the example points to a network issue. It distinguishes a network problem from a non-compliant BitLocker , or Secure Boot—the two categories of causes described above.

Our Reading

We would treat this change as the launch of a network flow that needs to be prepared, rather than as a project focused on compliance strategies: the announcement describes an migration automated process, and what it requires us to review are the network, firewall, proxy , and endpoint access configurations. The risk stems from a network configuration set up to has.spserv.microsoft.com and that does not yet know the new hostnames, particularly an SSL inspection exclusion set on a per-host basis.

We would complete the rollout and testing well before 2027. The migration is automatic and scheduled over a period of time, without the administrator having to trigger it: we would prefer that the tenant’s location addresses be reachable, without inspection, before the first device is transferred to Microsoft Azure Certification, rather than discovering the issue through a wave of non-compliant devices.

We would finally test using actual devices, running SYSTEM, on each network profile in the fleet: internal network, VPN, and mobile devices if a proxy or filtering agent is applied to them. When conditional access requires a compliant device, user access depends on the outcome of this test.

What to Check

• The tenant's location, in Tenant Administration > Tenant status > Tenant Details, on the line Tenant location.
• Compliance strategies Windows that enable "Require BitLocker," "Require Secure Boot to be enabled on the device," or "Require code integrity," and the device groups Windows 11 to which they are assigned.
• Enable outbound HTTPS traffic on port 443 to the addresses in the list that corresponds to the tenant's location—that is, the six addresses listed on the Europe tab for a tenant located in Europe—on both the firewall and the proxy.
• The lack of SSL inspection at these same addresses, in addition to .manage.microsoft.com, .dm.microsoft.com and has.spserv.microsoft.com.
• has.spserv.microsoft.com, which must remain available as long as Windows 10 devices are being evaluated based on these criteria.
• The connection test from a device running Windows Windows 11, in a PowerShell window opened under SYSTEM, showing the response code and the certificate issuer for each address.
• Conditional access policies that require the device to be marked as compliant, and the time limit for the "Mark device as noncompliant" action in the relevant compliance policies.

Microsoft Sources

• Windows Message Center, entry dated September 17, 2026: Intune: Windows Health Attestation Migration to Microsoft Azure Attestation
• Network endpoints for Microsoft Intune
• Device compliance settings for Windows in Intune
• Health Certificate CSP
• Tenant status in Microsoft Intune
• Device compliance policies in Microsoft Intune
• Configure actions for noncompliant devices in Intune