Konformität Intune Windows s 11: Die Zertifizierung wird künftig von Microsoft übernommen Azure Bescheinigung

Am 17. September 2026 kündigte Microsoft im Windows Message Center eine Änderung an, die die Konformität von Geräten betrifft, die von Windows 11 verwaltet werden Intune. Die „ Windows Health Attestation“-Prüfung, die „ BitLocker “, „Secure Boot“ und die Codeintegrität überprüft, wird automatisch vom „Device Health Attestation“ (DHA)-Dienst auf die „Microsoft Azure Attestation (MAA) um. Microsoft plant diese Änderung für das erste Halbjahr 2027 und gibt kein konkretes Datum für die Umstellung an.

Die Arbeit des Administrators konzentriert sich auf das Netzwerk. Die Geräte „ Windows 11“ werden sich an Microsoft-Instanzen wenden Azure Zertifikate, die je nach Standort des Tenants ausgewählt werden Intune, und nicht mehr am Endpunkt has.spserv.microsoft.com des Dienstes „Device Health Attestation“. Eine Firewall, ein „ proxy “ oder eine SSL-Prüfung, die den Zugriff auf diese Instanzen verhindert, führt dazu, dass die betroffenen Geräte als nicht konform eingestuft werden. Wenn eine Richtlinie für den bedingten Zugriff ein konformes Gerät vorschreibt, können diese Geräte daraufhin den Zugriff auf die Ressourcen des Unternehmens verlieren.

Abgerufen am 29. September 2026 aus der Microsoft-Dokumentation.

Windows 11 wird zu Microsoft wechseln Azure Zertifizierung: „ Windows “ 10 bleibt bei „Device Health Attestation“

Intune nutzt die Zertifizierungsdienste von Microsoft, um zu überprüfen, ob ein Gerät in einem vertrauenswürdigen Zustand gestartet ist. Die Seite „Netzwerkendpunkte“ vonIntune beschreibt das neue Verhalten: Wenn eine „Device Health“-Einstellung in der Compliance-Richtlinie „ Windows “ aktiviert ist, nutzen Geräte mit „ Windows “ 11 einen Microsoft-Authentifizierungsdienst Azure Attestation, der vom Standort des Mandanten abhängt Intune. Diese Seite beschreibt die angestrebte Funktionsweise ohne Angabe eines Datums; der Zeitplan geht aus der Ankündigung vom 17. September 2026 hervor.

Windows 10 und die Umgebungen „GCC High“ und „DoD“ verwenden weiterhin den Endpunkt has.spserv.microsoft.com des Dienstes „Device Health Attestation“, und Microsoft gibt an, dass diese von dieser Änderung nicht betroffen sind. Der Support für „ Windows “ 10 endet am 14. Oktober 2025, doch es bleibt weiterhin eine zulässige Version im Intune : Die Geräte können sich weiterhin registrieren und die berechtigten Funktionen nutzen, allerdings ohne Funktionsgarantie. Ein gemischter Gerätepark verfügt daher über zwei Zertifizierungsabläufe: den alten für „ Windows 10“ und den neuen für „ Windows 11“.

Was „ Windows “ betrifft, so erklärt die HealthAttestation CSP , was auf dem Gerät geschieht. Windows 11 fügt Knoten hinzu, die es dem Anbieter ermöglichen, MDM , sich auf die Microsoft-Bescheinigung Azure Attestation zu nutzen. Auf Anfrage des MDM sammelt das Gerät seine Bescheinigungsnachweise (Startprotokolle, TPM-Audit-Protokolle und TPM-Zertifikat) und übermittelt sie an die Microsoft-Instanz Azure Attestation, die der Anbieter MDM konfiguriert hat, und erhält anschließend einen signierten Bericht, den er im lokalen Cache speichert. Die Zertifizierungsanfrage des Anbieters MDM enthält die vollständige Adresse der zu verwendenden Instanz: Auf diese WeiseIntune die für den Standort des Mandanten zuständige Instanz angegeben werden kann.

Die drei „Device Health“-Parameter der Compliance-Richtlinie Windows

In einer Compliance-Strategie Windows umfasst der Abschnitt „Device Health“ unter „ Windows Health Attestation Service evaluation rules“ drei Einstellungen: „Require BitLocker “, „Require Secure Boot to be enabled on the device“ und „Require code integrity“. Jede dieser Einstellungen ist standardmäßig auf „Not configured“ gesetzt und wird daher nicht bewertet. Auf der Seite mit den Endpunkten hängt die Umstellung auf Microsoft Azure Attestation von der Aktivierung mindestens einer dieser Einstellungen abhängig.

