Microsoft Cloud PKI
Zertifikate aus der Cloud – was Microsoft Cloud PKI in der Praxis leistet und wo die Grenzen liegenMicrosoft Cloud PKI in der Praxis — was es wirklich kann
Was im Lieferumfang ist, was nicht — und warum die Lizenzänderung im Oktober 2026 die Lage komplett neu sortiert
Kurzfassung vorab
Microsoft Cloud PKI ist eine cloud-gehostete CA, die exklusiv für Intune-verwaltete Geräte arbeitet. Sie ersetzt NDES und Intune Certificate Connector und macht Computer-, Wi-Fi- und VPN-Zertifikate für Windows, iOS, macOS und Android elegant. Sie ist keine vollständige ADCS-Ablöse. Server-TLS, ACME, klassisches Smartcard-Logon mit PIV-Karte am Domain-Controller, S/MIME für Outlook-User — alles weiterhin nicht im Lieferumfang.
Spannend wird die Lage durch eine Lizenzänderung, die seit Dezember 2025 angekündigt ist: Ab Oktober 2026 wird Cloud PKI in Microsoft 365 E5 inkludiert. Wer heute eine PKI-Strategie aufsetzt, sollte das einrechnen — die Wirtschaftlichkeitsrechnung verschiebt sich für viele Unternehmen kräftig.
Abb. 1: Was im Lieferumfang von Microsoft Cloud PKI steckt — und wofür es weiterhin ADCS oder eine andere Lösung braucht.
1. Was Microsoft Cloud PKI ist — und was es nicht ist
Microsoft Cloud PKI ist eine Komponente der Intune Suite. Sie wurde im Februar 2024 als Bestandteil dieses Add-ons allgemein verfügbar gemacht und richtet sich an Unternehmen, die Zertifikate für Intune-verwaltete Endgeräte ausstellen wollen, ohne dafür eine eigene PKI-Infrastruktur on-prem zu betreiben. Microsoft selbst formuliert das in der Dokumentation glasklar: "Microsoft Cloud PKI only issues certificates to network devices that are MDM-enrolled."
Das ist die wichtigste Information aus zwei Sätzen Marketing. Wer das überliest, sitzt drei Monate später beim Geschäftsführer und erklärt, warum die Linux-VMs jetzt doch keine Zertifikate aus der "neuen Cloud-PKI" bekommen können. Cloud PKI ist nicht der Hyperscaler-CA-Service wie AWS Private CA oder GCP Certificate Authority Service. Sie ist deutlich enger zugeschnitten, dafür aber sehr gut integriert in den Intune-Workflow.
|
Info · Verweis · Was Microsoft mit "MDM-enrolled" wirklich meint Das Gerät muss in Intune enrolliert sein und ein SCEP-Zertifikatsprofil von Intune zugewiesen bekommen können. Apple-Geräte werden seit Januar 2026 für das Enrollment-Profil selbst per ACME ausgestattet — das ist aber ein interner Apple-Intune-Mechanismus und hat nichts mit ACME-Support für deine Workloads zu tun. Für alles, was nicht in Intune steckt, bleibt die SCEP-Tür der Cloud PKI verschlossen. |
|---|
Lizenzseitig braucht es eine Intune-Plan-1-Subscription plus entweder die Intune-Suite-Lizenz oder das eigenständige Cloud-PKI-Add-on. Beides liegt heute noch im niedrigen zweistelligen US-Dollar-Bereich pro Nutzer und Monat. Die wichtigste Neuigkeit für die Strategie: Microsoft hat angekündigt, Cloud PKI ab Oktober 2026 als Bestandteil von Microsoft 365 E5 ohne Aufpreis mitzuliefern. Für E5-Kunden entfällt damit die separate Add-on-Lizenzierung. Dazu kommen wir später noch ausführlich.
2. Wie Cloud PKI funktioniert — Architektur und Komponenten
Die Architektur ist bewusst minimalistisch gehalten. Im Intune Admin Center legst du eine Root CA an (oder bringst eine eigene mit, dazu gleich mehr) und darunter eine oder mehrere Issuing CAs. Jede Cloud-Issuing-CA bekommt automatisch eine SCEP-URI als Registrierungsstelle und eine CRL-Distribution-URI. Beide werden ebenfalls von Microsoft gehostet und sind aus dem Internet erreichbar.
Damit ist die Cloud-PKI-Seite fertig. Auf der Geräteseite konfigurierst du in Intune drei Profile: ein Trusted-Certificate-Profil mit dem Root-Public-Key (damit das Gerät der Root vertraut), ein zweites Trusted-Certificate-Profil mit dem Issuing-CA-Public-Key, und ein SCEP-Profil, das das Gerät anweist, an der SCEP-URI ein Zertifikat anzufordern. Die SCEP-Challenge wird dabei vom Intune-Service signiert, sodass die Cloud-PKI-RA prüfen kann, dass das anfragende Gerät tatsächlich aus deinem Intune-Tenant kommt.
Abb. 2: SCEP-Enrollment vom Intune-Gerät bis zum signierten Zertifikat — acht Schritte, alles automatisiert.
Was technisch elegant ist: der Intune-Service signiert die Challenge mit eigenen Schlüsseln. Die Cloud PKI muss also kein klassisches SCEP-Geheimnis verteilen oder verwalten, wie es bei NDES nötig wäre. Genau diese Schwachstelle vergangener SCEP-Implementierungen ist mit dem Cloud-PKI-Ansatz weg. Wer NDES jemals produktiv betreut hat, weiß, was das wert ist.
3. Was Cloud PKI heute kann
Die folgende Liste deckt die produktiv verfügbaren Funktionen ab — Stand Mai 2026. Microsoft erweitert das Produkt schrittweise, gleichzeitig sind manche Erweiterungen seit Monaten in der Roadmap, aber noch nicht ausgeliefert.
Bemerkenswert auch, was technisch sauber gelöst ist: jede Issuing CA bekommt ihren eigenen Schlüssel im Microsoft-HSM, die Trennung der CA-Instanzen ist tenant-spezifisch, und es gibt eine vernünftige RBAC-Struktur für Lese-, Erstellungs- und Revocation-Rechte. Das hat das alte Microsoft-On-Prem-CA-Modell so nie geliefert.
4. Was Cloud PKI heute nicht kann
Hier wird es interessant. Wer den Marketing-Pitch hört, vermutet Cloud PKI auf Augenhöhe mit AWS Private CA oder GCP Certificate Authority Service. Das stimmt nicht. Microsoft hat den Funktionsumfang bewusst eng gezogen — und einige der fehlenden Disziplinen sind kein Versehen, sondern Architektur.
Kein nativer ACME-Support für Workloads
Stand Mai 2026 spricht Cloud PKI kein ACME. Linux-Webserver, Container-Workloads, Network Appliances und alles andere, was ACME als Standardprotokoll erwartet, kann mit der Cloud PKI nicht direkt reden. Wer ACME braucht, landet entweder bei einer ACME-Bridge vor einer separaten CA (siehe Spoke 6.5) oder bei einer parallelen ACME-fähigen Cloud-PKI wie Smallstep oder AWS Private CA. Dass Apple seit Januar 2026 sein Enrollment-Profil per ACME bezieht, ist eine Microsoft-Apple-Mechanik im Intune-Service und liefert keinen ACME-Endpoint für deine eigenen Workloads.
Kein OCSP — nur CRL
Revocation läuft ausschließlich über CRL-Distribution. Wer auf OCSP-Stapling oder OCSP-Responder-Hochverfügbarkeit angewiesen ist, muss anderswo schauen. Für die meisten Intune-Szenarien ist das in Ordnung, weil die Clients ohnehin nur sporadisch CRLs abrufen — bei größeren Setups mit vielen Zertifikaten kann die CRL-Größe aber irgendwann ein Thema werden.
Keine TLS-Zertifikate für Server
Auch das steht in der Microsoft-Doku im Klartext: "Microsoft Cloud PKI doesn’t provide these TLS/SSL certificates." Wenn deine Intune-Geräte einen Wi-Fi-Accesspoint oder einen VPN-Server brauchen, der sich gegen sie ausweist — das TLS-Zertifikat dieses Servers muss aus einer anderen PKI kommen, etwa aus deiner ADCS. Cloud PKI ist End-Entity-only und nicht für Server-Authentifizierung gedacht.
Kein klassisches Smartcard-Logon mit PIV-Karte
Die klassische On-Prem-Anmeldung mit Smartcard am Domain-Controller braucht eine CA, die im AD veröffentlicht ist und der die DCs vertrauen. Cloud PKI kann zwar Zertifikate für Windows Hello for Business und Entra-CBA ausstellen, das traditionelle Kerberos-PKINIT-Smartcard-Logon ist damit aber nicht abgedeckt. Wer eine PIV-Karten-Flotte für AD-Anmeldung im Einsatz hat, behält für diese Strecke seine ADCS.
Keine S/MIME-Disziplin
Auto-Enrollment von S/MIME-Zertifikaten für Outlook-User über GPO — das klassische ADCS-Szenario im Mittelstand — ist kein Cloud-PKI-Anwendungsfall. Microsoft empfiehlt für S/MIME nach wie vor entweder ADCS oder spezialisierte externe Anbieter wie GlobalSign oder Sectigo. Für interne User-S/MIME-Verschlüsselung bleibt ADCS in deinem Stack.
Keine SCEP-Integration für nicht-Intune-Geräte
Das ist eine harte Grenze. Wenn du Macs mit Jamf statt mit Intune managst, wenn du Chromebooks mit Google Workspace betreibst oder wenn du Network Appliances per SCEP versorgen willst — Cloud PKI hilft dir nicht. Die SCEP-RA prüft die Intune-Service-Signatur in der Challenge. Ohne Intune kommt das Gerät nicht durch.
|
Warnung · Klassische Falle · Migration heißt: alles neu ausstellen Wer heute mit der Microsoft-Root-Variante startet (also keine BYOCA wählt) und in zwei Jahren feststellt, dass Cloud PKI nicht mehr passt, hat ein hartes Migrationsproblem. Die Cloud-Root liegt vollständig bei Microsoft. Es gibt keinen Pfad, die Root mitzunehmen — jede Migration heißt: alle Zertifikate aus der neuen PKI ausstellen, Trust-Stores ergänzen, Auslauf der alten Zertifikate abwarten oder forcieren. Bei zehntausenden Endgeräten ist das ein Projekt von Quartalen, nicht von Wochen. |
|---|
5. Die beiden Deployment-Modelle
Microsoft bietet beim Aufbau einer Cloud-PKI-Hierarchie zwei Modelle an. Welches du nimmst, hängt davon ab, ob du eine bestehende PKI hast und wie wichtig dir Vertrauenshoheit auf der Root-Ebene ist.
Abb. 3: Variante A (Microsoft Root) gegenüber Variante B (BYOCA mit eigener ADCS-Root) — der entscheidende Unterschied liegt darin, wo die Vertrauenswurzel sitzt.
Variante A — Microsoft Root CA (Greenfield)
Du legst Root und Issuing CA komplett in der Microsoft Cloud an. Vier Klicks im Intune Admin Center, Zertifikate können nach wenigen Minuten ausgestellt werden. Für reine Cloud-First-Umgebungen ohne historische PKI ist das der pragmatische Weg. Der Preis dafür: die Root-Schlüssel sind nicht bei dir. Bei einem Anbieterwechsel musst du dich an die zuvor genannten Migrationskosten gewöhnen.
Variante B — Bring Your Own CA (BYOCA)
Du behältst deine bestehende ADCS-Root on-prem, signierst damit ein Issuing-CA-Zertifikat für die Cloud-Issuing-CA, und lädst dieses signierte Sub-CA-Zertifikat in Microsoft Cloud PKI hoch. Damit hängt die Cloud-PKI-Chain technisch unter deiner eigenen Root. Endgeräte, die deiner Root sowieso vertrauen, vertrauen automatisch auch der Cloud-Issuing-CA. Audit-seitig schließt die Vertrauenskette nach oben sauber: Root und HSM bleiben in deiner Kontrolle, nur die Issuing-Ebene wird zu Microsoft ausgelagert.
Für die meisten Unternehmen mit bestehender ADCS ist BYOCA die deutlich bessere Wahl. Der initiale Aufwand für die Root-Schlüssel-Zeremonie zum Signieren der Cloud-Sub-CA ist überschaubar (ein halber Tag, sauber dokumentiert), die langfristige Hoheit über die Vertrauenswurzel ist es wert. Plus: wenn Cloud PKI dir später nicht mehr gefällt, kannst du die Cloud-Issuing-CA abklemmen und eine neue On-Prem-Issuing-CA unter derselben Root einhängen — die ausgestellten Endgeräte-Zertifikate bleiben gültig bis zum Ablauf.
|
Praxis-Tipp · Aus dem Beratungsalltag · BYOCA setzt eine gepflegte ADCS-Root voraus Wer BYOCA wählt, signiert mit seinem produktiv genutzten Root-Schlüssel ein Sub-CA-Zertifikat für Microsoft. Das ist ein ernstzunehmender Vorgang — Root-Schlüssel-Operationen gehören gehärtet, dokumentiert und bei mehrstufigen Hierarchien in eine richtige Zeremonie eingebettet. Wenn deine Root-CA bisher als Software-CSP auf einem VM-Host läuft, ist das jetzt der Moment, das HSM-Thema zu klären. BYOCA ohne HSM ist möglich, aber von Auditor-Seite eine Diskussion. |
|---|
6. Was Oktober 2026 ändert — Lizenzierung als Game-Changer
Im Dezember 2025 hat Microsoft angekündigt, eine Reihe von Intune-Suite-Funktionen ab dem Geschäftsjahr 2027 in Microsoft 365 E5 zu integrieren. Cloud PKI gehört dazu. Die Pricing-Änderung greift offiziell im Juli 2026, die Funktionsverfügbarkeit für E5-Kunden rollt schrittweise ab Oktober 2026 aus. Das ist die wahrscheinlich wichtigste strategische Nachricht zu Cloud PKI seit der GA im Februar 2024.
Abb. 4: Zeitachse der Cloud-PKI-Verfügbarkeit — der Oktober 2026 ist der Wendepunkt, an dem die Verbreitung in M365-E5-Kunden sprunghaft steigen wird.
Was sich dadurch verändert: Unternehmen, die bereits M365 E5 lizenziert haben (in Deutschland ist das vor allem das obere Mittelstandssegment und größere Konzerne), bekommen Cloud PKI ohne zusätzliche Kosten. Damit kippt die Wirtschaftlichkeitsrechnung für Intune-Geräte-Zertifikate. Wer heute noch NDES on-prem betreibt, um Computer-Zertifikate an Intune-Geräte auszuliefern, hat ab Oktober 2026 keinen vernünftigen ökonomischen Grund mehr dafür — die Cloud-Lösung kommt sowieso ohne Aufpreis ins Lizenzpaket.
Für die Pillar-Strategie heißt das: Wer in 2026 ohnehin eine Modernisierung der PKI angeht (Stichworte NIS2, 47-Tage-TLS, Post-Quantum-Vorbereitung), sollte den Oktober-2026-Termin als Planungsanker setzen. Statt heute eine Bridge-Konstruktion zu bauen, kann es sich lohnen, ein bestimmtes Workload-Segment auf Cloud PKI vorzubereiten und die Umstellung dann zum Lizenzwirksamkeitsdatum zu fahren.
Wichtige Einschränkung: Für M365 E3 und alle Lizenzen unterhalb von E5 bleibt Cloud PKI weiterhin ein separates Add-on. Wer also mit E3 unterwegs ist (klassischer Mittelstandsfall), muss bei seiner Lizenz-Rechnung den Cloud-PKI-Posten weiterhin extra einplanen.
|
PowerShell — Cloud-PKI-Zertifikate per Microsoft Graph inventarisieren # Voraussetzung: Microsoft.Graph.Authentication und # Microsoft.Graph.Beta.DeviceManagement installiert # Berechtigung: DeviceManagementConfiguration.Read.All
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
# Alle Cloud-PKI-Certification-Authorities auflisten $cas = Get-MgBetaDeviceManagementCertificateAuthority
foreach ($ca in $cas) { Write-Host "" Write-Host "CA: $($ca.DisplayName) [$($ca.CertificationAuthorityType)]" Write-Host " Subject: $($ca.Subject)" Write-Host " Valid until: $($ca.NotAfterDateTime)" Write-Host " Status: $($ca.Status)"
# Für Issuing CAs: ausgestellte Zertifikate zählen if ($ca.CertificationAuthorityType -eq "issuing") { $leaves = Get-MgBetaDeviceManagementCertificateAuthority` IssuedCertificate -CertificateAuthorityId $ca.Id Write-Host " Issued leaf certs: $($leaves.Count)" } }
# Limit beachten: Die Admin-Center-Ansicht zeigt nur die ersten # 1.000 ausgestellten Zertifikate. Die Graph-API liefert mehr, # braucht aber Paginierung bei großen Beständen. |
|---|
7. Wer heute schon umsteigen sollte — und wer nicht
Aus den Funktionsgrenzen und der Lizenz-Roadmap ergeben sich für die meisten Unternehmen klare Entscheidungs-Pfade.
|
Profil |
Empfehlung |
Begründung |
|---|---|---|
|
Greenfield, cloud-first, vor allem Intune-Geräte |
Heute starten mit Microsoft Root |
Schnell aufgebaut, kein historisches Setup, Lock-in akzeptabel |
|
M365 E5 vorhanden, ADCS für mehr als Intune im Einsatz |
Warten bis Oktober 2026, dann BYOCA |
Lizenz wird sowieso inkludiert, Migration parallel zur ADCS-Modernisierung |
|
M365 E3 und Intune Plan 1, kein Add-on-Budget |
Status quo, ADCS gepflegt halten |
Cloud PKI bleibt für E3 Add-on-pflichtig und in der Wirtschaftlichkeit fragwürdig |
|
Stark regulierte Branche (KRITIS, BSI-Hoch) |
BYOCA mit eng begrenztem Scope |
Vertrauenshoheit bleibt on-prem, Cloud nur für ausgewählte Workloads |
|
Mac- oder Linux-fokussiert, vor allem Server-TLS |
Cloud PKI ist hier nicht die Antwort |
Server-TLS nicht im Funktionsumfang, andere Lösung suchen |
|
Info · Verweis · Verweis auf Schwester-Spokes Wer abwägt zwischen Cloud-PKI-Wechsel und Verbleib bei ADCS, findet die Gesamt-Entscheidungsmatrix in Spoke 6.1 (Cloud-PKI vs. On-Prem ADCS). Wer ACME für ADCS-Workloads nachrüsten will, weil Cloud PKI dafür nicht geeignet ist, findet die Optionen in Spoke 6.5 (ACME für ADCS). |
|---|
Praxis-Beispiel — Sparfuchs & Partner Steuerberatungs GmbH
Sparfuchs & Partner ist eine kleinere Steuerkanzlei mit knapp 60 Beschäftigten an zwei Standorten. Compliance-Anforderungen sind hoch (Steuerberatungsgesetz, DSGVO, gehobene Vertraulichkeitsklassen), das IT-Budget ist überschaubar. Die ITler tragen den Hauptberuf "Partner-Erklär-Bär" und nicht "PKI-Architekt". Bestand: keine produktive ADCS, alle Macs der Steuerberater laufen über ein älteres Jamf-Setup, die Windows-Notebooks der Sachbearbeiter sind seit 2024 in Intune.
Auslöser für das PKI-Thema war ein Audit-Hinweis: Das Wi-Fi läuft noch mit PSK, das ist bei vertraulichen Mandantendaten nicht mehr zeitgemäß. Die Frage war, ob für 60 Mitarbeiter eine eigene ADCS-Hierarchie aufgesetzt werden soll oder ob Cloud PKI reicht.
Die Antwort war eindeutig Cloud PKI mit Microsoft Root. Sparfuchs hat M365 Business Premium, kein E5 — der Cloud-PKI-Add-on-Aufpreis von rund 800 Euro pro Jahr für 60 User ist überschaubar und ersetzt die Notwendigkeit, eine eigene CA-Infrastruktur aufzubauen und zu pflegen. EAP-TLS Wi-Fi-Authentifizierung für alle Intune-verwalteten Windows-Notebooks läuft seit dem Rollout problemlos. Die Macs unter Jamf werden in einer zweiten Stufe entweder zu Intune umgezogen oder behalten ihre bisherige Anmeldung — das ist ein paralleles Thema, kein PKI-Thema.
Der Aufwand für die Implementierung: drei Personentage einschließlich Wi-Fi-Konfiguration und Intune-Profil-Rollout. Würde Sparfuchs zu E5 wechseln (was wegen anderer Features ohnehin im Gespräch ist), entfällt der Cloud-PKI-Posten ab Oktober 2026 sowieso aus der Rechnung.
Verwandte Themen
Häufige Fragen (FAQ)
Kann Microsoft Cloud PKI meine bestehende ADCS komplett ersetzen?
Nein, in den allermeisten Fällen nicht. Cloud PKI deckt nur Intune-verwaltete Geräte und einen klar umrissenen Funktionsumfang ab. Server-TLS, klassisches Smartcard-Logon mit PIV-Karte, S/MIME für Outlook-User, Codesigning, ACME für Linux-Workloads — alles weiterhin Sache von ADCS oder anderen Lösungen.
Wie unterscheidet sich Cloud PKI von Azure Key Vault Managed HSM?
Cloud PKI ist eine fertige Managed-CA, die Zertifikate für Intune-verwaltete Geräte ausstellt. Azure Key Vault Managed HSM ist eine reine HSM-Hardware in der Cloud — du musst die CA-Logik selbst bauen, etwa mit einem Drittprodukt wie EZCA. Für Unternehmens-PKI im typischen Microsoft-Stack ist Cloud PKI der naheliegende Weg.
Wann macht Bring Your Own CA (BYOCA) Sinn?
Sobald eine ordentliche ADCS-Hierarchie bereits existiert und du die Vertrauenswurzel im Haus behalten willst. Vor allem in regulierten Umfeldern (BSI, NIS2, KRITIS) ist BYOCA fast immer die richtige Wahl — sie hält die Audit-Kette geschlossen und reduziert den Lock-in. Greenfield-Setups ohne ADCS fahren auch mit der Microsoft-Root-Variante gut, müssen sich aber bewusst sein, dass ein späterer Anbieterwechsel teuer wird.
Was passiert mit meinen Cloud-PKI-Zertifikaten, wenn ich Intune oder das Add-on kündige?
Die ausgestellten Zertifikate bleiben technisch bis zu ihrem Ablauf gültig, aber die Issuing CA stellt nichts Neues mehr aus und die CRL-URI ist nicht mehr garantiert erreichbar. Bei produktiven Workloads heißt das: rechtzeitig vor der Kündigung alle Zertifikate auf eine andere Quelle umstellen, sonst läuft das in jedem Fall in einen Ausfall.
Kann ich Cloud PKI für VPN- oder Wi-Fi-Server-Zertifikate nutzen?
Nein, ausdrücklich nicht. Cloud PKI stellt nur End-Entity-Zertifikate für Intune-verwaltete Geräte aus. Das TLS-Zertifikat des RADIUS- oder VPN-Servers muss aus einer anderen PKI kommen — typischerweise deiner ADCS oder einer öffentlichen CA. Die Geräte müssen dann beiden Trust-Chains vertrauen.
Lohnt es sich, jetzt schon mit der Cloud-PKI-Migration zu starten, obwohl die Lizenz ab Oktober 2026 günstiger wird?
Das hängt vom Bestand ab. Wer M365 E5 hat und keine akuten Schmerzen mit dem NDES- oder Intune-Connector-Setup, sollte den Oktober 2026 abwarten — der Add-on-Wegfall macht die Rechnung deutlich besser. Wer akute Probleme mit NDES hat oder sowieso eine Modernisierung plant, kann jetzt schon starten und nimmt das günstigere Lizenzmodell mit, sobald es greift.
Nächste Schritte mit boddenberg.de
Microsoft Cloud PKI ist verlockend einfach in der Inbetriebnahme — und gleichzeitig anspruchsvoll in der strategischen Einordnung. Wer falsch einsteigt, baut sich Lock-in oder eine schiefe Trust-Chain. Drei Wege, das gemeinsam sauber zu klären:
Wer parallel die TLS-Erneuerungslogik auf Microsoft-Servern modernisieren will, sollte sich CertBinder anschauen (siehe Spoke 5.2). Atomare TLS-Erneuerung ergänzt jedes Setup, in dem TLS-Zertifikate weiter aus ADCS kommen und Cloud PKI nur den Intune-Anteil übernimmt.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund