SSL-Zertifikate Laufzeit: Was jetzt gilt und was zu beachten ist

Die maximale Laufzeit öffentlich vertrauenswürdiger SSL/TLS-Zertifikate wird schrittweise deutlich verkürzt. Seit dem 15. März 2026 dürfen neu ausgestellte Zertifikate höchstens 200 Tage gültig sein. Am 15. März 2027 sinkt die maximale Gültigkeitsdauer auf 100 Tage und am 15. März 2029 schlussendlich auf 47 Tage.

Für Unternehmen bedeutet diese Entwicklung, dass Zertifikate wesentlich häufiger validiert, ausgestellt, installiert und kontrolliert werden müssen. Was bei einzelnen Websites noch manuell beherrschbar erscheinen mag, kann in größeren oder heterogenen IT-Umgebungen schnell zu einem erheblichen Betriebsrisiko werden. Nicht rechtzeitig erneuerte oder fehlerhaft installierte Zertifikate können Websites, Anwendungen, Schnittstellen und weitere digitale Dienste unerreichbar machen.

Die verkürzten Laufzeiten betreffen jedoch nicht pauschal jede Art von digitalem Zertifikat. Der vom CA/Browser Forum beschlossene Stufenplan gilt für öffentlich vertrauenswürdige TLS-Serverzertifikate. Unternehmen sollten deshalb zunächst prüfen, welche Zertifikate in ihrer Infrastruktur betroffen sind und wie zuverlässig die zugehörigen Erneuerungsprozesse funktionieren.

Das Wichtigste in Kürze:

• Seit dem 15. März 2026 beträgt die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Serverzertifikate 200 Tage.
• Ab dem 15. März 2027 sinkt die Höchstlaufzeit auf 100 Tage, ab dem 15. März 2029 auf 47 Tage.
• Neben den Zertifikatslaufzeiten werden auch die Zeiträume verkürzt, in denen bereits erhobene Validierungsdaten wiederverwendet werden dürfen.
• Eine automatisierte Zertifikatsverwaltung ist keine formale Vorgabe des CA/Browser Forums, wird für Unternehmen mit mehreren Zertifikaten aber zunehmend wichtig.

Hinweis: Technisch kommt heute nur noch das modernere Transport Layer Security Protocol, kurz TLS, zum Einsatz. Der Begriff „SSL-Zertifikat“ hat sich dennoch als geläufige Bezeichnung etabliert und wird hier auch so verwendet.

Wie lange sind SSL-Zertifikate aktuell gültig?

Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige SSL-Zertifikate mit einer maximalen Laufzeit von 200 Tagen ausgestellt werden. Die zuvor geltende Obergrenze von 398 Tagen ist damit für neue Zertifikate nicht mehr zulässig.

Maßgeblich ist grundsätzlich der Zeitpunkt, zu dem ein Zertifikat ausgestellt wird. Nicht das Bestelldatum, die Laufzeit eines Vertrags oder der Zeitpunkt der Beantragung entscheiden darüber, welche maximale Gültigkeitsdauer möglich ist. Wird ein Zertifikat nach dem jeweiligen Stichtag ausgestellt, muss es die dann geltende Obergrenze einhalten.

Die Vorgaben des CA/Browser Forums bilden lediglich die branchenweit zulässige Höchstgrenze. Zertifizierungsstellen können ihre Produkte früher umstellen oder eine kürzere Laufzeit festlegen. DigiCert stellt öffentliche TLS-Zertifikate beispielsweise seit dem 24. Februar 2026 mit einer maximalen Gültigkeit von 199 Tagen aus. Bei D-Trust beträgt die maximale Laufzeit entsprechender Zertifikate 198 Tage. Diese produktspezifischen Grenzen liegen unter der branchenweiten Obergrenze und reduzieren das Risiko, dass die zulässigen 200 Tage durch unterschiedliche Zeitberechnungen überschritten werden.

Nicht automatisch von dem beschlossenen Stufenplan betroffen sind dagegen:

• Zertifikate aus einer privaten Unternehmens-PKI, die nicht öffentlich vertrauenswürdig sein müssen,
• S/MIME-Zertifikate zur Absicherung von E-Mails,
• Code-Signing-Zertifikate zur Signierung von Software,
• Client-Zertifikate zur Authentifizierung von Personen oder Systemen sowie
• interne Geräte- und Maschinenzertifikate.

