Die Lebensdauer von Code-Signatur-Zertifikaten wird immer kürzer

Code-Signaturzertifikate authentifizieren Software, bevor sie Endnutzer erreicht. Sie bestätigen, dass eine Binärdatei, ein Installationsprogramm oder ein Update von einem verifizierten Herausgeber stammt und während der Übertragung nicht verändert wurde. Jahrelang war das Betriebsmodell für diese Zertifikate einfach: Man besorgte sich ein Zertifikat mit mehrjähriger Gültigkeit, speicherte es in der Entwicklungsumgebung und verlängerte es, sobald die Ablaufbenachrichtigung erschien. Dieses Modell barg ein stilles, aber reales Risiko, denn ein 39 Monate gültiges Zertifikat bedeutet, dass ein kompromittierter privater Schlüssel für diesen gesamten Zeitraum als vertrauenswürdig gilt, sofern er nicht rechtzeitig entdeckt und widerrufen wird.

Gemäß der CA/Browser Forum-Abstimmung CSC-31 vom 17. November 2025, die in die Code Signing Baseline Requirements Version 3.10.0 aufgenommen wurde, verkürzte sich die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger Codesignaturzertifikate von 39 Monaten auf 460 Tage, also etwa 15 Monate. Alle ab dem 1. März 2026 ausgestellten Codesignaturzertifikate müssen diese Beschränkung einhalten. Zertifikate, die vor diesem Datum ausgestellt wurden, bleiben bis zu ihrem regulären Ablaufdatum gültig; bei der Verlängerung gilt jedoch die neue Gültigkeitsdauer.

Dies ist kein Einzelfall. Es folgt der gleichen Entwicklung wie bei TLS-Zertifikaten , deren Gültigkeitsdauer ab dem 15. März 2026 von 398 auf 200 Tage sank und gemäß CA/B Forum Ballot SC-081v3, der im April 2025 verabschiedet wurde, am 15. März 2027 auf 100 Tage und am 15. März 2029 auf 47 Tage weiter reduziert werden soll. Codesignierung und TLS nähern sich demselben Prinzip an: Zertifikate sollten nicht länger gültig sein als die Vertrauensbedingungen, unter denen sie ausgestellt wurden. Die Branche setzt auf Automatisierung, um dies praktisch umzusetzen.

Dieser Blogbeitrag erläutert die Änderungen, die Risiken und die Punkte, die Unternehmen vor dem nächsten Erneuerungszyklus angehen müssen.

Warum die Gültigkeitsdauer von Zertifikaten immer kürzer wird

Die Tendenz zu kürzeren Zertifikatslebensdauern ist nicht willkürlich. Sie adressiert zwei Probleme, die in öffentlichen PKIs seit Langem bestehen: die Diskrepanz zwischen der Kompromittierung eines Zertifikats und dem tatsächlichen Verlust des Vertrauens, sowie die langsame Umstellung von Organisationen auf stärkere kryptografische Standards, solange ihre bestehenden Zertifikate noch einwandfrei funktionieren.

Wenn ein privater Signaturschlüssel offengelegt wird, bleibt das zugehörige Zertifikat gültig, bis es abläuft oder widerrufen wird. Der Widerruf ist mit bekannten Zuverlässigkeitsproblemen behaftet. Zertifikatssperrlisten (CRLs) und das Online Certificate Status Protocol (OCSP) werden nicht von allen Plattformen einheitlich überprüft, und wenn eine Widerrufsprüfung fehlschlägt oder ein Timeout auftritt, werten die meisten Systeme dies als bestanden und nicht als gesperrt.

Das Ergebnis ist, dass ein kompromittiertes Zertifikat so lange ein wirksames Angriffswerkzeug bleibt, wie es als vertrauenswürdig gilt. Nach dem bisherigen Gültigkeitsmodell von 39 Monaten konnte die Kompromittierung eines einzigen Schlüssels ein Unternehmen potenziell über drei Jahre lang einem Risiko aussetzen. Mit der neuen Grenze von 460 Tagen wird der maximale Zeitraum für Angriffe deutlich reduziert.

Das zweite Problem besteht darin, dass Unternehmen gültige Zertifikate tendenziell nicht vorzeitig ersetzen, selbst wenn bessere Algorithmen verfügbar sind. Die Branche musste diese Erfahrung bei der Abschaffung von SHA-1 und dem Übergang von 1024-Bit-RSA-Schlüsseln machen. Beide Übergänge zogen sich unnötig in die Länge, da langlebige Zertifikate Unternehmen keine natürliche Frist zum Handeln boten.

Kürzere Gültigkeitsdauern ändern dies. Jede Verlängerung bietet die Möglichkeit, aktuelle Standards einzuführen. Dies ist insbesondere jetzt relevant, da das NIST im August 2024 seine ersten Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) finalisiert hat. Organisationen, die ihre Zertifikate regelmäßig verlängern, sind deutlich besser gerüstet, um quantenresistente Algorithmen einzuführen, sobald die Unterstützung durch Plattformen und Zertifizierungsstellen weiterentwickelt wird.

Kürzere Zertifikatsgültigkeitsdauern begrenzen den Schaden durch einen Schlüsselkompromittierungsfall, verringern die Abhängigkeit von nicht immer zuverlässigen Widerrufsmechanismen und halten kryptografische Standards im gesamten Ökosystem aktuell. Die Anwendung dieser Regelung auf Codesignaturzertifikate ist ein direkter Schritt hin zu mehr Sicherheit in der Software-Lieferkette . Der Wahlvorschlag CSC-31 formalisierte diesen Schritt mit einer festgelegten maximalen Gültigkeitsdauer und einem verbindlichen Inkrafttretensdatum für alle öffentlich vertrauenswürdigen Codesignaturzertifikate.

Was hat sich durch die Wahl CSC-31 tatsächlich geändert?

Die CA/B-Forum-Abstimmung CSC-31 wurde von Microsoft vorgeschlagen. Die Abstimmungsfrist endete am 13. Oktober 2025, und die Abstimmung wurde nach Abschluss der Prüfung des geistigen Eigentums am 17. November 2025 formell angenommen. Sieben von neun Zertifikatsausstellern stimmten dafür, zwei enthielten sich, und niemand stimmte dagegen. Auch die einzige Stimme eines Zertifikatsinhabers, abgegeben von Microsoft, fiel positiv aus. Die Prüfung des geistigen Eigentums endete am 17. November 2025, ohne dass Ausschlussanträge eingereicht wurden.

Die aktualisierten Anforderungen an die Code-Signatur (Version 3.10.0) wurden am 17. November 2025 veröffentlicht. Die neue Gültigkeitsdauer tritt am 1. März 2026 in Kraft. Die Anforderung gilt für alle öffentlich vertrauenswürdigen Code-Signaturzertifikate, d. h. für Zertifikate von Zertifizierungsstellen, deren Stammzertifikate in den Truststores von Betriebssystemen und Browsern hinterlegt sind. Private PKI-Systeme, die für interne Signaturprozesse verwendet werden, unterliegen nicht den Regeln des CA/B-Forums. Eine Angleichung der internen Vorgehensweise an denselben Standard ist jedoch sinnvoll.

Ein wichtiger praktischer Punkt: Die 460-Tage-Frist beginnt mit dem Ausstellungsdatum, nicht mit dem Bestelldatum. Zertifikate, die vor dem 1. März 2026 beantragt, aber erst danach ausgestellt wurden, unterliegen der neuen Beschränkung. Die meisten Zertifizierungsstellen (CAs) haben die Ausstellung von 2- und 3-jährigen Codesignaturzertifikaten Ende Februar 2026 eingestellt, um die Frist einheitlich umzusetzen. Alle ab dem 1. März 2026 ausgestellten, öffentlich vertrauenswürdigen Codesignaturzertifikate sind maximal 460 Tage gültig.

Die Einhaltung der 460-Tage-Frist ist theoretisch unkompliziert. Die schwierigere Frage ist jedoch, ob die bestehende Infrastruktur für die Vertragsunterzeichnung jemals für diesen Rhythmus ausgelegt war.

Warum die Infrastruktur für die Signatur nicht dafür ausgelegt war

Der Wechsel von einem 39-monatigen Zertifikat zu einem 460-Tage-Zertifikat klingt nach einer einfachen Änderung des Verlängerungskalenders. In der Praxis offenbart er jedoch strukturelle Probleme in den Signaturprozessen, die die meisten Organisationen eingerichtet haben.