Eine ähnliche Einstellung sorgt für Verwirrung. Die Option „Encryption of data storage on a device“ im Abschnitt „System security“ überprüft allgemein, ob auf dem Systemlaufwerk eine Verschlüsselung vorhanden ist. In der Dokumentation wird diese Option ausdrücklich von „Require BitLocker “ unterschieden, die sich auf „Device Health Attestation“ stützt, um den Status von „ BitLocker “ auf TPM-Ebene zu überprüfen.

Es gibt bereits zwei Ursachen für die Nichteinhaltung dieser Parameter, die unabhängig vom Netzwerk sind, und es lohnt sich, diese auszuschließen, bevor man bei der Firewall nachforscht. Der Status „ BitLocker “ wird nur beim Systemstart gemessen: Ein Gerät, dessen Verschlüsselung gerade abgeschlossen wurde, muss neu gestartet werden, um die Konformität zu erreichen. Und Microsoft weist darauf hin, dass „Require Secure Boot to be enabled on the device“ auf Geräten, die TPM 2.0 oder eine neuere Version nicht unterstützen, als „Not Compliant“ angezeigt wird.

Ein gesperrter Zertifizierungsendpunkt führt dazu, dass das Gerät „ Windows . 11“ nicht konform ist

Auf der Seite zu den Endpunkten wird deutlich: Wenn Firewall-Regeln den Zugriff auf den neuen Microsoft-Dienst verhindern Azure Bestätigung vonIntune: Geräte mit „ Windows s 11“, für die eine Compliance-Richtlinie mit einer der „Device Health“-Einstellungen (BitLocker, Secure Boot, Code Integrity) gilt, gelten als nicht konform, da sie die Endpunkte ihres Standorts nicht erreichen können.

Dieser Status der Nichtkonformität geht auf Microsoft zurück Entra ID. Eine Strategie für den bedingten Zugriff, deren Zugriffskontrolle auf „Gerät muss als konform markiert sein“ eingestellt ist, nutzt diesen Status, um den Zugriff auf E-Mails und andere Ressourcen der Organisation zu gewähren oder zu sperren. Das Prinzip des bedingten Zugriffs, das auf dem Konformitätsstatus basiert, der Intune, wird in unserem Artikel über die Rolle des bedingten Zugriffs beschrieben.

Die Zeitspanne zwischen dem Versagen der Regel und der Sperrung hängt von den Maßnahmen bei Nichteinhaltung ab. Jede Compliance-Strategie enthält die Aktion „Gerät als nicht konform kennzeichnen“, die standardmäßig auf null Tage eingestellt ist: Das Gerät wird als nicht konform gekennzeichnet, sobald die Regel nicht erfüllt wird. Durch Ändern dieser Zeitspanne wird eine Schonfrist geschaffen, während der das Gerät noch nicht als nicht konform gekennzeichnet wird.

Den Standort des Tenants ermitteln Intune

Der Speicherort ist in der Microsoft-Datei Intune admin center, unter Tenant Verwaltung > Tenant Status, Registerkarte Tenant „Details“, in der Zeile Tenant „Standort“. Der Wert hat ein Format wie „North America 0501“, wobei die Region – also der erste Teil des Werts – angibt, welche Liste geöffnet werden soll. Auf der Endpunktseite werden drei Listen veröffentlicht: Nordamerika, Europa und Asien-Pazifik.

Der Zugang zur Tenant Verwaltung, zu der auch Tenant „status“, erfordert die Berechtigungen Intune „Organization.Read“, „ManagedDevice.Read“ und „ManagedApp.Read“, über die die integrierte Rolle Intune „Read Only Operator“ verfügt.

Die sechs Microsoft-Endpunkte Azure Bestätigung eines in Europa ansässigen Mandanten

Für einen Aussteller mit Standort in Europa werden auf der Seite sechs Adressen aufgeführt:

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

Es erscheinen dieselben sechs Hostnamen, jedoch ohne das Präfix https://, in der konsolidierten Liste der FQDNs am Ende der Seite. Microsoft verlangt, dass keine Firewall-Regel den ausgehenden HTTPS-Datenverkehr über Port 443 zu diesen Endpunkten blockiert und dass dort keine SSL-Prüfung durchgeführt wird.

Falls sich im Bestand noch Geräte vom Typ „ Windows 10“ mit „Device Health“-Einstellungen befinden, has.spserv.microsoft.com muss für sie erreichbar bleiben.

Die SSL-Prüfung wird an diesen Endpunkten nicht unterstützt