Für diese Zertifikatsarten gelten eigene technische, organisatorische oder branchenspezifische Vorgaben. Entscheidend ist daher nicht allein die Bezeichnung „SSL-Zertifikat“, sondern welchem Zweck ein Zertifikat dient, wer es ausgestellt hat und in welchem Vertrauensmodell es eingesetzt wird.

Was für bereits ausgestellte Zertifikate gilt

Bereits ausgestellte Zertifikate werden durch einen neuen Stichtag nicht automatisch ungültig. Wurde ein Zertifikat vor der Umstellung regelkonform mit einer längeren Laufzeit ausgestellt, kann es grundsätzlich bis zu seinem eingetragenen Ablaufdatum weiterverwendet werden. Eine vorsorgliche Ersetzung allein aufgrund der neuen Laufzeitgrenze ist daher in der Regel nicht erforderlich.

Anders sieht es aus, wenn ein neues Zertifikat ausgestellt wird. Bei einer regulären Erneuerung gelten die Vorgaben, die zum Zeitpunkt der Neuausstellung wirksam sind. Auch eine Neuausstellung aufgrund geänderter Domainnamen, eines neuen Schlüsselpaares oder technischer Anpassungen kann bereits unter die kürzere Laufzeit fallen.

Bei Zertifikatsanbietern können zudem Reissues oder Duplikate betroffen sein. DigiCert begrenzt beispielsweise auch nach dem 24. Februar 2026 ausgestellte Ersatz- und Duplikatzertifikate auf maximal 199 Tage. Ein bestehendes Zertifikat mit längerer Restlaufzeit lässt sich dort folglich nicht ohne Weiteres erneut mit derselben Gültigkeitsdauer ausstellen.

Der beschlossene Stufenplan für 200, 100 und 47 Tage

Die Verkürzung der Zertifikatslaufzeiten ist keine unverbindliche Planung mehr. Mit dem Ballot SC-081v3 hat das CA/Browser Forum einen verbindlichen Stufenplan beschlossen, der die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Serverzertifikate bis März 2029 auf 47 Tage reduziert.

Die Umstellung erfolgt in mehreren Schritten. Zertifizierungsstellen, Softwareanbieter und Unternehmen erhalten dadurch Zeit, ihre Systeme und Prozesse an häufigere Validierungen und Erneuerungen anzupassen.

Die Fristen im Überblick

• Bis 14. März 2026: maximal 398 Tage
  Dies war die bisherige Obergrenze für öffentlich vertrauenswürdige SSL-Zertifikate.
• 15. März 2026 bis 14. März 2027: maximal 200 Tage
  Die Erneuerungsintervalle verkürzen sich deutlich.
• 15. März 2027 bis 14. März 2029: maximal 100 Tage
  Zertifikate müssen künftig mehrmals pro Jahr erneuert und auf den Zielsystemen ausgerollt werden.
• Ab 15. März 2029: maximal 47 Tage
  Manuelle Prozesse geraten insbesondere bei größeren Zertifikatsbeständen zunehmend an ihre operativen Grenzen.

Die genannten Werte sind die maximal zulässigen Laufzeiten. Unternehmen sollten zusätzlich die konkreten Produktbedingungen und Umstellungstermine ihrer Zertifizierungsstellen beachten.

Auch Validierungsdaten dürfen kürzer wiederverwendet werden

SC-081v3 verkürzt nicht nur die Zertifikatslaufzeit. Gleichzeitig ändern sich die Zeiträume, in denen eine Zertifizierungsstelle bereits abgeschlossene Prüfungen für eine weitere Ausstellung wiederverwenden darf.

Besonders relevant ist die Domain Control Validation, kurz DCV. Dabei weist der Antragsteller nach, dass er die Kontrolle über die im Zertifikat enthaltenen Domainnamen besitzt. Auch Validierungen von IP-Adressen unterliegen den kürzeren Fristen.

• Bis 14. März 2026: maximal 398 Tage
  Domain- und IP-Validierungen durften bis zu 398 Tage wiederverwendet werden.
• 15. März 2026 bis 14. März 2027: maximal 200 Tage
  Seit dem 15. März 2026 gilt eine verkürzte Wiederverwendungsfrist von 200 Tagen.
• 15. März 2027 bis 14. März 2029: maximal 100 Tage
  Ab März 2027 sinkt die Frist auf 100 Tage.
• Ab 15. März 2029: maximal 10 Tage
  Domain- und IP-Validierungen dürfen dann nur noch zehn Tage für eine weitere Zertifikatsausstellung wiederverwendet werden.

Ab März 2029 kann eine erfolgreiche Domain- oder IP-Validierung somit nur noch für maximal zehn Tage wiederverwendet werden. Danach muss die Kontrolle über die betreffende Domain oder IP-Adresse erneut nachgewiesen werden.

Für OV- und EV-Zertifikate sind zusätzlich die geprüften Angaben zur Identität des Zertifikatsinhabers relevant. Diese sogenannten Subject Identity Information umfassen beispielsweise den Namen und die Anschrift einer Organisation. Seit dem 15. März 2026 dürfen solche Identitätsdaten nur noch für maximal 398 statt zuvor 825 Tage wiederverwendet werden.

Unternehmen müssen künftig daher nicht nur die Ablaufdaten ihrer Zertifikate überwachen. Ebenso relevant sind die Fristen der Domain-, IP- und gegebenenfalls Organisationsvalidierung. Ist eine erforderliche Prüfung abgelaufen, kann sich die Neuausstellung verzögern, obwohl der eigentliche Erneuerungsprozess rechtzeitig begonnen wurde.

SSL-Zertifikate und ihre Laufzeit im Wandel

Die Höchstlaufzeit von 47 Tagen wirkt auf den ersten Blick wie ein besonders großer Einschnitt. Tatsächlich ist sie jedoch der vorläufige Endpunkt einer Entwicklung, die bereits seit mehr als einem Jahrzehnt anhält. Die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate wurde schrittweise von bis zu fünf Jahren auf wenige Wochen reduziert.

2025: Abstimmung macht den Weg zu 47 Tagen verbindlich

Am 11. April 2025 endete die Abstimmung über den Ballot SC-081v3. Mit seiner Annahme wurde aus den vorherigen Diskussionen ein verbindlicher Stufenplan. Anders als frühere Ankündigungen enthält er nicht nur ein langfristiges Ziel, sondern konkrete Stichtage für die Zertifikatslaufzeit und die Wiederverwendung von Validierungsdaten.

2024: Apple schlägt zunächst 45 Tage vor

Dem finalen Beschluss ging ein Vorschlag von Apple voraus. Das Unternehmen brachte einen Entwurf in die Diskussion ein, der eine schrittweise Verkürzung auf zunächst 200, dann 100 und schließlich 45 Tage vorsah.

Im weiteren Verfahren wurden sowohl die Termine als auch die endgültige Laufzeit angepasst. Aus den ursprünglich vorgeschlagenen 45 Tagen wurden die heute beschlossenen 47 Tage. Der Apple-Vorschlag ist damit als wichtige Zwischenstufe und nicht als aktuell geltende Regelung einzuordnen.

2023: Google bringt 90-Tage-Zertifikate in die Diskussion

Im März 2023 schlug das Chrome Root Program im Rahmen der Initiative „Moving Forward, Together“ vor, die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Serverzertifikate von 398 auf 90 Tage zu reduzieren.

Dabei handelte es sich nicht um eine verbindliche Richtlinie, sondern um einen Vorschlag für eine spätere Policy-Änderung oder einen Ballot im CA/Browser Forum. Die 90-Tage-Grenze wurde letztlich nicht als eigene Laufzeitstufe umgesetzt. Stattdessen beschloss das CA/Browser Forum später den Stufenplan mit einer abschließenden Höchstlaufzeit von 47 Tagen.

2020: Apple setzt eine Höchstlaufzeit von 398 Tagen durch

Die vorangegangene große Verkürzung erfolgte zum 1. September 2020. Seit diesem Datum akzeptieren Apple-Systeme neu ausgestellte TLS-Serverzertifikate aus öffentlich vertrauenswürdigen Root-CAs nur noch mit einer Laufzeit von höchstens 398 Tagen.

Ein gemeinsamer Vorschlag zur Verkürzung auf ungefähr 13 Monate hatte zuvor im CA/Browser Forum nicht die erforderliche Zustimmung erhalten. Apple setzte die Begrenzung anschließend über die Anforderungen des eigenen Root-Programms durch. Die 398-Tage-Grenze blieb bis März 2026 der maßgebliche Branchenstandard.

2018: Aus 39 Monaten werden 825 Tage

Die vorherige Grenze von 825 Tagen, ungefähr 27 Monaten, geht auf den Ballot 193 des CA/Browser Forums zurück. Der Ballot wurde 2017 angenommen und trat am 1. März 2018 in Kraft.

2012 bis 2015: Als Zertifikate noch bis zu fünf Jahre gültig waren

Mit der Einführung der Baseline Requirements wurde die maximale Laufzeit öffentlich vertrauenswürdiger Zertifikate zunächst auf 60 Monate begrenzt. Gleichzeitig war bereits eine spätere Reduzierung vorgesehen. Seit April 2015 durften neu ausgestellte Zertifikate grundsätzlich höchstens 39 Monate gültig sein.

In etwas mehr als einem Jahrzehnt hat sich die maximale Zertifikatslaufzeit damit von 60 Monaten über 39 Monate, 825 Tage und 398 Tage bis zum heutigen Stufenplan mit 200, 100 und schließlich 47 Tagen entwickelt.

Warum werden die Laufzeiten von SSL-Zertifikaten verkürzt?

Die kürzeren Laufzeiten sollen die Sicherheit und Verlässlichkeit der Web-PKI verbessern. Ein Zertifikat bestätigt bestimmte Informationen zu dem Zeitpunkt, an dem es ausgestellt wird. Dazu gehören die Kontrolle über die enthaltenen Domains und – bei OV- und EV-Zertifikaten – Angaben zur Identität einer Organisation.

Eine kürzere Laufzeit verhindert weder den Diebstahl eines privaten Schlüssels noch die fehlerhafte Ausstellung eines Zertifikats. Sie begrenzt jedoch den Zeitraum, in dem ein betroffenes oder nicht mehr aktuelles Zertifikat ohne erneute Prüfung gültig bleiben kann.

Aktuellere Domain- und Identitätsinformationen

Ein TLS-Zertifikat bildet immer nur eine Momentaufnahme ab. Domains können den Inhaber wechseln, Unternehmen können umfirmieren und technische Zuständigkeiten können sich verändern. Je länger Zertifikate und Validierungsdaten wiederverwendet werden dürfen, desto länger können Angaben gültig erscheinen, die nicht mehr der aktuellen Situation entsprechen.

Durch kürzere Laufzeiten und häufigere Validierungen soll die Zeitspanne zwischen der Prüfung und der tatsächlichen Verwendung eines Zertifikats reduziert werden.

Kleineres Risikofenster bei kompromittierten Schlüsseln

Gerät ein privater Schlüssel in die Hände Unbefugter, kann das zugehörige Zertifikat unter bestimmten Voraussetzungen missbraucht werden. Kürzere Laufzeiten beheben eine solche Kompromittierung nicht, begrenzen aber den maximalen Zeitraum, in dem das Zertifikat ohne Erneuerung gültig bleiben kann.

Sperrmechanismen wie Certificate Revocation Lists und das Online Certificate Status Protocol bleiben weiterhin notwendig. Sie gewährleisten jedoch nicht in jeder Situation eine vollständige und sofort wirksame Absicherung. Kürzere Laufzeiten ergänzen diese reaktiven Verfahren daher um eine feste zeitliche Begrenzung.

Schnellere Reaktion auf Schwachstellen und neue Verfahren

Die Web-PKI muss auf neu entdeckte Schwachstellen, unsichere Verfahren und geänderte technische Anforderungen reagieren können. Bei langen Laufzeiten bleiben ältere kryptografische Verfahren entsprechend länger im Umlauf.

Kürzere Laufzeiten erleichtern den Wechsel, weil neue Vorgaben schneller in reguläre Erneuerungsprozesse einfließen können. Diese Fähigkeit wird als Krypto-Agilität bezeichnet. Langfristig spielt sie auch bei der Vorbereitung auf Post-Quanten-Kryptografie eine Rolle. Der Übergang zu quantenresistenten Verfahren ist jedoch nicht der alleinige oder unmittelbare Grund für den aktuellen Stufenplan.

Mehr Automatisierung als begleitender Effekt

Der beschlossene Stufenplan fördert zugleich die Entwicklung zuverlässiger Prozesse für Ausstellung, Erneuerung und Austausch. Bei Laufzeiten von 47 Tagen sind rein manuelle Abläufe insbesondere in größeren Zertifikatsumgebungen kaum noch wirtschaftlich und mit einem erhöhten Fehlerrisiko verbunden.

