Änderungen im PKI-Ökosystem 2026: Was Ihr Team wissen muss

• Apple erzwingt ab Ende März 2026 Zertifikatslaufzeiten von 200 Tagen, und Amazon stellt bereits Zertifikate mit 198 Tagen Laufzeit aus. Bis 2029 sinken die Laufzeiten auf 47 Tage.
• 81% der zertifikatsbedingten Ausfälle gehen weiterhin auf abgelaufene oder falsch konfigurierte Zertifikate zurück. Kürzere Laufzeiten vervielfachen dieses Risiko.
• 60% der Unternehmen betreiben eigene interne Zertifizierungsstellen (CAs), und ein durchschnittliches Großunternehmen nutzt mehr als 140.000 interne Zertifikate. Die meisten haben kaum zentrale Kontrolle darüber.
• Die „Harvest Now, Decrypt Later“-Bedrohung durch Quantencomputer bedeutet, dass Unternehmen jetzt hybrides TLS einsetzen sollten (klassisches ECDHE kombiniert mit ML-KEM).
• Unternehmen brauchen ein Echtzeit-Zertifikatsinventar aus mehreren Quellen, das öffentliche und private Infrastruktur abdeckt, um mit diesen Änderungen Schritt zu halten.

Die Änderungen sind bereits da. Apple erzwingt ab Ende März 2026 eine maximale Zertifikatslaufzeit von 200 Tagen. Auch Amazon stellt inzwischen Zertifikate mit 198 Tagen Laufzeit aus. Wenn Sie Zertifikate dieser Anbieter im Bestand haben, wird sich die Zahl der Zertifikate in Ihrer Umgebung in diesem Jahr mindestens verdoppeln.

Und das ist erst der Anfang. 2027 sinken die Laufzeiten auf 100 Tage. 2029 sind es nur noch 47.

Die entscheidende Rechnung: Eine Laufzeit von 47 Tagen bedeutet etwa achtmal so viele Zertifikatserneuerungen pro Jahr wie heute. Wenn Sie derzeit 1.000 öffentliche Zertifikate betreiben, verwalten Sie 2029 jährlich 8.000 Erneuerungen.

Bei diesem Volumen ist manuelle Zertifikatserneuerung unmöglich. Aber wie Billy McDiarmid im Webinar betonte, reicht Automatisierung allein ebenfalls nicht.

„Wir sprechen jeden Tag mit Kunden darüber“, sagte McDiarmid. „Sie kommen zu uns und sagen, sie hätten gedacht, alles sei automatisiert. Dann ist die Automatisierung in einem Teil ihres Bestands ausgefallen, oder ein Zertifikat eines Drittanbieters, von dem einer ihrer Services abhing, ist abgelaufen.“

Auch das Zeitfenster für den Austausch schrumpft. Bisher galt es als Best Practice, 30 Tage vor Ablauf mit der Rotation zu beginnen. Bei kürzeren Laufzeiten bleiben Ihnen vielleicht nur noch sieben Tage. Damit bleibt dramatisch weniger Zeit, um eine fehlgeschlagene Automatisierung zu bemerken und zu beheben.

Und es steht viel auf dem Spiel: 81% der zertifikatsbedingten Ausfälle gehen weiterhin auf abgelaufene oder falsch konfigurierte Zertifikate zurück. Das ist schon jetzt eine der größten Ursachen für Downtime. Kürzere Laufzeiten verschärfen das ohne die richtigen Tools noch.

Öffentliche PKI (die Zertifikate, die Ihre Website, öffentliche APIs und externe Domains absichern) bekommt die meiste Aufmerksamkeit. Es gibt ein etabliertes Ökosystem aus CAs, Browser-Durchsetzung, Certificate-Transparency-Logs (CT-Logs) und Compliance-Anforderungen, das die öffentliche PKI vergleichsweise gut unter Kontrolle hält.

Bei der privaten PKI sieht das anders aus.

Interne Zertifikate, die Ihre Server, VPNs, DevOps-Pipelines, IoT-Geräte und internen APIs absichern, stammen oft von internen privaten CAs wie den Microsoft Active Directory Certificate Services (ADCS) und werden kaum zentral kontrolliert. Die Laufzeiten betragen häufig Jahre, manchmal sogar Jahrzehnte. Externes Monitoring gibt es in der Regel nicht. Und wenn etwas schiefgeht (ein unerwarteter Ablauf, ein kompromittiertes Root-Zertifikat, ein falsch konfiguriertes Intermediate), können die Folgen gravierend und schwer zu diagnostizieren sein.

Die Zahlen sprechen für sich. 60% der Unternehmen betreiben eigene interne CAs. Ein großes Unternehmen nutzt im Schnitt mehr als 140.000 interne Zertifikate. Und 57% der Organisationen integrieren inzwischen Zero Trust in ihre Verschlüsselungsstrategie, wodurch die private PKI noch zentraler für ihren Betrieb wird.

Zero Trust folgt einem einfachen Prinzip: Niemals vertrauen, immer überprüfen. Jeder Service erhält ein eigenes Zertifikat. Jede Verbindung nutzt Mutual TLS (mTLS), das heißt, beide Seiten müssen ein gültiges, von einer vertrauenswürdigen CA signiertes Zertifikat vorlegen. Der Zugriff folgt Richtlinien, nicht dem Standort.

Die private PKI macht all das im großen Maßstab möglich. Sie gibt jedem Service, jedem Gerät und jedem Nutzer eine starke kryptografische Identität. Weil Zero Trust aber kurzlebige, automatisch rotierte Zertifikate bevorzugt, nehmen Volumen und Tempo der Zertifikatsvorgänge weiter zu.

Und die Folgen eines Ausfalls der privaten PKI gehen weit über eine nicht erreichbare Website hinaus. Wenn private Zertifikate ablaufen oder ausfallen, kann das Fertigungslinien, Systeme der Betriebstechnik (OT) und interne Services lahmlegen, auf die Ihr Geschäft angewiesen ist. McDiarmid brachte es so auf den Punkt: „Wir reden nicht mehr nur davon, dass Ihre Website down ist oder Ihre API nicht antwortet. Wir reden davon, dass keine Produkte mehr gefertigt werden.“

Die Vorbereitung auf Post-Quanten-Kryptografie (PQC) wirkt wie ein Zukunftsproblem. Die regulatorischen Fristen für die vollständige Migration liegen etwa zwischen 2030 und 2033. Doch der Vorbereitungsaufwand ist erheblich, und eine Bedrohung verlangt schon jetzt Handeln.

Sobald ein kryptografisch relevanter Quantencomputer (CRQC) gebaut ist, wird er die heute weit verbreitete Public-Key-Kryptografie, darunter RSA und Elliptic Curve Cryptography (ECC), im Grunde über Nacht brechen.

Die unmittelbare Sorge heißt „Harvest Now, Decrypt Later“. Angreifer können verschlüsselte Daten schon heute abgreifen (Ihren TLS-Verkehr, VPN-Tunnel) und speichern. Sobald ein CRQC verfügbar ist, können sie alles entschlüsseln, was sie gesammelt haben. Für Organisationen mit langlebigen sensiblen Daten ist das ein Risiko von heute, nicht von morgen.

Bhushan Lokhande von Red Sift hat drei Schritte für den Aufbau der PQC-Bereitschaft skizziert.

• Schritt eins: Kennen Sie Ihre Lage. Was Sie nicht sehen, können Sie nicht schützen. Bauen Sie ein umfassendes, stets aktuelles Inventar Ihrer kryptografischen Assets auf, das sowohl öffentlich erreichbare als auch interne private Infrastruktur abdeckt. Jede Domain, jede Subdomain, jedes Zertifikat und jeden Netzwerk-Endpunkt.
• Schritt zwei: Finden Sie Ihre Schwachstellen. Welche Systeme nutzen Algorithmen, die Quantencomputer brechen werden? Dazu müssen Sie alle RSA- und ECC-Implementierungen finden. Außerdem suchen Sie nach Systemen ohne Krypto-Agilität (Systeme, die sich nicht ohne erheblichen Umbau auf neue Algorithmen umstellen lassen).
• Schritt drei: Planen Sie die Migration. Nicht alles muss auf einmal umziehen. Priorisieren Sie langlebige Daten und Hochrisikosysteme, denn sie tragen die größte „Harvest Now, Decrypt Later“-Exposition.