Der erste Punkt betrifft die Schlüsselspeicherung. Die Code Signing Baseline Requirements schreiben bereits vor, dass die privaten Schlüssel aller öffentlich vertrauenswürdigen Code-Signatur-Zertifikate – sowohl der standardmäßigen Organization Validated (OV) als auch der Extended Validation (EV) – in einem Hardware-Kryptografiemodul gespeichert werden müssen, das mindestens den Federal Information Processing Standards (FIPS) 140-2 Level 2 oder den Common Criteria EAL 4+ entspricht. Da die FIPS-140-2-Validierungen am 21. September 2026 in die Liste der historischen Validierungen aufgenommen werden, sollten Organisationen, die neue Hardware beschaffen, Module mit aktiver FIPS-140-3-Validierung priorisieren , um die fortlaufende Konformität auch nach diesem Datum sicherzustellen.

Für Standard-OV-Zertifikate sind Hardware-Tokens wie USB-basierte Geräte weit verbreitet, doch sie verursachen einen erheblichen Verwaltungsaufwand. Tokens können verloren gehen, sind an bestimmte Personen gebunden und die Verlängerung erfordert eine erneute Bereitstellung der Hardware. Bei einem 460-Tage-Zyklus findet dieser Prozess jährlich statt statt alle drei Jahre statt, was deutlich mehr Aufwand und ein höheres Fehlerrisiko mit sich bringt, wenn die Verwaltung nicht ordnungsgemäß erfolgt.

Das zweite Problem ist die Pipeline-Integration. Viele Build-Systeme signieren Artefakte mit einem Zertifikat und einem Schlüssel, die manuell in einem Dateisystempfad, einer Umgebungsvariablen oder einem Eintrag im Secrets Manager hinterlegt wurden. Wird das Zertifikat ersetzt, bricht etwas in dieser Kette. Bei einem 460-Tage-Zyklus tritt dieser Fehler häufiger auf. Teams ohne durchgängige Automatisierung der Zertifikatsbereitstellung, der Generierung von Certificate Signing Requests (CSRs), der Interaktion mit der Zertifizierungsstelle und der Bereitstellung werden diesen Zeitplan nur schwer zuverlässig verwalten können.

Das dritte Problem ist die Bestandsverwaltung. Eine einzelne Organisation kann Dutzende von Codesignaturzertifikaten besitzen, die über verschiedene Produktlinien, Entwicklungsumgebungen und von externen Dienstleistern verwaltete Systeme verteilt sind. Die Teams, die diese Zertifikate vor drei Jahren besaßen, sind möglicherweise nicht mehr im Unternehmen. Ohne eine zentrale Erfassung der vorhandenen Zertifikate, ihrer Eigentümer und ihrer Ablaufdaten wird ein 460-tägiger Erneuerungszyklus unpraktikabel.

Die strukturellen Lücken in der Unterzeichnungsinfrastruktur führen nicht nur zu Reibungsverlusten bei der Erneuerung von Zertifikaten; sie werden zu kritischen Haftungsrisiken, sobald ein Zertifikat in Frage gestellt wird.

Was passiert, wenn ein Code-Signaturzertifikat kompromittiert wird?

Ein kompromittiertes Codesignaturzertifikat ist nicht nur ein Sicherheitsvorfall, sondern ein betrieblicher Notfall mit einer strikten Frist. Gemäß den Code Signing Baseline Requirements Version 3.10.0 muss eine Zertifizierungsstelle (CA) ein Codesignaturzertifikat innerhalb von 24 Stunden widerrufen, nachdem sie darüber informiert wurde, dass das Zertifikat zum Signieren von Schadsoftware verwendet wurde oder dass der private Schlüssel gestohlen oder offengelegt wurde. Dieses 24-Stunden-Fenster lässt kaum Spielraum für eine langsame oder unkoordinierte Reaktion.

Das unmittelbare Problem ist die Identifizierung. Bevor eine Zertifizierungsstelle (CA) tätig werden kann, muss das betreffende Zertifikat genau identifiziert werden: Seriennummer, ausstellende CA und aktueller Sperrstatus. Für Organisationen ohne zentrales Zertifikatsverzeichnis kann allein dieser Schritt Stunden dauern. Sind Signaturzertifikate über verschiedene Teams, Build-Umgebungen und Systeme von Auftragnehmern verteilt und kein eindeutiger Eigentümer verzeichnet, ist es unter Zeitdruck schwierig, das richtige Zertifikat zu finden.

Nach dem Widerruf kann das Zertifikat nicht mehr zur Signierung neuer Dokumente verwendet werden, und die Zertifizierungsstelle (CA) veröffentlicht den Widerruf über ihre CRL- und OCSP-Infrastruktur. Die Überprüfung des Widerrufs wird jedoch nicht auf allen Plattformen einheitlich durchgeführt. Das bedeutet, dass ein widerrufenes Zertifikat in manchen Umgebungen nach dem Widerruf noch eine Zeit lang akzeptiert werden kann – genau das Verhalten, das durch kürzere Zertifikatslebensdauern im Laufe der Zeit eingeschränkt werden soll.

Das Ersatzzertifikat muss anschließend ausgestellt und in allen Pipelines bereitgestellt werden, die vom kompromittierten Zertifikat abhängig waren. Ohne dokumentierte Pipeline-Integration und automatisierte Bereitstellung bedeutet dies einen weiteren manuellen Aufwand unter Zeitdruck. Organisationen mit einem Hardware-Sicherheitsmodul (HSM) zur Schlüsselspeicherung sind hier im Vorteil, da die Kompromittierung typischerweise auf das Zertifikat und nicht auf die zugrunde liegende Hardware beschränkt ist und die Generierung neuer Schlüssel innerhalb des HSM erfolgen kann, ohne dass physische Token teamübergreifend neu bereitgestellt werden müssen.

Die praktische Lehre ist eindeutig: Dieselben Schwachstellen, die die Verwaltung eines 460-tägigen Erneuerungszyklus erschweren – wie unvollständige Zertifikatsbestände, manuelle Signaturprozesse und softwaregespeicherte private Schlüssel –, führen auch zu langsameren und fehleranfälligeren Reaktionen auf Sicherheitsvorfälle. Die Behebung dieser Schwachstellen vor einem Sicherheitsvorfall ist deutlich kostengünstiger als der Versuch, sie während eines laufenden Vorfalls zu beheben.

Die Reaktion auf Sicherheitsvorfälle endet nicht mit dem Entzug und der Ersetzung von Zertifikaten. Unternehmen müssen auch verstehen, wie sich Zeitstempel auf das Vertrauen und die Nutzbarkeit zuvor signierter Software auswirken.

Die Frage der Zeitstempelung, die die meisten Teams übersehen

Ein Aspekt der Codesignierung, der bei kürzeren Zertifikatsgültigkeitsdauern besonders wichtig ist, ist die Zeitstempelung gemäß RFC 3161. Wenn eine Signatur einen vertrauenswürdigen Zeitstempel einer Zeitstempelstelle (Time-Stamping Authority, TSA) enthält , bleibt diese Signatur auch nach Ablauf des Zertifikats gültig.

Der Zeitstempel liefert einen kryptografischen Nachweis darüber, wann die Software signiert wurde. Dadurch bleibt die Signatur auch nach Ablauf des Codesignaturzertifikats gültig, vorausgesetzt, die Zertifikatskette der TSA ist zum Zeitpunkt der Überprüfung gültig und vertrauenswürdig. Folglich verliert Software, die vor Ablauf des Zertifikats signiert und verteilt wurde, nicht automatisch ihr Vertrauen gemäß der neuen Gültigkeitsdauer von 460 Tagen. 

Was sich ändert, ist das Signaturzertifikat selbst. Für die Signierung neuer Releases, Builds und aktualisierter Pakete ist ein gültiges, nicht abgelaufenes Zertifikat erforderlich. Sobald ein Codesignaturzertifikat abläuft, kann es nicht mehr für neue Signaturen verwendet werden, selbst wenn ältere Signaturen dieses Zertifikats weiterhin gültig sind. Die Folgen sind unmittelbar: Jede Lücke in der Zertifikatsverfügbarkeit unterbricht die Softwareauslieferung. Bei einem 460-Tage-Zyklus lässt eine versäumte Verlängerung keine dreijährige Pufferzeit zu. Sie stoppt die Softwareentwicklung am 461. Tag.

Diese praktischen Gegebenheiten machen eines deutlich: Organisationen benötigen Signatur-Workflows, die für die kontinuierliche Zertifikatserneuerung und nicht nur für den gelegentlichen Zertifikatsaustausch ausgelegt sind.

Was muss sich bei den Signaturprozessen ändern?

Die Einhaltung der 460-Tage-Grenze ist nur der Anfang. Um einen Workflow zu entwickeln, der auch die nächste Reduzierung übersteht – die angesichts der bereits geplanten mehrjährigen Reduzierung von TLS-Zertifikaten wahrscheinlich ist –, sind strukturelle Änderungen erforderlich.