Automatisierung ist dennoch keine formale Vorgabe für Websitebetreiber. Sie ist vielmehr eine praktische Konsequenz aus den häufigeren Zertifikatswechseln. Dabei gilt: Ein fehlerhafter automatisierter Prozess kann Zertifikate ebenso falsch verteilen oder unbemerkt ablaufen lassen wie ein manueller Prozess. Erst das Zusammenspiel aus Automatisierung, Monitoring und klaren Verantwortlichkeiten sorgt für einen verlässlichen Betrieb.

Was kürzere Zertifikatslaufzeiten für Unternehmen bedeuten

Mit der Verkürzung steigt die Zahl der erforderlichen Erneuerungen deutlich. Die Herausforderung liegt dabei nicht allein in der Beantragung. Zu jedem Vorgang gehören weitere Schritte: Domains müssen gegebenenfalls erneut validiert, Zertifikate ausgestellt, auf den vorgesehenen Systemen installiert und anschließend auf ihre korrekte Funktion geprüft werden.

Mehr Erneuerungen und Revalidierungen

Bei einer maximalen Gültigkeit von 47 Tagen kann ein Zertifikat rechnerisch mehr als siebenmal pro Jahr erneuert werden müssen. Erfolgt die Erneuerung mit ausreichendem zeitlichem Puffer, können in der Praxis noch häufigere Vorgänge erforderlich sein.

Die Verkürzung der Domainvalidierung auf zehn Tage führt zudem dazu, dass die Kontrolle über eine Domain vor vielen Neuausstellungen erneut nachgewiesen werden muss. Das kann zusätzliche Abstimmungen auslösen, wenn DNS-Einträge, Webserver oder E-Mail-Postfächer von unterschiedlichen Teams oder Dienstleistern verwaltet werden.

Höheres Ausfallrisiko bei manuellen Prozessen

Mit jedem zusätzlichen Vorgang steigt die Zahl der Gelegenheiten, bei denen Fehler auftreten können. Typische Ursachen sind:

• Ein Zertifikat wird zu spät beantragt oder erneuert.
• Das neue Zertifikat wird ausgestellt, aber nicht rechtzeitig installiert.
• Die Installation erfolgt nur auf einem Teil der Server, Loadbalancer oder Appliances.
• Ein falsches Zertifikat oder eine unvollständige Zertifikatskette wird eingebunden.
• Der betroffene Dienst verwendet nach dem Austausch weiterhin das alte Zertifikat.
• Ein System oder eine Subdomain fehlt im Zertifikatsinventar.

Die möglichen Folgen reichen von Browserwarnungen bis zu nicht erreichbaren Websites, Webshops, APIs und internen Anwendungen. Weitere Maßnahmen zur Vermeidung solcher Störungen erläutern wir im Beitrag über abgelaufene Zertifikate und zertifikatsbedingte Ausfälle.

Mehr Anforderungen an Verantwortlichkeiten und Kontrolle

Für jedes Zertifikat sollte eindeutig festgelegt sein, welches Team oder welche Person für Beantragung, Validierung, Installation und Überwachung verantwortlich ist. In der Praxis verteilen sich diese Aufgaben häufig auf Security, Einkauf, Administration, Fachabteilungen und externe Dienstleister.

Neben dem Ablaufdatum sollten mindestens die ausstellende Zertifizierungsstelle, die enthaltenen Domains, der Installationsort, das Validierungsverfahren und der Eskalationsweg bei Fehlern dokumentiert werden.

Auch automatisierte Abläufe müssen kontrolliert werden. Eine erfolgreiche Ausstellung bedeutet noch nicht, dass das Zertifikat auf allen vorgesehenen Systemen installiert wurde und dort fehlerfrei funktioniert.

So bereiten sich Unternehmen auf 100- und 47-Tage-Zertifikate vor

Mit den kürzeren Laufzeiten steigt nicht nur die Zahl der Erneuerungen. Auch Domainvalidierungen, Installationen und technische Kontrollen müssen häufiger durchgeführt werden. Unternehmen sollten deshalb frühzeitig prüfen, an welchen Stellen ihre Zertifikatsverwaltung noch von manuellen Abläufen oder einzelnen Personen abhängt.

Zertifikatsbestand und Verantwortlichkeiten erfassen

Grundlage einer zuverlässigen Verwaltung ist ein vollständiger Überblick. Dazu gehören nicht nur Zertifikate auf klassischen Webservern, sondern auch auf Loadbalancern, Reverse-Proxys, Firewalls, Appliances, Cloud-Diensten und Schnittstellen.

