Alles, was Sie über PKI-as-a-Service (PKIaaS) wissen müssen

Am 21. Juli 2024 legte ein abgelaufenes Zertifikat in der Infrastruktur der Bank of England deren CHAPS- und Retail-Settlement-Systeme für 91 Minuten lahm – so die Angaben der Bank selbst. Das ist kein unbedeutender IT-Fehler. Es verdeutlicht, dass abgelaufene oder falsch verwaltete Zertifikate ein Zahlungssystem lahmlegen können. PKI-as-a-Service (PKI-as-a-Service) verhindert genau dieses Szenario, indem der gesamte Zertifikatslebenszyklus – von der Einrichtung einer Zertifizierungsstelle (CA) über die Ausstellung und Erneuerung bis hin zum Widerruf von Endbenutzerzertifikaten – auf eine verwaltete Cloud-Plattform verlagert wird.

Statt Hardware zu kaufen, Software einzurichten und eigenes PKI-Personal einzustellen, erhalten Sie dieselbe Vertrauensinfrastruktur als Dienstleistung, wobei automatisierte Verfahren und ein geringerer Aufwand die Verwaltung des Zertifikatslebenszyklus für Sie übernehmen.

Executive Summary

PKI-as-a-Service (PKIaaS) hostet die Stamm- und ausstellenden Zertifizierungsstellen einer Organisation in der Cloud und automatisiert die Ausstellung, Verlängerung und den Widerruf von Zertifikaten. Folgendes ist für ein PKI- oder Sicherheitsteam bei der Evaluierung von PKIaaS am wichtigsten:

• PKIaaS hostet Ihre Root- und Issuing-CAs in der Cloud und verwaltet den gesamten Zertifikatslebenszyklus in Ihrem Auftrag.
• Es verwendet die gleichen PKI-Bausteine ​​wie eine lokale Bereitstellung: öffentliche/private Schlüsselpaare, digitale Zertifikate und eine auf einer Zertifizierungsstelle basierende Vertrauenskette.
• Mit der Abstimmung im CA/Browser Forum SC-081v3 wurde die maximale Lebensdauer öffentlicher TLS-Zertifikate ab dem 15. März 2026 auf 200 Tage und bis März 2029 auf 47 Tage verkürzt, wodurch die manuelle Zertifikatsverwaltung zunehmend unpraktisch wird.
• Automatisierte Registrierungsprotokolle (ACME, SCEP, EST, WSTEP) ermöglichen es PKIaaS, Zertifikate auszustellen und zu erneuern, ohne dass ein Mensch jedes Mal auf „Erneuern“ klicken muss.
• PKIaaS tauscht die anfänglichen Hardware- und Personalkosten gegen ein Abonnementmodell, ermöglicht Ihnen aber dennoch die Kontrolle über die Zertifikatsrichtlinien und, im Modell von Encryption Consulting, über Ihre eigenen privaten Schlüssel.

Nachdem Sie nun einen ersten Überblick über PKIaaS erhalten haben, schauen wir uns an, wie es mit der Public Key Infrastructure selbst zusammenhängt, denn PKIaaS ersetzt nicht die PKI-Konzepte, sondern ändert lediglich, wer sie betreibt.

Wie PKI-as-a-Service mit der Public-Key-Infrastruktur (PKI) zusammenhängt

PKI stellt digitale Zertifikate (wie SSL/TLS-Zertifikate) zur Authentifizierung der Datenkommunikation mittels asymmetrischer Verschlüsselung aus und generiert X.509-Zertifikate aus öffentlichen und privaten Schlüsselpaaren. Unabhängig davon, ob Sie dies intern betreiben oder als PKI-Lösung beziehen, bilden dieselben vier Komponenten die Vertrauenskette.

Öffentliche und private Schlüssel

Öffentliche und private Schlüssel ermöglichen asymmetrische Verschlüsselung. Wenn ein Client sensible Informationen empfangen muss, teilt er dem Absender seinen öffentlichen Schlüssel mit, um die Daten zu verschlüsseln. Nur der Inhaber des zugehörigen privaten Schlüssels kann die Daten entschlüsseln und lesen.

Digitale Zertifikate

Der private Schlüssel der Zertifizierungsstelle signiert das digitale Zertifikat . Diese Signatur bestätigt sowohl die Identität des Zertifikatsinhabers als auch dessen Eigentumsrecht am zugehörigen öffentlichen Schlüssel.

Zertifizierungsstelle: Stammzertifizierungsstelle und ausstellende Zertifizierungsstelle