Auf der Seite „Endpunkte“ vonIntune gibt an, dass die SSL-Verkehrsüberprüfung für .manage.microsoft.com, für .dm.microsoft.com noch für die Endpunkte der Bescheinigung im Abschnitt „Konformität“, der auf die Microsoft-Liste Azure Zertifizierung. Der Abschnitt „ migration “ wiederholt dies für die standortspezifischen Adressen des Tenants.

Eine SSL-Prüfungsausnahme wurde bereits festgelegt für has.spserv.microsoft.com umfasst keine neuen Hostnamen: Sie muss auf die Adressen der Liste erweitert werden, die dem Standort des Mandanten entspricht – im Falle eines Mandanten in Europa sind dies die sechs oben genannten Adressen.

Auf dem Gerät unter dem SYSTEM-Konto testen

Im HealthAttestation- CSP werden die für „ Windows “ 11 hinzugefügten Knoten, wie „TriggerAttestation“ und „AttestStatus“, für den Bereich „Device“ und nicht für „User“ deklariert. Für sein eigenes Diagnosetool, Test-IntuneAFDConnectivity.ps1, unterscheidet Microsoft übrigens zwischen der Ausführung unter dem angemeldeten Benutzer und der Ausführung unter dem Local-System-Konto, das als „Device Context“ bezeichnet wird, und gibt diesen zweiten Kontext an, um die Konnektivität des Geräts selbst zu testen. Wir testen daher unter SYSTEM. Microsoft ruft diesen Kontext mit PsExec von Sysinternals ab, und zwar über eine als Administrator geöffnete Eingabeaufforderung „ PowerShell “:

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

Dieses Skript von Microsoft überprüft die Auflösung DNS der Endpunkte des Dienstes Intune, die TCP-Verbindungen auf den Ports 80 und 443 zu den IP-Adressen vonAzure Front Door sowie die HTTPS-Validierung zum Dienst Intune. Für die Zertifikatsadressen des Tenant-Standorts wird im selben SYSTEM-Fenster eine direkte Überprüfung gestartet. Das folgende Skript, das wir für Windows PowerShell 5.1 geschrieben haben und das von Microsoft nicht bereitgestellt wird, enthält die sechs Adressen eines in Europa ansässigen Tenants; für einen anderen Standort lautet die Liste $hotes wird durch die des entsprechenden Reiters auf der Endpunktseite ersetzt. Es öffnet eine HTTPS-Verbindung zu jeder Adresse mit den Einstellungen unter „ proxy “ des aktuellen Kontexts und zeigt anschließend den Antwortcode sowie den Aussteller des empfangenen Zertifikats an:

# 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 }

Ein HTTP-Code in Verbindung mit einem Zertifikatsaussteller zeigt an, dass eine TLS-Verbindung zu einem Server erfolgreich hergestellt wurde; da das Skript die Stammzertifikate jeder Adresse abfragt – die nicht das Zertifikat „API “ sind –, deutet ein 404-Fehler in diesem Fall nicht auf ein Problem hin. Hinter einem expliziten „ proxy “, einem 407 oder einem 403 steht hingegen der proxy , der den Tunnel ablehnt: Das Skript zeigt dies dann als gewöhnlichen HTTP-Code an, und der gegebenenfalls in dieser Zeile angezeigte Zertifikatsaussteller gilt nicht als Nachweis für eine Verbindung zum Endpunkt. Ein Fehler ohne HTTP-Code (Namensauflösung, Zeitüberschreitung, abgelehnte Verbindung oder keine Vertrauensbeziehung möglich) zeigt an, dass die Verbindung nicht zustande kommt. Bleibt noch der Absender in einer Zeile, in der die Verbindung erfolgreich war: Handelt es sich um die Zertifizierungsstelle Ihrer proxy oder Ihrer Firewall, wird der Datenverkehr überprüft, selbst wenn die Verbindung erfolgreich ist.

AttestStatus, AttestErrorMessage und GetServiceCorrelationIDs: Der Verlauf der letzten Bescheinigung

Drei Knoten des HealthAttestation- CSP s liefern Informationen zur letzten Sitzung. AttestStatus speichert den Erfolg- oder Fehlercode der letzten Zertifizierungssitzung, der vor jedem Aufruf des Dienstes gelöscht wird: 0 bei Erfolg, andernfalls ein HRESULT-Code, für den Microsoft folgendes Beispiel angibt: 0x80072efd, WININET_E_CANNOT_CONNECT. „AttestErrorMessage“ speichert die Fehlermeldung der letzten Sitzung, sofern der Zertifizierungsdienst eine solche zurückgibt; diese Funktion ist ab „ Windows “ 11, Version 22H2 mit KB5046732 und Version 24H2 mit KB5046617 verfügbar. GetServiceCorrelationIDs schließlich gibt die Korrelations-IDs des Dienstes zurück: Bei einer erfolgreichen Attestierung erfolgen zwei Aufrufe zwischen dem Client und Microsoft Azure Authentifizierung, und deren beiden GUIDs sind durch ein Semikolon getrennt.