Für jedes Zertifikat sollten mindestens der Einsatzort, die Zertifizierungsstelle, das Ablaufdatum, das Validierungsverfahren und das verantwortliche Team dokumentiert sein. Nur bekannte Zertifikate lassen sich zuverlässig überwachen und automatisieren.

Ausstellung und Erneuerung automatisieren

Das ACME-Protokoll kann wiederkehrende Vorgänge wie Domainvalidierung, Ausstellung und Erneuerung automatisieren. Entscheidend ist jedoch, den Prozess nicht mit dem Abruf eines neuen Zertifikats enden zu lassen. Auch Installation, Verteilung und erfolgreiche Aktivierung auf den Zielsystemen müssen berücksichtigt werden.

Für standardisierte Webserver-Umgebungen können ACME-Zertifikate einen geeigneten Einstieg in die Automatisierung bieten.

In komplexen oder heterogenen Infrastrukturen kann ein Certificate Lifecycle Management, kurz CLM, zusätzlich für zentrale Transparenz und Steuerung sorgen. Eine CLM-Lösung kann Zertifikate inventarisieren, Richtlinien durchsetzen, Erneuerungen orchestrieren und Fehler zentral melden.

ACME und CLM sind dabei keine Gegensätze: ACME kann als technisches Automatisierungsprotokoll innerhalb eines übergeordneten Lifecycle-Managements eingesetzt werden. Bei großen, verteilten Zertifikatslandschaften können zentrale Managed-PKI- und CLM-Lösungen zusätzlich bei Orchestrierung, Monitoring und Richtlinienverwaltung unterstützen.

Monitoring und Notfallprozesse einrichten

Auch automatisierte Erneuerungen können fehlschlagen. Unternehmen sollten deshalb überwachen, ob eine Validierung erfolgreich abgeschlossen, das neue Zertifikat ausgestellt, auf allen vorgesehenen Systemen installiert und anschließend tatsächlich verwendet wird.

Für Fehlerfälle braucht es klare Warnschwellen, Eskalationswege und einen getesteten Ersatzprozess. Je kürzer die Zertifikatslaufzeiten werden, desto weniger Zeit bleibt, fehlgeschlagene Erneuerungen manuell zu korrigieren.

Anbieterabhängige Laufzeiten berücksichtigen

Die Vorgaben des CA/Browser Forums legen lediglich die maximal zulässige Laufzeit fest. Zertifizierungsstellen können ihre Produkte früher umstellen oder zusätzliche zeitliche Puffer einplanen. Verantwortliche sollten deshalb regelmäßig prüfen, welche Laufzeiten, Reissue-Regeln und Validierungsfristen für die konkret eingesetzten Zertifikate gelten.

Kürzere Laufzeiten verlangen verlässliche Prozesse

Die schrittweise Verkürzung der Laufzeit öffentlich vertrauenswürdiger TLS/SSL-Zertifikate auf 200, 100 und schließlich 47 Tage verändert den Zertifikatsbetrieb grundlegend. Unternehmen müssen Zertifikate künftig häufiger validieren, ausstellen, installieren und kontrollieren.

Die größte Herausforderung liegt dabei weniger in der kürzeren Laufzeit selbst als in unvollständigen Beständen, manuellen Abläufen und unklaren Zuständigkeiten. Wer nicht zuverlässig weiß, welche Zertifikate vorhanden sind und wo sie eingesetzt werden, kann auch ihre Erneuerung nicht sicher automatisieren.

Unternehmen sollten deshalb jetzt ihre Zertifikatslandschaft erfassen, Verantwortlichkeiten klären und prüfen, welche Prozesse sich mit ACME oder einem zentralen Certificate Lifecycle Management automatisieren lassen. Ebenso wichtig sind Monitoring, Eskalationswege und getestete Notfallverfahren.

Die 47-Tage-Regel ist keine formale Verpflichtung zur Automatisierung. Für größere und komplexere Zertifikatsbestände wird eine überwiegend manuelle Verwaltung jedoch zunehmend aufwendig und riskant. Wer die notwendigen Prozesse frühzeitig aufbaut, kann die kommenden Laufzeitstufen kontrolliert umsetzen und das Risiko zertifikatsbedingter Ausfälle deutlich reduzieren. Wenn Sie Ihre Zertifikatsverwaltung auf kürzere Laufzeiten vorbereiten und bestehende Automatisierungspotenziale prüfen möchten, können Sie einen Beratungstermin mit unseren Experten vereinbaren.

 

Beitrag vom 4. Februar 2026 | Letztes Update am 28. Juli 2026