Die Zertifizierungsstelle signiert und stellt das digitale Zertifikat mit ihrem eigenen privaten Schlüssel aus. Es gibt zwei Ebenen:

• StammzertifizierungsstelleDie oberste Zertifizierungsstelle (CA) bildet die Vertrauensgrundlage in der PKI-Hierarchie. Sie stellt Zertifikate für Zwischenzertifizierungsstellen aus und signiert diese. Zum Schutz des langfristigen Vertrauens wird sie üblicherweise offline in einer hochsicheren Umgebung betrieben.
• Ausstellende ZertifizierungsstelleDiese Plattform verarbeitet und signiert Endbenutzerzertifikatsanforderungen (z. B. SSL/TLS-Zertifikate), unabhängig davon, ob diese über einen Microsoft-CA-Proxy oder einen anderen Registrierungsweg eingehen. Sie arbeitet online und übernimmt die tägliche Ausstellung, Verlängerung und den Widerruf von Zertifikaten.

Registrierungsstelle

Die Registrierungsstelle fungiert als Bindeglied zwischen Nutzern und der Zertifizierungsstelle. Sie überprüft die Identität aller Antragsteller eines Zertifikats und leitet validierte Anfragen anschließend zur Ausstellung an die Zertifizierungsstelle weiter.

PKI-as-a-Service vs. Selbstverwaltete (traditionelle) PKI: Welche ist die richtige für Sie?

Die oben genannten Komponenten sind unabhängig davon, ob Sie PKI lokal (selbstverwaltet) einsetzen oder als PKIaaS beziehen. Der Unterschied liegt im Betreiber, und dieser beeinflusst Kosten, Geschwindigkeit und Skalierbarkeit.

Faktor	PKI-as-a-Service	Selbstverwaltete (traditionelle) PKI
Einsatz	Schnelle, unkomplizierte Einrichtung mit minimalem Infrastrukturaufwand seitens Ihres Unternehmens.	Für die Konfiguration von Hardware, Software und Netzwerk werden erheblicher Zeitaufwand, Fachwissen und Ressourcen benötigt.
Verwaltung	Die Ausstellung, Verlängerung und der Widerruf von Zertifikaten werden vom Dienstleister übernommen, wodurch der operative Aufwand reduziert wird.	Die Verwaltung erfolgt intern und erfordert daher dediziertes Personal für die laufenden Zertifizierungsaufgaben und die Instandhaltung.
Skalierbarkeit	Die Cloud-Infrastruktur passt sich automatisch an, wenn das Zertifikatsvolumen wächst oder schwankt.	Für eine Skalierung sind zusätzliche Hardware, Softwarelizenzen und Konfigurationsänderungen erforderlich.
Kosten	Das Abonnementmodell eliminiert Hardware-, Software- und laufende Wartungskosten und reduziert so die Vorabinvestitionen.	Erfordert hohe Vorabinvestitionen in Hardware, Softwareinstallation und laufende Verwaltung.
Erneuerungsintervall bei einer Gültigkeitsdauer von 47 Tagen	Automatisierte Ausgabeprotokolle (ACME, SCEP, EST) kompensieren die Erneuerungshäufigkeit ohne zusätzlichen Personalaufwand.	Manuelle Erneuerungsprozesse versagen schon lange bevor die Zertifikate eine Gültigkeitsdauer von 100 Tagen erreichen, geschweige denn von 47 Tagen.

PKI-as-a-Service eignet sich besonders für Organisationen, die Wert auf Benutzerfreundlichkeit, Kosteneinsparungen und schnelle Bereitstellung legen, insbesondere angesichts der immer kürzeren Gültigkeitsdauer von Zertifikaten. Organisationen mit strengen Anforderungen an den Datenstandort oder hochspezialisierten CA-Konfigurationen haben unter Umständen weiterhin gute Gründe, ihre PKI selbst zu verwalten, doch diese Gründe werden mit zunehmender Reife der Automatisierungsprotokolle immer weniger.

Entscheidungstabelle für Käufer: Welches PKI-Bereitstellungsmodell passt zu Ihrer Organisation?

Nutzen Sie diese Tabelle, um die Einschränkungen Ihrer Organisation mit einem Bereitstellungsmodell abzugleichen, bevor Sie Anbieter evaluieren.