Ein Verbindungscode wie der im Beispiel verweist auf das Netzwerk. Er unterscheidet zwischen einem Netzwerkproblem und einem nicht konformen „ BitLocker “ oder „Secure Boot“ – den beiden oben beschriebenen Ursachengruppen.

Unsere Lektüre

Wir würden diese Änderung eher als die Vorbereitung einer neuen Netzwerkverbindung betrachten und nicht als eine Maßnahme im Bereich der Compliance-Strategien: In der Ankündigung wird eine automatische „ migration “ beschrieben, und was dabei überprüft werden muss, sind die Konfigurationen des Netzwerks, der Firewall, des „ proxy “ und des Zugriffs auf die Endpunkte. Das Risiko besteht in einer Netzwerkkonfiguration, die so eingestellt ist, dass has.spserv.microsoft.com und die die neuen Hostnamen noch nicht kennt, insbesondere eine SSL-Prüfungsausnahme, die für jeden Hostnamen einzeln festgelegt wurde.

Wir würden die Eröffnung und den Test bereits weit vor 2027 durchführen. Die „ migration “ erfolgt automatisch und wird über einen bestimmten Zeitraum angekündigt, ohne dass der Administrator sie auslöst: Wir würden es vorziehen, wenn die Adressen des Tenant-Standorts ohne Überprüfung erreichbar wären, bevor das erste Gerät zu Microsoft wechselt Azure Bestätigung, anstatt das Problem erst durch eine Flut nicht konformer Geräte zu entdecken.

Schließlich würden wir die Tests auf echten Geräten unter SYSTEM für jedes Netzwerkprofil des Gerätebestands durchführen: internes Netzwerk, VPN sowie mobile Endgeräte, sofern dort ein proxy oder ein Filteragent zum Einsatz kommt. Wenn die bedingte Zugriffsberechtigung ein konformes Gerät erfordert, hängt der Zugriff der Benutzer von diesem Test ab.

Was zu überprüfen ist

• Der Speicherort des Tenants unter Tenant Verwaltung > Tenant Status > Tenant Details, in der Zeile Tenant Standort.
• Die Compliance-Strategien „ Windows “, die die Optionen „ BitLocker “ aktivieren, „Secure Boot muss auf dem Gerät aktiviert sein“ oder „Codeintegrität erforderlich“ aktivieren, sowie die Gerätegruppen „ Windows 11“, denen sie zugewiesen sind.
• Die Freigabe des ausgehenden HTTPS-Verkehrs auf Port 443 zu den Adressen aus der Liste, die dem Standort des Tenants entspricht – d. h. den sechs Adressen auf der Registerkarte „Europa“ für einen in Europa ansässigen Tenant –, sowohl auf der Firewall als auch auf dem proxy.
• Das Fehlen einer SSL-Prüfung bei eben diesen Adressen, zusätzlich zu .manage.microsoft.com, .dm.microsoft.com und has.spserv.microsoft.com.
• has.spserv.microsoft.com, der erreichbar bleiben muss, solange Geräte mit „ Windows s 10“ hinsichtlich dieser Parameter getestet werden.
• Der Verbindungstest von einem Gerät mit „ Windows “ 11 aus, in einem unter „SYSTEM“ geöffneten „ PowerShell “-Fenster, mit dem Antwortcode und dem Zertifikatsaussteller für jede Adresse.
• Zugriffskontrollstrategien, die die Einstellung „Gerät muss als konform markiert sein“ erfordern, sowie die Zeitfrist für die Aktion „Gerät als nicht konform markieren“ in den entsprechenden Konformitätsrichtlinien.

Quellen von Microsoft

• Windows Nachrichtencenter, Eintrag vom 17. September 2026: Intune: Windows Gesundheitsbescheinigung Migration an Microsoft Azure Bescheinigung
• Netzwerkendpunkte für Microsoft Intune
• Gerätekonformitätseinstellungen für „ Windows “ in Intune
• Gesundheitsbescheinigung CSP
• Tenant Status in Microsoft Intune
• Richtlinien zur Gerätekonformität bei Microsoft Intune
• Konfigurieren Sie Maßnahmen für nicht konforme Geräte in Intune