Cloud-PKI-Migration: ADCS ergänzen, nicht ersetzen
Hybrid-Architektur statt Entweder-oder – was Cloud-PKI kann und wo ADCS bleibtCloud-PKI-Migration – wann der Schritt aus On-Prem sinnvoll ist
Kurzfassung vorab
Cloud-PKI ist kein Ersatz für ADCS, sondern eine Entlastung. Sie nimmt der On-Prem-CA die Last der MDM-verwalteten Geräte ab – aber Domain-Controller, Server-CSRs und Netzwerkgeräte bleiben Sache von ADCS. Deshalb landet die Mehrheit nicht bei „Cloud statt On-Prem“, sondern bei einer hybriden Architektur: Cloud für die Geräteflotte, ADCS für alles, was die Cloud-CA heute nicht kann. Wer das versteht, stellt nicht die Frage „umsteigen oder nicht“, sondern „was gehört wohin“.
Abb. 1: Die drei Betriebsmodelle. Hybrid ist 2026 für die meisten Organisationen der realistische Weg.
1. Was Cloud-PKI kann – und was nicht
Cloud-PKI-Dienste stellen Zertifikate bereit, ohne dass du eigene CA-Server, NDES-Rollen oder Zertifikats-Connectoren betreiben musst. Der typische Ausstellungsweg läuft über SCEP an Geräte, die über ein Mobile-Device-Management wie Intune verwaltet werden. Das ist stark für Laptop- und Mobilflotten, die ohnehin cloud-verwaltet sind.
Die Grenze ist genauso wichtig wie die Stärke: Cloud-PKI bedient heute primär MDM-verwaltete Geräte. Das Signieren von Zertifikatsanträgen anderer Server, Netzwerk- oder Sicherheitsgeräte – wie es ADCS über die Certificate Enrollment Web Services und andere Mechanismen leistet – gehört nicht zum Funktionsumfang. Wer Domain-Controller-Zertifikate, Server-CSRs oder 802.1x für Switches braucht, kommt um eine On-Prem-CA nicht herum.
|
Warnung · Cloud-PKI ist kein Komplettersatz Wer glaubt, mit einem Cloud-PKI-Dienst die gesamte ADCS abschalten zu können, erlebt eine böse Überraschung beim ersten Domain-Controller-Zertifikat oder beim Netzwerk-Switch, der per CSR ein Zertifikat will. Cloud-PKI ergänzt ADCS, sie ersetzt es nicht universell. |
|---|
2. Die Entscheidungskriterien ehrlich gegenübergestellt
Die Frage „Cloud oder On-Prem“ lässt sich nicht pauschal beantworten, weil verschiedene Anforderungen in verschiedene Richtungen zeigen. Die folgende Gegenüberstellung hilft, die eigene Lage einzuordnen – Zeile für Zeile.
Abb. 2: Entscheidungskriterien. Die meisten Zeilen sprechen für das eine oder das andere – selten für alles dasselbe.
Wenn dein Gerätepark überwiegend Intune-verwaltet ist und du wenig PKI-Know-how im Haus hast, spricht viel für Cloud. Hast du Domain-Controller, Server-CSRs, Netzwerkgeräte oder strenge Datenhoheits-Anforderungen, bleibt On-Prem im Spiel. Genau weil die Kriterien gemischt ausfallen, ist Hybrid so oft die Antwort.
3. Die Hybrid-Architektur: ein Anker, zwei Wege
Der eleganteste Aufbau kombiniert beide Welten unter einem gemeinsamen Vertrauensanker. Die bestehende Offline Root CA bleibt der zentrale Trust-Punkt. Darunter hängen zwei Issuing-Wege: die On-Prem-ADCS für alles Klassische und eine Cloud-Issuing-CA für die Geräteflotte.
Abb. 3: Eine Root, zwei Ausstellungswege. Über BYOCA wird die Cloud-CA an die bestehende Root verankert – eine Kette für alle.
Der Schlüssel dazu heißt Bring Your Own CA (BYOCA): Die Cloud-Issuing-CA wird an deine bestehende On-Prem-Root angebunden, statt einen eigenen Vertrauensanker aufzubauen. Das Ergebnis: Alle Endgeräte vertrauen derselben Kette, egal ob ihr Zertifikat aus der Cloud oder aus ADCS kommt. Kein zweites Root-Rollout, kein paralleler Trust-Store.
|
Praxis-Tipp · EKUs vorab durchdenken Bei einer hybriden Hierarchie müssen die Extended Key Usages konsistent vom Root bis zum Endzertifikat durchgeplant sein. Wer später S/MIME oder Code-Signing über die Cloud-CA ausstellen will, muss die passenden EKUs schon in der Trust-Kette vorgesehen haben. Das ist Designarbeit, die vor der ersten Ausstellung passieren muss. |
|---|
4. Der Migrationspfad: umlenken statt abreißen
Eine Cloud-Migration der PKI ist kein Stichtag, sondern eine Verlagerung in Etappen. Du reißt nichts ab, du lenkst Last um. Die On-Prem-CA bleibt – aber sie macht am Ende nur noch das, was die Cloud nicht kann.
Abb. 4: Der Migrationspfad in vier Etappen. Die On-Prem-CA wird bewusst behalten, aber entlastet.
|
Info · Verantwortung und Lizenz Auch in der Cloud bleibt die Zertifikatsstrategie deine Aufgabe: Template-Design, EKU-Planung, Lifecycle und Sperrung steuerst du. Der Anbieter betreibt die Infrastruktur, nicht deine Strategie. Lizenzhinweis: Cloud-PKI war bisher ein kostenpflichtiges Add-on. Ab dem 1. Juli 2026 ist es für E5-Kunden Teil der Intune Suite – das senkt die Einstiegshürde spürbar. |
|---|
Praxis-Beispiel
Ausgangslage: Die Trendforge Digital GmbH (Tech-Scaleup, stark cloud-orientiert) betreibt eine On-Prem-ADCS samt NDES, nur um ihre rund 600 Intune-verwalteten Laptops und Mobilgeräte mit WLAN- und VPN-Zertifikaten zu versorgen. Der NDES-Server ist ein ungeliebtes Einzelstück, das niemand anfassen will.
Maßnahme: Statt NDES weiter zu pflegen, binden wir eine Cloud-Issuing-CA per BYOCA an die bestehende Offline Root an. Die Intune-Geräte bekommen SCEP-Profile, die auf die Cloud-CA zeigen. Domain-Controller und die wenigen Server-Zertifikate bleiben bei der On-Prem-ADCS. Die Inventur zeigt klar: Nur die MDM-Flotte wandert, der Rest bleibt.
Ergebnis: Der NDES-Server konnte abgeschaltet werden, die Betriebslast für die Geräteflotte liegt jetzt beim Cloud-Dienst. Die On-Prem-CA ist deutlich schlanker, macht aber weiter, was nur sie kann. Alle Geräte vertrauen weiter derselben Root – für die Anwender hat sich nichts geändert.
Verwandte Themen
Häufige Fragen (FAQ)
Kann Cloud-PKI meine On-Prem-ADCS vollständig ersetzen?
In den meisten Umgebungen nicht. Cloud-PKI bedient vor allem MDM-verwaltete Geräte über SCEP. Domain-Controller-Zertifikate, das Signieren von Server-CSRs und Zertifikate für Netzwerkgeräte gehören heute nicht zum Funktionsumfang. Wer diese Szenarien hat, braucht weiterhin eine On-Prem-CA.
Was bedeutet BYOCA bei einer Cloud-PKI?
BYOCA steht für Bring Your Own CA. Dabei wird die Cloud-Issuing-CA an deine bestehende On-Prem-Root verankert, statt einen eigenen Vertrauensanker aufzubauen. So vertrauen alle Endgeräte derselben Kette, egal ob ihr Zertifikat aus der Cloud oder aus ADCS stammt.
Für wen lohnt sich der Schritt in die Cloud-PKI?
Vor allem für Organisationen mit überwiegend Intune-verwalteten Geräten und wenig PKI-Know-how im Haus. Wer dagegen viele Domain-Controller, Server-CSRs, Netzwerkgeräte oder strenge Datenhoheits-Anforderungen hat, fährt mit einer hybriden oder rein On-Prem-Lösung besser.
Übernimmt der Cloud-Anbieter die Verantwortung für meine PKI?
Nur für den Betrieb der Infrastruktur. Template-Design, EKU-Planung, Zertifikats-Lifecycle und Sperrung bleiben deine Aufgabe. Cloud-PKI nimmt dir die Server-Wartung ab, nicht die Zertifikatsstrategie – die musst du weiterhin selbst steuern.
Wie läuft eine Cloud-PKI-Migration praktisch ab?
In vier Etappen: zuerst eine Inventur erstellen, welche Geräte welche Zertifikate brauchen, dann die Cloud-CA per BYOCA an die bestehende Root verankern, anschließend die MDM-Geräte per SCEP-Profil umlenken und schließlich die On-Prem-CA auf das reduzieren, was die Cloud nicht kann.
Was ändert sich 2026 bei der Lizenzierung von Cloud-PKI?
Cloud-PKI war bisher ein kostenpflichtiges Add-on oder Teil der Intune Suite. Ab dem 1. Juli 2026 steht es E5-Kunden ohne Zusatzkosten als Teil der Intune Suite zur Verfügung. Für Organisationen, die bereits E5 nutzen, entfällt damit eine Lizenzhürde.
Nächste Schritte mit boddenberg.de
Die Cloud-Frage ist eine Architekturfrage, keine Produktfrage. Was bei dir wohin gehört, klärt am besten eine nüchterne Bestandsaufnahme:
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund