Ein IT-Administrator betreibt eine Flotte von Windows-Geräten. BitLocker, Secure Boot und Code Integrity sind aktiv, Intune zeigt grün. Dann kommt ein Dienstag im Juli. Eine neue Build wird ausgerollt. Intune meldet für zahlreiche Geräte: „Noncompliant“. Drei rote Fehler, alle mit dem Code 2016345708. Was ist passiert? Die Geräte wurden nicht gehackt, sie haben keine Sicherheitslücke. Sie sind immer noch genauso geschützt wie vor dem Update. Aber Intune sieht das anders. Das liegt an einem unsichtbaren Mechanismus im Hintergrund: Wenn der Ausweis nicht mehr passt, kommt keiner rein.
Ein Beitrag auf PatchMyPC hat das Problem beschrieben. Auslöser war ein Reddit-Post, der vielen IT-Administratoren bekannt vorkam: BitLocker aktiviert, Secure Boot aktiviert, Code Integrity aktiviert – und trotzdem meldete Intune für alle drei Checks einen Fehler mit dem gleichen Code 2016345708. Das sah nach einem Problem mit den Geräteeinstellungen aus, war es aber nicht. Die Ursache lag eine Ebene tiefer, im Zusammenspiel zwischen Windows, dem Trusted Platform Module (TPM) und dem Microsoft Device Health Attestation Service.
Wenn Intune prüft, ob ein Gerät compliant ist, vertraut es nicht einfach auf eine lokale Ja/Nein-Antwort. Stattdessen fragt es den Health Attestation Service: der sammelt beim Hochfahren des Geräts gemessene Boot-Protokolle und TPM-Nachweise, schickt sie an Microsofts Cloud-Dienst und erhält ein signiertes Gesundheitszertifikat zurück. Dieses Zertifikat fungiert als „Reisepass“ des Geräts für Intune. Fehlt der Reisepass, weil die Ausstellung nicht geklappt hat, kann Intune nicht bestätigen, dass BitLocker eingeschaltet ist. Das Gerät erscheint noncompliant, obwohl lokal alles korrekt ist.
Bei den Juli-Builds war der Fehler genau dieser: Das Gesundheitszertifikat kam nie an. Der Tpm-HASCertRetr-Task blieb hängen – der Health-Attestation-Status verharrte auf 0xFFFF, dem Code für einen aus unbekanntem Grund fehlgeschlagenen Zertifikatsabruf. Weil dieser eine Nachweis fehlte, gingen auch alle abhängigen Compliance-Prüfungen (BitLocker, Secure Boot, Code Integrity) ins Leere. Das war kein Einzelfall. Bereits 2023 gab es ähnliche Berichte. Diesmal war die Ursache eine neue Windows-Funktion, die mit dem Juli-Update aktiviert wurde.
Die Analyse zeigte ein verstecktes Windows-Feature: die Funktions-ID 62861611, intern „PCPKspEKPubEnumeration“ genannt. Diese Funktion ändert, wie Windows die TPM-Identität vorbereitet, bevor der Attestierungsprozess beginnt. Normalerweise verwendet Windows einen etablierten RSA-basierten Pfad, um den Endorsement Key (EK) und den Attestation Identity Key (AIK) auszulesen. Mit Feature 62861611 erweitert Windows diesen Pfad: es sammelt zusätzliche öffentliche Schlüssel aus dem TPM – sowohl RSA als auch ECC – und bereitet einen neuen AIK-Typ (v2) vor. Das ist eine Modernisierung für mehr Krypto-Agilität und verschiedene Algorithmen.
Doch diese Erweiterung führte zu Kompatibilitätsproblemen. Bei physischen TPMs von Herstellern wie Nuvoton oder STMicroelectronics konnte Windows zwar die vorhandenen Zertifikate finden, aber die neu angelegten Identitäten ließen sich nicht vollständig mit dem Microsoft-AIK-Dienst abgleichen. Die Zertifikatskette wurde als ungültig zurückgewiesen. Bei virtuellen TPMs – etwa in Parallels Desktop – war das Problem noch schwerwiegender: Der neue Code erwartete bestimmte Schlüsselformate, die die virtuelle TPM-Umgebung nicht lieferte. Get-Tpm gab den Fehler „Structure is wrong size“ zurück, und Hello, BitLocker sowie alle Attestierungsfunktionen brachen zusammen.
Microsoft hat das Problem mit Advisory IT1431577 anerkannt. Die Ursache wurde als „Windows-Code-Regression“ beschrieben, die Device Health Attestation und die Intune-Compliance-Auswertung beeinträchtigt. Das Advisory geht nicht auf die Details des Features 62861611 ein, bestätigt aber: Es war kein Konfigurationsfehler in Intune, sondern ein Windows-Update, das die Attestierung während der Enrollment-Phase veränderte. Die offizielle Lösung war KB5101684, ein Preview-Update, das die Regression behob. Davor hatte Microsoft bereits serverseitige Anpassungen vorgenommen, um die Auswirkungen abzumildern.
Was bedeutet das konkret für Administratoren? Wenn nach einem Windows-Update plötzlich hunderte Geräte als noncompliant wegen BitLocker, Secure Boot und Code Integrity auftauchen, sollten sie nicht jede Einstellung einzeln debuggen. Der gemeinsame Nenner ist das Device Health Attestation-Zertifikat. Ein einfacher A/B-Test, den der PatchMyPC-Autor durchgeführt hat, zeigt, wie man das Problem isolieren kann: Deaktiviert man das Feature 62861611 mit einem Tool wie ViVeTool und startet neu, funktioniert die Attestierung wieder. Das belegt, dass die Ursache in der neuen TPM-Identitätslogik liegt und nicht im TPM selbst.
Für die Zukunft bleibt die Erkenntnis: Microsoft treibt die Krypto-Agilität von Windows voran, auch wenn das bei bestehenden Infrastrukturen zu kurzzeitigen Aussetzern führen kann. Die Einführung von AIK v2 und die breitere Nutzung von ECC-Schlüsseln erhöht die Sicherheit, erfordert aber, dass sowohl physische als auch virtuelle TPMs die neuen Anforderungen erfüllen. Die betroffene Feature-ID ist nur der Anfang. IT-Teams sollten ihre TPM-Umgebungen auf Kompatibilität prüfen, insbesondere bei Geräten mit unterschiedlichen TPM-Herstellern oder virtualisierten TPMs.
Diese Geschichte zeigt, wie tief die Abhängigkeiten in modernen Windows-Umgebungen reichen. Ein kleiner Schalter in der Windows-Binary kann Compliance-Ergebnisse auf der ganzen Flotte kippen lassen, ohne dass sich an den Sicherheitseinstellungen selbst etwas ändert. Die Lösung kommt in Form eines kumulativen Updates, aber das Verständnis der Ursache hilft, ähnliche Störungen schneller zu erkennen. Der schlimmste Fehler wäre, jetzt an den BitLocker-Richtlinien zu drehen – das würde das Problem nur verschleiern, nicht beheben.
Quelle: patchmypc.com