Kriterium	On-Prem PKI	SaaS PKI	PKIaaS
Speziell geschultes PKI-Personal verfügbar	Erforderlich	Reduziert, aber für die Politik weiterhin notwendig.	Nicht erforderlich
Wachstum des Zertifikatsvolumens	Für die Skalierung wird neue Hardware benötigt.	Skaliert innerhalb Ihres Cloud-Mandanten	Automatische Skalierung, vom Anbieter verwaltet
Zeit bis zum ersten Zertifikat	Wochen bis Monate	Tage bis Wochen	Tage
Budgetmodell	Hoher Kapitalbedarf im Vorfeld	Cloud-Verbrauch plus interner Personalaufwand	Abonnement, minimale Vorabkosten
Private Schlüsselkontrolle	Vollständig, in Ihren eigenen HSMs	Vollständig, in Ihrem eigenen Cloud-Mandanten	Vollständig, in vom Anbieter gehosteten HSMs (im Modell von Encryption Consulting)
Am besten geeignet für	Strenge Datenresidenz oder hochspezialisierte CA-Konfigurationen	Organisationen, die bereits auf eine Cloud-Plattform umgestiegen sind	Organisationen, die Geschwindigkeit, Automatisierung und reduzierten Gemeinkosten Priorität einräumen

So funktioniert PKI-as-a-Service: Der Zertifikatsanforderungsprozess

Von dem Moment an, in dem ein Gerät eine Zertifikatsignierungsanforderung einreicht , bis zu dem Moment, in dem es ein signiertes Zertifikat erhält, durchläuft die PKIaaS-Plattform fünf Schritte:

1. Einleitung der Zertifikatsanforderung. Ein Client fordert ein Zertifikat mithilfe eines Protokolls wie ACME, SCEP oder IntuneDie Anfrage geht an das Certificate Enrollment Gateway (CEG), das mithilfe seines eigenen Clientzertifikats eine sichere Verbindung zum Certificate Authority Gateway (CAGW) herstellt.
2. Anfragebearbeitung. Der auf einem containerisierten System gehostete CAGW empfängt die Anfrage und leitet sie über einen sicheren Proxy an die entsprechende Managed CA weiter.
3. Verbindung zur ausstellenden Zertifizierungsstelle. Der Proxy stellt die Brücke zwischen dem CAGW und der designierten ausstellenden Zertifizierungsstelle her, wobei die Verbindung durch gegenseitige Client- und Serverzertifikate gesichert wird.
4. Ausstellung des Zertifikats. Die ausstellende Zertifizierungsstelle stellt das Endbenutzerzertifikat aus, häufig über Active Directory-Zertifikatdienste (AD CS).
5. Zertifikatszustellung. Das signierte Zertifikat wird über den Proxy an den CAGW zurückgesendet, der es an den CEG zur Zustellung an den anfragenden Client weiterleitet.

Jeder Schritt in dieser Kette ist durch gegenseitige Zertifikatsauthentifizierung gesichert, sodass der gesamte Prozess von der Anfrage bis zur Zustellung ohne manuelle Genehmigung jedes einzelnen Zertifikats abläuft.

Hauptmerkmale von PKI-as-a-Service

PKI-as-a-Service bietet umfassende Funktionen zur Verwaltung digitaler Zertifikate und Schlüsselpaare. Die Kernfunktionen lassen sich in vier Gruppen einteilen:

• PKI-InfrastrukturmanagementDie zentrale Konfiguration der verwalteten PKI, einschließlich der optionalen Trennung der Root-CA, erfolgt gemäß den Best Practices der Branche, wie z. B. FIPS 140-3 Level 3 HSMs, um die privaten Schlüssel der CAs hochverfügbar zu sichern. Da NIST die Validierungszertifikate nach FIPS 140-2 am 21. September 2026 auf den Status „Historisch“ setzt, sollten neue HSM-Implementierungen FIPS 140-3 spezifizieren.
• Sicherheit der ZertifizierungsstelleDie Root-CA-Schlüssel werden sicher und transparent generiert, mit automatischen Registrierungsprotokollen wie SCEP, EST und ACME sowie REST-APIs, die die Ausstellung und Erneuerung automatisieren.
• Richtlinien- und Compliance-Management: Zertifikatsprofile, Gültigkeitszeiträume und Schlüsselverwendungsbeschränkungen werden so definiert, dass sie den Sicherheitsanforderungen Ihrer Organisation entsprechen und gleichzeitig Standards wie NIST, FIPS und DSGVO einhalten.
• Integration und AutomatisierungRESTful APIs verbinden PKI-Dienste mit anderen Anwendungen und Systemen, wobei Skripte und Tools die Ausstellung und Verwaltung von Anfang bis Ende automatisieren.