Beginnen Sie mit der Ermittlung des Zertifikatbestands. Die Verwaltung von Codesignaturzertifikaten mit einem 460-tägigen Erneuerungszyklus erfordert Kenntnisse über deren Anzahl, deren Einsatzorte, die davon abhängigen Pipelines und die jeweiligen Eigentümer. Organisationen, die bisher das alte 39-Monats-Modell verwendet haben, verfügen oft nicht über einen solchen Bestand in nutzbarer Form. Dessen Erstellung ist der erste Schritt, bevor weitere Prozesse automatisiert oder zuverlässig verwaltet werden können.

Signaturschlüssel müssen in Hardware verlagert werden. Private Schlüssel, die auf Dateisystemen, Entwicklerrechnern oder Build-Servern gespeichert sind, müssen in ein HSM (Hardware-Signature-Management-System) verschoben werden. HSM-basierter Speicher erfüllt die Mindestanforderungen von FIPS 140-2 Level 2 , die in den CA/B Forum Code Signing Baseline Requirements festgelegt sind, beseitigt das Problem der physischen Neubereitstellung, das USB-Token bei jährlichen Erneuerungszyklen verursachen, und reduziert das Risiko, dass ein kompromittierter Schlüssel zum Signieren und Verbreiten von Schadsoftware verwendet wird. Da alle FIPS 140-2-Validierungen am 21. September 2026 in die Liste der historischen Zertifizierungen aufgenommen werden, sollten bei neuen Hardwarebeschaffungen Module mit aktiver FIPS 140-3-Validierung berücksichtigt werden.

Automatisieren Sie den Erneuerungsprozess. Die CA/B-Forum-Code-Signatur-Basisanforderungen schreiben zwar keine Automatisierung vor, doch ein 460-Tage-Zyklus macht die manuelle Erneuerung in nennenswertem Umfang unzuverlässig. Die Generierung von Zertifikatsignierungsanforderungen (CSRs), die Einreichung bei der Zertifizierungsstelle, die Ausstellung und die Bereitstellung sollten über einen wiederholbaren und nachvollziehbaren Workflow erfolgen und nicht manuell, sondern erst wenige Tage vor Ablauf der Gültigkeit. Das ACME-Protokoll ( Automatic Certificate Management Environment ), sofern CA-Unterstützung verfügbar ist, eliminiert manuelle Schritte vollständig aus dem Erneuerungsprozess.

Planen Sie für die nächste Reduzierung. Code-Signatur-Zertifikate werden nun, wie TLS, reduziert. Organisationen, die heute eine auf Automatisierung basierende Signaturinfrastruktur aufbauen, können zukünftige Gültigkeitsreduzierungen verkraften, ohne von Grund auf neu aufbauen zu müssen. Organisationen, die 460 Tage als dauerhafte Obergrenze betrachten, könnten bei der nächsten Abstimmung erneut mit denselben Problemen konfrontiert werden.

Für viele Organisationen erfordert der Aufbau dieses Reifegrades im operativen Bereich spezialisiertes Fachwissen, geeignete Werkzeuge und eine schrittweise Implementierungsstrategie. Hier kann Encryption Consulting helfen.

Wie Verschlüsselungsberatung helfen kann

CodeSign Secure ist die Enterprise-Codesignatur-Managementplattform von Encryption Consulting, die entwickelt wurde, um die von verschiedenen Branchen benötigten Infrastrukturkontrollen bereitzustellen.

HSM-gestütztes Schlüsselmanagement

CodeSign Secure speichert alle privaten Signaturschlüssel in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen (HSMs) und ist mit Thales Luna, Entrust nShield, Utimaco, Securosys sowie Cloud-HSMs von AWS und Azure kompatibel. Die Schlüsselisolation pro Produkt wird auf HSM-Partitionsebene gewährleistet: Jede Produktlinie erhält einen eigenen, dedizierten Schlüssel, der in der Hardware generiert und niemals exportiert wird.

Unterzeichnungsbeschlussfähigkeit und RBAC der M-of-N

Das rollenbasierte Zugriffskontrollmodell der Plattform erzwingt die Genehmigungsanforderungen (M-von-N) für die Signierung von Produktions-Firmware. Keine einzelne Person kann einen Signiervorgang initiieren und genehmigen. Signieranfragen, Genehmigungen und Ablehnungen werden protokolliert. Die RBAC-Konfiguration selbst ist auditierbar und versionskontrolliert und stellt somit die dokumentierte Signierrichtlinie bereit, die für CRA-Konformitätsbewertungen erforderlich ist.