Die Migration besteht aus zwei getrennten Teilen. Beim Schlüsselaustausch ist die dringendste Maßnahme, hybrides TLS einzusetzen und klassisches ECDHE mit ML-KEM (früher bekannt als Kyber) zu kombinieren. Das adressiert direkt das „Harvest Now, Decrypt Later“-Risiko und bleibt abwärtskompatibel. Cloudflare, Google und die großen Browser-Hersteller setzen hybriden Schlüsselaustausch bereits im großen Maßstab ein. Bei den digitalen Signaturen sollten Organisationen NIST-standardisierte Post-Quanten-Algorithmen wie ML-DSA und SLH-DSA schrittweise einführen, sobald das Ökosystem reift.

PQC-Bereitschaft ist kein einmaliges Ereignis. Es ist ein Migrationsprozess, und Sie sollten sofort damit beginnen.

Alle drei Entwicklungen führen zur selben Grundanforderung. Sie brauchen ein umfassendes, laufend aktualisiertes Inventar jedes Zertifikats in Ihrem Bestand, öffentlich und privat, im Moment der Ausstellung.

Tabellenkalkulationen reichen nicht mehr aus. Tägliche Scans ebenfalls nicht. Sie brauchen Echtzeit-Erfassung von Zertifikaten aus mehreren Erkennungsquellen: hostnamenbasierte Erkennung, Netzwerk-Scans, Certificate-Transparency-Logs, Cloud-Provider-Integrationen und Agenten in der privaten Infrastruktur.

Die meisten Organisationen unterschätzen außerdem, wie stark ihre Zertifizierungsstellen wuchern. McDiarmid berichtete im Webinar von einer aufschlussreichen Beobachtung: Bei den meisten Interessenten, die Red Sift onboardet, tauchen Zertifikate von 10 oder 11 verschiedenen Zertifizierungsstellen auf, dazu selbstsignierte Zertifikate, und das ist nur der öffentliche Fußabdruck, bevor jemand ins Netzwerk schaut.

Außerdem brauchen Sie Einblick in Ihre kryptografische Lage: welche Endpunkte PQ-sicheren Schlüsselaustausch unterstützen, welche Zertifikate quantenanfällige Algorithmen nutzen und wo Ihr Bestand im Hinblick auf die kommenden Änderungen bei den Laufzeiten steht.

Ein CLM-Tool (Certificate Lifecycle Management) übernimmt Ausstellung und Erneuerung. Aber 2026 brauchen Sie zusätzlich eine Versicherung neben Ihrem CLM: etwas, das in Minuten einsatzbereit ist, kontinuierlich in Echtzeit erkennt, Zertifikatsdaten mit CT-Logs und DNS abgleicht und beide Seiten des Netzwerks abdeckt.

Red Sift Certificates überwacht öffentliche und private Infrastruktur in einer einzigen Ansicht, mit eigenen Dashboards für PQC-Bereitschaft und Compliance im Zertifikatslebenszyklus. Der Agent für private PKI der Plattform erkennt Zertifikate in der internen Infrastruktur und führt sie im selben Inventar zusammen wie Ihre öffentlichen Zertifikate.

Zu den neuen Funktionen, die 2026 erscheinen, gehören eine ADCS-Integration (kommt im 2. Quartal), eine HashiCorp-Vault-Integration später im Jahr und MCP-Zugriff (Model Context Protocol), damit Teams ihren Zertifikatsbestand per KI abfragen können.

Möchten Sie wissen, wo Ihr Bestand steht? Prüfen Sie die Sicherheitslage Ihrer Domain mit Red Sift Radar Lite für eine kostenlose Bewertung oder fordern Sie eine Demo von Red Sift Certificates an, um vollständige Transparenz über Ihre öffentliche und private Zertifikatsinfrastruktur zu erhalten.