Anwendungsfälle und unterstützte Protokolle für PKI-as-a-Service

PKIaaS generiert seinen Wert durch Automatisierung, und diese Automatisierung basiert auf standardisierten Registrierungsprotokollen. Im Folgenden wird die Funktion jedes einzelnen Protokolls und dessen Anwendungsbereich erläutert.

Automatisierte Zertifikatverwaltungsumgebung (ACME)

• Automatisiert die Kommunikation zwischen Zertifizierungsstellen und Clients, die Serverzertifikate für eine in RFC 8555 definierte Domäne anfordern.
• Validiert die Domaininhaberschaft mittels HTTP-01 (Platzierung einer Datei auf dem Webserver) oder DNS-01 (Erstellung eines DNS-Eintrags).
• Die Kommunikation erfolgt über HTTPS, wodurch der Zertifikatsverwaltungsprozess sicher und manipulationssicher bleibt.
• Es handelt sich um das Protokoll, dessen Unterstützung CA-Antragsteller seit Februar 2024 im Rahmen des Chrome Root Programs vorschreiben müssen, und um dasjenige, das durch die verkürzten Zertifikatslebensdauern des CA/Browser Forums am direktesten belohnt wird, da es für die vollständige Automatisierung ohne manuellen Erneuerungsschritt konzipiert ist.

Einfaches Zertifikatsregistrierungsprotokoll (SCEP)

• Automatisiert die Zertifikatsregistrierung für Geräte wie Router und Switches und reduziert so den manuellen Aufwand in Umgebungen mit vielen Geräten.
• Verwendet PKCS#10 (Public-Key-Kryptografiestandards) für Zertifikatsanfragen, standardisiert in RFC 8894 (2020), nachdem es jahrzehntelang ein De-facto-Standard war.
• Überprüft vor der Ausstellung eines Zertifikats die Identität des anfragenden Geräts oder Benutzers mittels eines gemeinsamen Herausforderungspassworts.
• Wird weiterhin häufig im Bereich Mobile Device Management (MDM) und in älteren Netzwerk-Hardware eingesetzt, obwohl EST der moderne und sicherere Nachfolger ist.

Anmeldung über sichere Übertragung (EST)

• In RFC 7030 als moderner Ersatz für SCEP definiert, läuft es über HTTPS mit gegenseitiger TLS-Authentifizierung.
• Sowohl Client als auch Server authentifizieren sich gegenseitig und schließen so eine Vertrauenslücke, die das Shared-Password-Modell von SCEP offen lässt.
• Geeignet für Enterprise-PKI- und IoT-Implementierungen, die bereits über eine TLS-Infrastruktur verfügen und eine stärkere gegenseitige Authentifizierung benötigen, als SCEP bietet.

WSTEP (Windows-Registrierung)

• Ermöglicht es einem Windows-Registrierungsclient, über den Zertifikatregistrierungsrichtlinien-Webdienst eine Verbindung zu einem Domänencontroller herzustellen und Zertifikate von mehreren Zertifizierungsstellen anzufordern.
• Beschränkt den Zertifikatszugriff auf autorisierte Geräte und verbessert so die allgemeine Netzwerksicherheit.
• Schützt Zertifikatsregistrierung Datenübertragung über sichere Kanäle und Verschlüsselung.

Microsoft Intune-Integration

• Das Certificate Enrollment Gateway kann SCEP-Anfragen mit einer CSR von Windows-Clients empfangen und diese zur Validierung an Intune weiterleiten, wodurch die Geräteverwaltung über mobile Geräte, Desktops und virtuelle Endpunkte hinweg optimiert wird.
• Kryptografische Richtlinien und Algorithmen werden an regulatorischen und Compliance-Anforderungen ausgerichtet.
• Der automatische Widerruf in Intune beschleunigt die Zertifikatsinvalidierung und unterstützt so einen besseren Notfallwiederherstellungsplan.

Endpunktauthentifizierung (UEM/MDM)

• Überprüft, ob Zertifikate mit starken Sicherheitseinstellungen ausgestellt werden, und ermöglicht so die Transparenz hinsichtlich Zertifikatsnutzung und -gültigkeit.
• Erfordert, dass sich Mobile Device Management (MDM)-Clients mit gültigen Anmeldeinformationen beim Certificate Enrollment Gateway authentifizieren, wobei pro Client mindestens ein Benutzername/Passwort-Paar definiert sein muss.
• Setzt eine detaillierte Zugriffskontrolle und rollenbasierte Berechtigungen durch, eine Compliance-Anforderung gemäß NIST und FIPS 140-3, sodass nur autorisiertes Personal sensible Zertifikatsfunktionen verwalten kann.
• Zertifikate werden erst ausgestellt, nachdem sowohl Integritätsprüfungen als auch der Stand der Sicherheitspatches auf dem anfragenden Gerät geprüft wurden.