Unveränderliche Audit-Protokollierung

Jeder Signaturvorgang in CodeSign Secure erzeugt einen unveränderlichen Protokolleintrag, der den Artefakt-Hash, die Schlüsselkennung, das verwendete Zertifikat, die genehmigende Identität und den RFC-3161-Zeitstempel erfasst. Die Protokolle werden zentral und getrennt von der Signaturinfrastruktur gespeichert.

Unterstützung für plattformübergreifende Firmware-Formate

CodeSign Secure unterstützt die Signierung von Firmware-Artefakten in allen Formaten, die ein vielfältiges Produktportfolio erfordert: .bin, .img, .hex, .fw, .dfu und .efi. Damit wird die Anforderung der CRA nach einheitlichen Kontrollen über alle Produktlinien hinweg erfüllt, ohne dass die Signaturinfrastruktur für jede Plattform neu aufgebaut werden muss.

Unterstützung für Post-Quanten-Kryptographie

CodeSign Secure v3.02 unterstützt produktionsreife ML-DSA (FIPS 204, Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) und SLH-DSA (FIPS 205) als abtrennbare Signaturen neben klassischen Algorithmen. Für Hersteller von Produkten mit mehr als fünfjährigen CRA-Supportverpflichtungen bietet die PQC-Signatur heute Schutz vor der HNDL-Bedrohung, bevor ein kryptografisch relevanter Quantencomputer (CRQC) verfügbar ist.

CI/CD-Pipeline-Integration

CodeSign Secure lässt sich über API- und Befehlszeilenschnittstellen in Azure DevOps , Jenkins , GitLab CI und andere gängige Pipeline-Plattformen integrieren. Die Signierung der Firmware ist ein kontrollierter, richtlinienkonformer Schritt in der Build-Pipeline und kein manueller Vorgang.

Organisationen, die den 460-tägigen Übergangsprozess durchlaufen – sei es die Bewertung ihres aktuellen Zertifikatsbestands, die Migration von Schlüsseln auf Hardware oder die Einrichtung automatisierter Erneuerungsprozesse – können sich für eine praxisnahe Beratung an Encryption Consulting wenden. Das Team arbeitet direkt mit den Organisationen zusammen, um Schwachstellen in ihrer Signaturinfrastruktur zu identifizieren und einen praktikablen Weg zu entwickeln, bevor der nächste Erneuerungszyklus Druck erzeugt.

Fazit

Die Abstimmung des CA/B Forums (CSC-31) markiert einen grundlegenden Wandel im Umgang mit öffentlich vertrauenswürdigen Code-Signaturzertifikaten. Die bisherige Gültigkeitsdauer von 39 Monaten, auf der die meisten Teams ihre Arbeitsabläufe aufgebaut hatten, entfällt. Organisationen, die sich noch nicht angepasst haben, stehen demnächst vor ihrer ersten Verlängerung um 460 Tage. Die dann getroffenen Infrastrukturentscheidungen werden darüber entscheiden, ob zukünftige Kürzungen zu Störungen führen oder reibungslos verlaufen.

Organisationen, die in dieser Situation erfolgreich sind, beschränken sich nicht darauf, eine Kalendererinnerung hinzuzufügen und weiterzumachen. Sie verstehen die 460-Tage-Grenze als klares Signal: Die Branche tendiert branchenweit zu kürzeren Zertifikatslaufzeiten, TLS-Zertifikate unterliegen bereits einem bestätigten mehrjährigen Reduzierungsplan, und auch die Codesignierung befindet sich auf diesem Weg. Der Aufbau einer automatisierten, auditierbaren Signaturinfrastruktur bedeutet, dass diese bei der nächsten Reduzierung nicht erneut aufgebaut werden muss.

Das CA/B-Forum verfolgt konsequent seine Strategie. Die Gültigkeitsdauer von Zertifikaten wird sich weiter verkürzen, und manuelle Erneuerungsprozesse werden zunehmend schwieriger aufrechtzuerhalten sein. Organisationen, die heute in Erkennung, hardwaregestützte Schlüsselspeicherung und automatisiertes Zertifikatslebenszyklusmanagement investieren, erfüllen nicht nur eine aktuelle Anforderung. Sie schaffen die Grundlage, die sie auch bei zukünftigen Verkürzungen der Zertifikatsgültigkeit tragen wird.