S / MIME

• Bietet Ende-zu-Ende-Verschlüsselung für E-Mail-Nachrichten.
• Trennt die Signier- und Verschlüsselungsfunktionalität, sodass S/MIME-Zertifikate neben Vertraulichkeit auch Nichtabstreitbarkeit gewährleisten.
• Nutzt Schlüsselhistorienverwaltung und automatisierte Datensicherung, um kryptografische Schlüssel ohne Unterbrechung verfügbar zu halten.
• Funktioniert unter Windows, macOS, iOS und Android.

Verwaltete PKI

• Sichert die Root-CA-Infrastruktur gemäß ISO/IEC 27001-Standards und schützt so kryptografische Assets.
• Sie behalten die volle Kontrolle über Ihre privaten Schlüssel und haben jederzeit die volle Kontrolle über Zertifikate und kryptografische Operationen.
• Speichert private Schlüssel gemäß FIPS 140-3 Level 3 zertifiziert Hardware-Sicherheitsmodule (HSMs) um unbefugten Zugriff oder Manipulation zu verhindern.
• Überprüft die Gültigkeit und den Status des Zertifikats anhand der CRL (Zertifikatssperrliste) und OCSP (Online Certificate Status Protocol) Dienstleistungen.

Checkliste für Service-Level-Agreements (SLAs) und Sicherheitskontrollen zur Bewertung eines PKIaaS-Anbieters

Bevor Sie einen PKIaaS-Vertrag unterzeichnen, vergewissern Sie sich, dass der Anbieter diese SLA- und Sicherheitskontrollvorgaben erfüllt:

• Veröffentlichte Verfügbarkeits-SLA (99.9 % oder höher) für Ausgabe-, Verlängerungs- und Widerrufs-Endpunkte mit dokumentierten Reaktionszeiten bei Störungen.
• Die privaten Schlüssel für Root und ausstellende Zertifizierungsstelle werden in FIPS 140-3 Level 3 validierten HSMs generiert und gespeichert, nicht auf Allzweckservern.
• Die Verfügbarkeitszusagen für CRL- und OCSP-Responder werden separat von der Kern-SLA für die Ausstellung von Service-Level-Agreements (SLA) veröffentlicht.
• Dokumentierte Schlüsselzeremonieverfahren und Prüfrechte für die Generierung von Root-CA-Schlüsseln.
• Eine angegebene Bearbeitungszeit für den Zertifikatswiderruf nach einer gemeldeten Schlüsselkompromittierung.
• Rollenbasierte Zugriffskontrolle und Mehrpersonenautorisierung für sensible CA-Operationen.
• Klare Offenlegung des Speicherorts der Zertifikatsmetadaten und Audit-Logs, um die Datenlokalität zu bestätigen.
• Dokumentierte Architektur für Notfallwiederherstellung und Failover auf der Ebene der ausstellenden Zertifizierungsstelle.
• Aktuelle Konformitätszertifizierungen (ISO/IEC 27001, SOC 2, PCI-DSS, HIPAA, DSGVO) mit aktuellen Prüfdaten.
• Vertragsbedingungen, die das Eigentum am privaten Schlüssel und dessen Übertragbarkeit bei einem späteren Anbieterwechsel bestätigen.

HSM- und Compliance-Anforderungen für PKI-as-a-Service

Eine PKIaaS-Plattform ist nur so vertrauenswürdig wie die Hardware, die ihre CA-Privatschlüssel schützt, und der Compliance-Rahmen, der ihren Betrieb regelt.

• FIPS 140-3 Level 3 HSMsRoot- und ausstellende CA-Privatschlüssel sollten in FIPS 140-3 Level 3-validierten Hardware-Sicherheitsmodulen (HSM) generiert und gespeichert werden. Das NIST stellt FIPS 140-2-Validierungszertifikate am 21. September 2026 auf den Status „Historisch“ ein. Stellen Sie daher sicher, dass jedes von Ihrem Anbieter verwendete HSM FIPS 140-3-validiert ist und sich nicht auf ein ablaufendes FIPS 140-2-Zertifikat verlässt.
• ISO / IEC 27001Das Informationssicherheitsmanagementsystem des Anbieters sollte über eine aktuelle ISO/IEC 27001-Zertifizierung verfügen, die die Systeme abdeckt, auf denen Ihre CA-Infrastruktur gehostet wird.
• HIPAA, PCI-DSS und DSGVOWenn Ihre Zertifikate PHI, Karteninhaberdaten oder personenbezogene Daten aus der EU schützen, vergewissern Sie sich, dass die PKIaaS-Umgebung des Anbieters explizit in dessen HIPAA-, PCI-DSS- oder GDPR-Compliance-Programm einbezogen ist und nicht nur in die allgemeine Compliance-Haltung des Mutterkonzerns.
• Schlüssel-VerwahrungsmodellKlären Sie im Vorfeld, ob Ihre Organisation oder der Anbieter die letztendliche Kontrolle über den privaten Schlüssel der Root-CA besitzt. Das PKIaaS-Modell von Encryption Consulting stellt diese Kontrolle beim Kunden sicher, was nicht jeder Anbieter bietet.

Warum die Automatisierung der Zertifikatserstellung jetzt wichtig ist: Die 47-Tage-Frist

Hier kommt der Punkt, den die meisten PKI-Erklärer übergehen: Die Argumente für PKIaaS wurden im Jahr 2026 deutlich stärker, und es geht nicht mehr nur um Bequemlichkeit.

Im April 2025 verabschiedete das CA/Browser Forum den Wahlvorschlag SC-081v3, der eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate vorsieht: 200 Tage ab dem 15. März 2026 (bereits in Kraft), 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Dies entspricht einer Reduzierung von der bisherigen Gültigkeitsdauer von 398 Tagen auf Erneuerungen alle 47 Tage, also etwa achtmal jährlich, innerhalb von drei Jahren.

Die manuelle Erneuerung ist in dieser Frequenz wirtschaftlich nicht rentabel, was auch durch Branchenzahlen bestätigt wird. Der CyberArk-Bericht „State of Machine Identity Security 2025“, der auf einer Umfrage unter mehr als 1,200 Sicherheitsverantwortlichen basiert, ergab, dass 72 % der Unternehmen im vergangenen Jahr mindestens einen Zertifikatsausfall erlebten und 50 % einen Sicherheitsvorfall oder eine Datenschutzverletzung im Zusammenhang mit kompromittierten Maschinenidentitäten meldeten. Automatisierung ist mittlerweile auch Voraussetzung für öffentliche Zertifizierungsstellen (CAs): Das Chrome Root Program verlangt seit Februar 2024 von CA-Antragstellern mindestens eine Lösung für die automatisierte Ausstellung und Erneuerung jeder von ihnen ausgestellten Zertifikatsrichtlinie. Ab dem 15. Juni 2026 müssen öffentlich vertrauenswürdige TLS-Zertifikate zudem nur noch die Serverauthentifizierungs-EKU enthalten. Dies zwingt alle Unternehmen, die noch öffentliche Zertifikate für die Clientauthentifizierung oder mTLS verwenden, zu einer privaten CA.

Unsere Einschätzung: Wenn Ihr Team Zertifikate noch manuell erneuert oder in einer Tabelle erfasst, ist die 100-Tage-Phase im März 2027 der Punkt, an dem dieser Prozess scheitert – nicht die 47-Tage-Phase im Jahr 2029. Nutzen Sie die Jahre 2026–2027, um auf ACME-, SCEP- oder EST-basierte Automatisierung umzusteigen, sei es über eine interne Plattform oder einen PKIaaS-Anbieter, bevor die Erneuerungshäufigkeit die manuelle Bearbeitungskapazität Ihres Teams übersteigt.

Warum Verschlüsselungsberatung für PKI-as-a-Service?

Stellen Sie PKI-as-a-Service in Ihrer Umgebung bereit

Encryption Consulting bietet eine flexible, hochsichere PKIaaS-Lösung mit skalierbarem Support, die den gesamten Lebenszyklus digitaler Zertifikate für Ihr Unternehmen verwaltet. Zwei Bereiche sind dabei besonders hervorzuheben:

• Anpassbare und skalierbare Lösungen: ein Framework, das auf die Sicherheitsanforderungen Ihrer Organisation zugeschnitten ist, mit umfassender CA-Unterstützung und der Möglichkeit, das Zertifikats- und Benutzervolumen zu skalieren, ohne die Leistung zu beeinträchtigen.
• Konsequente Unterstützung: starke Sicherheitsfunktionen, die mit HIPAA, PCI-DSS und DSGVO sowie tägliche operative Unterstützung, um die Zertifikatsrichtlinien unter Kontrolle zu halten.

Bereitstellungsmodelle: On-Premise, SaaS-PKI und PKIaaS

Encryption Consulting unterstützt drei Bereitstellungsansätze, sodass Sie das Modell an Ihre Umgebung anpassen können:

• On-Premise PKI: Managed PKI wird innerhalb Ihrer eigenen Infrastruktur bereitgestellt, wobei Root- und Issuing-CAs lokal gehostet werden.
• SaaS PKI: Zertifikatslebenszyklusmanagement, konfiguriert innerhalb der eigenen Cloud-Plattform Ihrer Organisation.
• PKIaaS: Automatisiertes Zertifikatslebenszyklusmanagement und kundenspezifische Managed PKI, die vollständig in der Cloud-Umgebung von Encryption Consulting gehostet werden und auf Ihre Domain und Sicherheitsanforderungen zugeschnitten sind.

Fazit

PKIaaS ist die Cloud-basierte Weiterentwicklung des bewährten PKI-Vertrauensmodells, auf das Unternehmen seit Jahrzehnten vertrauen – nur ohne den Aufwand für Hardware, Personal und manuelle Aktualisierung. Jede Organisation, die sensible Daten verarbeitet, seien es personenbezogene Daten (PII) oder geschützte Gesundheitsdaten (PHI), benötigt die Authentifizierung und Verschlüsselung einer PKI. PKIaaS bietet dies als verwalteten Cloud-Service anstelle eines internen Infrastrukturprojekts.

Da die vom CA/Browser Forum angekündigten Verkürzungen der Zertifikatslebensdauer bereits im Gange sind, stellt sich nicht mehr die Frage, ob die Zertifikatsverwaltung automatisiert werden soll, sondern wann. Eine auf ACME, SCEP und EST basierende PKIaaS-Plattform bietet Ihnen diese Automatisierung ohne zusätzlichen Personalaufwand und ermöglicht Ihnen gleichzeitig die Kontrolle über die Zertifikatsrichtlinien sowie – je nach Anbieter – über Ihre privaten Schlüssel.

Häufig gestellte Fragen zu PKI-as-a-Service

Was ist die wichtigste Erkenntnis aus diesem Leitfaden zu PKI-as-a-Service?

PKIaaS verlagert die Operationen der Stamm- und Ausstellungszertifizierungsstelle, das HSM-Management und den gesamten Zertifikatslebenszyklus auf eine verwaltete Cloud-Plattform. Dadurch kann ein Unternehmen die Kapitalkosten und den Personalaufwand einer selbstverwalteten PKI gegen ein Abonnement eintauschen, das automatisch skaliert und mit den immer kürzer werdenden Gültigkeitsdauern der Zertifikate Schritt hält.

Warum ist PKI-as-a-Service speziell für PKI-Teams in Unternehmen relevant?

Enterprise-PKI-Teams authentifizieren jeden Server, jedes Gerät und jeden Dienst im Netzwerk. Da die Gültigkeit öffentlicher TLS-Zertifikate bis 2029 von 398 auf 47 Tage sinkt, ist die manuelle Ausstellung und Erneuerung für Unternehmen dieser Größenordnung nicht mehr praktikabel. PKIaaS bietet diesen Teams automatisierte Registrierungsprotokolle (ACME, SCEP, EST), sodass das Zertifikatsvolumen ohne zusätzliches Personal wachsen kann.

Welche Risiken erhöhen sich, wenn PKI manuell anstatt über PKIaaS verwaltet wird?

Die manuelle PKI-Verwaltung erhöht das Risiko von Ausfällen durch abgelaufene Zertifikate, wie beispielsweise dem 91-minütigen CHAPS-Ausfall der Bank of England, übersehenen Verlängerungen in Tabellenkalkulationen, inkonsistentem Schlüsselschutz außerhalb FIPS-validierter HSMs und verzögerter Sperrung nach einem Sicherheitsvorfall. Laut einer Studie von CyberArk aus dem Jahr 2025 sind solche Risiken bereits heute für die Mehrheit der Unternehmen relevant.

Welche Teams sollten für die Einführung und den laufenden Betrieb von PKI-as-a-Service verantwortlich sein?

Die Teams für Sicherheitsarchitektur und Identitäts-/PKI-Management sollten für die Gestaltung der Zertifizierungsstellenhierarchie und die Richtlinienentscheidungen verantwortlich sein, während die IT-Betriebs- oder Plattformentwicklungsteams typischerweise die tägliche Registrierungsintegration über Intune, DevOps-Pipelines und Netzwerkgeräte hinweg verantworten. Compliance-Teams benötigen Einblick in die Audit-Protokollierung und die Bedingungen für die Schlüsselverwaltung, da die HSM- und regulatorischen Anforderungen letztendlich in ihrer Verantwortung liegen.

Wie ist PKIaaS mit dem Zertifikatslebenszyklusmanagement (CLM) verbunden?

PKIaaS bildet die Infrastrukturschicht, bestehend aus den Root- und ausstellenden Zertifizierungsstellen (CAs), während das Zertifikatslebenszyklusmanagement (CLM) die operative Schicht darstellt, die Ausstellung, Verlängerung, Widerruf und Ablauf jedes einzelnen von der CA ausgestellten Zertifikats verfolgt. Die Kombination einer PKIaaS-Implementierung mit einer CLM-Plattform wie CertSecure Manager ermöglicht vollständige Transparenz von der CA bis hin zu einzelnen Zertifikaten – eine Transparenz, die mit manueller Nachverfolgung in diesem Umfang nicht erreicht werden kann.

Wie sollten Organisationen den Erfolg einer PKIaaS-Implementierung messen?

Erfassen Sie die Anzahl der zertifikatsbedingten Ausfälle (Ziel: null), die durchschnittliche Zeit von der CSR-Einreichung bis zur Zertifikatsausstellung, den Anteil der über automatisierte Protokolle ausgestellten Zertifikate im Vergleich zu manuellen Anträgen, die Ergebnisse von HSM- und CA-Audits pro Zyklus sowie die Einhaltung der vom CA/Browser-Forum festgelegten, sich verkürzenden Gültigkeitsdauern ohne manuelle Eingriffe. Ein Rückgang ungeplanter Verlängerungsereignisse ist das deutlichste Erfolgssignal.

Was sollte in einer PKIaaS-Umgebung regelmäßig geprüft oder überwacht werden?

Prüfen Sie die Verwahrung von CA-Privatschlüsseln und HSM-Zugriffsprotokolle, Zertifikatsausstellungs- und -widerrufsprotokolle, die Verfügbarkeit von CRL/OCSP-Respondern, Authentifizierungsereignisse des Registrierungsprotokolls (ACME-Challenge-Validierung, SCEP Shared Secrets, EST Mutual TLS) sowie die Konformität mit ISO/IEC 27001, HIPAA, PCI-DSS oder DSGVO, je nachdem, welche für Ihr Unternehmen gelten.

Wie wirkt sich PKIaaS auf Cloud-, Hybrid- oder Multi-CA-PKI-Umgebungen aus?

PKIaaS ist von Grund auf für den Betrieb in Cloud-, Hybrid- und Multi-CA-Umgebungen konzipiert. Das Certificate Authority Gateway leitet Anfragen über einen sicheren Proxy an die jeweils zuständige Managed CA weiter. Dadurch erhält eine Organisation, die mehrere CAs betreibt – beispielsweise separate CAs für interne Geräte und öffentliches TLS – eine einzige automatisierte Registrierungsebene, anstatt den Erneuerungsprozess jeder CA einzeln verwalten zu müssen.

Welche häufigen Fehler sollten Teams bei der Einführung von PKI-as-a-Service vermeiden?

Die häufigsten Fehler sind, PKIaaS als bloße Übertragung bestehender manueller Prozesse zu betrachten, anstatt es auf Automatisierung auszurichten, vor Vertragsabschluss nicht genau zu prüfen, wo der Anbieter private Schlüssel generiert und speichert, die Validierungsanforderungen von FIPS 140-3 für HSMs zu ignorieren und im Falle eines Ausfalls nicht auf eine redundante ausstellende Zertifizierungsstelle zu testen.

Was sollte in einem PKI-as-a-Service-Programm vierteljährlich aktualisiert werden?

Überprüfen Sie die CA-Zertifikatsprofile und Gültigkeitszeiträume anhand des aktuellen CA/Browser Forum-Zeitplans, überprüfen Sie den HSM-FIPS-Zertifizierungsstatus erneut, insbesondere da FIPS 140-2-Zertifikate am 21. September 2026 in den historischen Status wechseln, aktualisieren Sie das Inventar der verwendeten Registrierungsprotokolle pro Gerätetyp und bestätigen Sie die SLA- und Sicherheitskontrollverpflichtungen mit Ihrem PKIaaS-Anbieter erneut.