Sichere Codesignatur: Reduzierte Zertifikatsgültigkeit auf 460 Tage

Wenn Sie für die Codesignierung in Ihrem Unternehmen zuständig sind, hat die Branche die Regeln geändert, und die Frist ist bereits abgelaufen. Am 1. März 2026 trat die Abstimmung CSC-31 in Kraft, die vom CA/Browser Forum am 17. November 2025 formell verabschiedet wurde. Sie verkürzt die maximale Gültigkeitsdauer aller öffentlich vertrauenswürdigen Codesignierungszertifikate von 39 Monaten (ca. 3 Jahren) auf 460 Tage (ca. 15 Monate). Alle Codesignierungszertifikate, die am oder nach dem 1. März 2026 ausgestellt werden, müssen diese neue Beschränkung einhalten.

Für Entwicklungsteams, die bisher nach dem Prinzip „einrichten und vergessen“ alle zwei bis drei Jahre erneuert haben, verändert diese Änderung grundlegend die Rolle der Codesignierung im Software-Release-Prozess. Was einst eine alle drei Jahre anfallende administrative Aufgabe war, ist nun eine wiederkehrende, betrieblich bedeutsame Verpflichtung, die bewusst gesteuert und in den meisten Fällen automatisiert werden muss.

In diesem Blogbeitrag erläutern wir genau, was sich geändert hat, warum das CA/Browser Forum diese Entscheidung getroffen hat, wer am stärksten betroffen ist und vor allem, was Ihr Team jetzt tun sollte, um die Compliance zu gewährleisten und den Signiervorgang ohne Unterbrechung aufrechtzuerhalten.

Die Gültigkeitsdauer des Codesignaturzertifikats beträgt 460 Tage und ist wie folgt definiert: die maximale Lebensdauer, die das CA/Browser Forum für ein öffentlich vertrauenswürdiges Codesignaturzertifikat zulässt, das am oder nach dem 1. März 2026 ausgestellt wird. Dies ist eine Reduzierung von 39 Monaten gemäß Wahlvorschlag CSC-31 (angenommen am 17. November 2025). Dadurch verdreifacht sich in etwa, wie oft jedes Signaturzertifikat, das eine Organisation verwendet, nachverfolgt, erneuert und, falls die Schlüsselspeicherung noch von physischen Token abhängt, physisch ersetzt werden muss.

Wichtige Erkenntnisse

• Der Wahlvorschlag CSC-31 wurde am 14. Oktober 2025 angenommen, durchlief das IPR-Verfahren und wurde am 17. November 2025 formell verabschiedet (Veröffentlichung der Code Signing Baseline Requirements v3.10.0). Er trat am 1. März 2026 in Kraft. Zertifikate, die vor diesem Datum ausgestellt wurden, behalten ihre ursprüngliche Gültigkeit; alle Zertifikate, die ab diesem Datum ausgestellt werden, sind auf 460 Tage begrenzt, ohne Nachfrist.
• Dies ist die maßgebliche und detaillierteste Seite zu dieser spezifischen Abstimmung und ihren operativen Folgen. Informationen darüber, wie dies mit den separaten Verpflichtungen des EU-Cyberresilienzgesetzes (EU Cyber ​​Resilience Act) zusammenhängt, die dieselbe Signaturinfrastruktur betreffen, finden Sie hier. CRA-konforme Architektur für sichere Codesignierung, wodurch beide Regimes zusammenfassend dargestellt werden, anstatt die Details des Wahlzettels hier zu wiederholen.
• Eine kürzere Gültigkeitsdauer verringert nicht die Notwendigkeit der Widerrufsbereitschaft, sondern ändert die Berechnung: Ein kompromittierter Schlüssel ist nun maximal 460 Tage lang potenziell gefährdet anstatt 39 Monaten, aber eine bestätigte Kompromittierung erfordert nach wie vor einen Widerruf innerhalb von 24 Stunden gemäß den Basisanforderungen, nicht erst dann, wenn das Zertifikat abläuft.
• USB-Hardware-Tokens, die bei einem 3-Jahres-Zyklus noch tolerierbar sind, werden bei einem 15-Monats-Zyklus zu einer wiederkehrenden Betriebskostenbelastung; dies ist der häufigste Grund, warum Unternehmen erst nach dieser Änderung, nicht davor, auf HSM-gestützte Signaturverfahren umsteigen.

Was sich geändert hat und wann

Die Arbeitsgruppe für Code-Signaturzertifikate des CA/Browser-Forums hat den Wahlvorschlag CSC-31 zur Aktualisierung der Basisanforderungen für die Ausstellung und Verwaltung öffentlich vertrauenswürdiger Code-Signaturzertifikate , Version 3.9, vorgelegt.

Hier ist die Zeitleiste:

Milestone	Datum
Vorschlag für den Wahlzettel CSC-31	September 2025
Der Stimmzettel wurde vom CA/B Forum angenommen und genehmigt.	14. Oktober 2025
Die IPR-Prüfungsphase ist abgeschlossen, der Stimmzettel wurde formell angenommen.	November 17, 2025
Neue Baseline-Anforderungen für die Codesignierung v3.10.0 veröffentlicht	November 17, 2025
Die neue maximale Gültigkeitsdauer von 460 Tagen tritt in Kraft.	1. März 2026

Zertifikate, die vor dem 1. März 2026 nach den bisherigen Bestimmungen ausgestellt wurden, behalten ihre Gültigkeit bis zu ihrem ursprünglichen Ablaufdatum. Zertifikate, die am oder nach dem 1. März 2026 ausgestellt oder verlängert werden, unterliegen jedoch der neuen Gültigkeitsdauer von 460 Tagen. Für neu ausgestellte Zertifikate gibt es keine Kulanzfrist.

Warum das CA/Browser-Forum diese Änderung vorgenommen hat

Die Tendenz zu kürzeren Zertifikatsgültigkeitsdauern ist weder willkürlich noch neu. Das CA/Browser Forum reduziert die Gültigkeitsdauer von Zertifikaten aller Art seit Jahren systematisch. Die Begründung dafür ist nachvollziehbar und basiert auf fundierten Sicherheitsprinzipien.

1. Begrenzung des Wirkungsradius wichtiger Kompromittierungen: Der private Schlüssel eines Codesignaturzertifikats kann kompromittiert werden – beispielsweise durch Datenlecks, Ransomware, Insiderbedrohungen oder unsachgemäße Schlüsselaufbewahrung. Gemäß der alten Gültigkeitsdauer von 39 Monaten blieb ein kompromittierter Schlüssel für Angreifer bis zu drei Jahre lang nutzbar, selbst wenn das Zertifikat widerrufen wurde (da die Überprüfung des Zertifikatswiderrufs plattformübergreifend uneinheitlich gehandhabt wird).
   Eine kürzere Lebensdauer begrenzt das Zeitfenster für potenzielle Angriffe erheblich. Wird ein Schlüssel am ersten Tag eines 460-Tage-Zertifikats kompromittiert, stehen dem Angreifer nur etwa 15 Monate anstatt drei Jahre für möglichen Missbrauch zur Verfügung.
2. Stärkeres Schlüsselmanagement: Wenn sich ein Team drei Jahre lang nicht um sein Signaturzertifikat kümmern muss, verkümmern wichtige Speicherpraktiken, Zugriffskontrollen und Prüfprotokolle. Jährliche oder fast jährliche Erneuerungen zwingen Unternehmen dazu, ihre Signaturinfrastruktur regelmäßig zu überprüfen – zu prüfen, wer Zugriff hat, wo die Schlüssel gespeichert sind, ob die Speichermethoden noch den aktuellen Standards entsprechen und ob die Signaturprozesse noch angemessen sind.
3. Förderung der Automatisierung: Alle Organisationen, die Code mit einem öffentlich vertrauenswürdigen Codesignaturzertifikat signieren, sind betroffen. Kürzere Gültigkeitsdauern machen die manuelle Verwaltung zunehmend unpraktisch, was die Einführung automatisierter Tools beschleunigt.

Das USB-Token-Problem

Es lohnt sich, einen Moment speziell auf das Problem der USB-Hardware-Token einzugehen, da dies für viele Entwicklungsteams die größte operative Herausforderung darstellt, die durch die 460-Tage-Änderung entstanden ist.

Die Baseline Requirements des CA/Browser Forums verlangen seit Jahren, dass private Schlüssel für öffentlich vertrauenswürdige Codesignaturzertifikate auf Hardware gespeichert werden, die den Standards FIPS 140-2 Level 2 oder Common Criteria EAL 4+ entspricht. Viele Organisationen erfüllten diese Anforderung, indem sie Codesignaturzertifikate auf USB-Hardware-Tokens ausstellten, die direkt von der Zertifizierungsstelle versandt wurden – ein Modell, das die Hardware-Speicheranforderung für die Schlüssel erfüllte, ohne dass die Organisation eine eigene HSM-Infrastruktur betreiben musste.

Die USB-Token-basierte Signierung brachte selbst unter der alten Gültigkeitsdauer von 39 Monaten ihre eigenen Probleme mit sich:

• Tokens konnten verloren gehen, beschädigt oder gestohlen werden, und für deren Ersatz war die Neuausstellung des Zertifikats erforderlich.
• Für die Signierung war ein physischer Zugriff auf das Token erforderlich, was zu Engpässen für Remote-Teams und automatisierte CI/CD-Pipelines führte.
• Die Token konnten nicht ohne Weiteres gesichert werden, wodurch ein einziger Fehlerpunkt für den Signiervorgang entstand.

Bei einer Gültigkeitsdauer von 460 Tagen treten all diese Probleme häufiger auf. Die Token-Logistik, die in einem Dreijahreszyklus noch überschaubar war, wird in einem 15-Monats-Zyklus zu einer wiederkehrenden operativen Belastung.

Die praktische Lösung und die klare Richtung, in die sich die Branche entwickelt, ist die Migration von USB-Tokens zu einer Cloud-basierten oder On-Premises- HSM-Infrastruktur, auf die über eine zentrale Signaturplattform zugegriffen wird. Dieser Ansatz speichert den privaten Schlüssel in FIPS-konformer Hardware, ermöglicht Signaturvorgänge per API von jedem autorisierten Build-System aus, eliminiert die physische Token-Logistik vollständig und integriert sich nahtlos in zentrale Codesignaturplattformen.

Warum die Zeitstempelung jetzt noch wichtiger wird

Einer der wichtigsten technischen Aspekte für kürzere Zertifikatslebensdauern ist die Zeitstempelung. Läuft ein Codesignaturzertifikat ab, wird Software, die mit diesem Zertifikat signiert wurde, nicht automatisch als nicht vertrauenswürdig eingestuft. Enthält der Signiervorgang einen gültigen RFC-3161-Zeitstempel einer vertrauenswürdigen Zeitstempelstelle (TSA), bleibt die Signatur unbegrenzt verifizierbar – auch nach Ablauf des Zertifikats. Der Zeitstempel liefert den kryptografischen Beweis, dass der Signiervorgang während der Gültigkeitsdauer des Zertifikats stattfand, und dieser Beweis bleibt auch nach Ablauf der Gültigkeitsdauer des Zertifikats bestehen.

Ohne Zeitstempel ist die Vertrauenswürdigkeit des signierten Artefakts direkt an die Gültigkeitsdauer des Zertifikats gebunden. Nach Ablauf des Zertifikats lehnen Verifizierungssysteme, die die Zertifikatsgültigkeit prüfen, die Signatur ab. Bei Software mit einer Nutzungsdauer von mehr als 15 Monaten – was praktisch alle Unternehmensanwendungen, Treiber, Firmware-Images und langlebigen ausführbaren Dateien betrifft – führt ein fehlender oder fehlerhaft angebrachter Zeitstempel dazu, dass die Software ihren Vertrauensstatus verliert.

Bei der jährlichen Erneuerung von Zertifikaten stellt jedes signierte Dokument ohne gültigen RFC-3161-Zeitstempel innerhalb von 15 Monaten nach der Unterzeichnung ein potenzielles Problem dar. Die praktischen Schritte hierfür sind:

• Stellen Sie sicher, dass Ihre Signatur-Toolchain standardmäßig bei jedem Signiervorgang RFC 3161-Zeitstempel anwendet.
• Konfigurieren Sie Ihre Signaturpipelines so, dass ein fehlender Zeitstempel als Signaturfehler und nicht als Warnung behandelt wird.
• Stellen Sie sicher, dass die Zeitstempel mit SHA-256-Hashing angewendet werden (nicht mit SHA-1, das weitgehend veraltet ist).
• Bei Artefakten mit langer Nutzungsdauer (Firmware, Treiber, Unternehmenssoftware) sollten Sie überprüfen, ob Ihre Zeitstempelkonfiguration auch auf alle historischen Artefakte korrekt angewendet wurde.

Widerruf im Rahmen des neuen Gültigkeitszeitraums

Eine kürzere Gültigkeitsdauer wird mitunter als Verringerung des Widerrufsbedarfs beschrieben. Das ist nicht ganz richtig: Sie reduziert zwar das maximale Risiko einer Kompromittierung, ändert aber nichts an der Widerrufspflicht selbst. Gemäß den Code Signing Baseline Requirements §4.9.1.1 muss eine Zertifizierungsstelle (CA) ein Zertifikat weiterhin innerhalb von 24 Stunden nach Bestätigung der Kompromittierung des privaten Schlüssels widerrufen – und zwar bei einem 460-Tage-Zertifikat genauso wie bei einem 39-Monats-Zertifikat. Die kürzere Frist ändert lediglich die maximale Angriffsfläche: Wird ein Schlüssel am Tag nach der Ausstellung kompromittiert und bleibt dies unentdeckt, verkürzt sich das Zeitfenster, in dem ein Angreifer dies theoretisch ausnutzen könnte, von etwa drei Jahren auf etwa 15 Monate.

Die praktische Konsequenz für Ihre Audit-Checkliste: Stellen Sie sicher, dass Ihre Organisation innerhalb einer Stunde nach Verdacht auf Kompromittierung alle mit einem bestimmten Zertifikat signierten Artefakte identifizieren kann. Das bloße Abwarten des Ablaufs eines Zertifikats ist kein wirksamer Widerrufsplan, und die durch diese Änderung eingeführte schnellere Erneuerungsfrequenz ersetzt keine erprobte Reaktion auf eine Kompromittierung.

Alte vs. neue Anforderungen, Seite an Seite

Anforderung	Vor dem 1. März 2026	Am oder nach dem 1. März 2026
Maximale Gültigkeitsdauer des Zertifikats	39 Monate	460 Tage
Erneuerungshäufigkeit (typisch)	Etwa alle 3 Jahre	Etwa alle 15 Monate
Widerrufsfrist für bestätigte Schlüsselkompromittierung	24 Stunden (unverändert)	24 Stunden (unverändert)
Speicherung des privaten Schlüssels	Hardware gemäß FIPS 140-2 Level 2+ oder Common Criteria EAL4+ (seit Juni 2023)	Gleiche Anforderung, unverändert
Maximales theoretisches Risiko durch eine unentdeckte Schlüsselkompromittierung	Bis zu ca. 39 Monate	Bis zu ca. 460 Tage

Checkliste für die Prüfung: Was Sie jetzt tun sollten

Falls Ihre Organisation die Auswirkungen der 460-Tage-Regelung noch nicht bewertet hat, finden Sie hier einen praktischen Ausgangspunkt:

Schritt 1 – Überprüfen Sie Ihr Codesignaturzertifikat-Inventar. Identifizieren Sie alle öffentlich vertrauenswürdigen Codesignaturzertifikate, die Ihre Organisation verwendet. Erfassen Sie für jedes Zertifikat das Ablaufdatum, die Speichermethode (USB-Token, HSM, Cloud-HSM, Software-Speicher), die davon abhängigen Signatur-Workflows oder -Pipelines sowie die für die Verlängerung zuständige Person. Falls diese Informationen noch nicht zentral dokumentiert sind, ist die Erstellung eines solchen Inventars Ihre oberste Priorität.

Schritt 2 – Ermitteln Sie, welche Zertifikate bereits den neuen Bestimmungen unterliegen. Alle Zertifikate, die ab dem 1. März 2026 ausgestellt wurden, sind auf 460 Tage begrenzt. Ermitteln Sie, welche Ihrer Zertifikate in diese Kategorie fallen, und planen Sie die Verlängerungen mit ausreichend Vorlaufzeit ein – mindestens 30 bis 60 Tage vor Ablauf, um Zeit für Beschaffung, Bereitstellung und Aktualisierungen der Lieferkette zu haben.

Schritt 3 – Prüfen Sie Ihre Key-Storage-Infrastruktur. Wenn Ihr Unternehmen USB-Hardware-Token verwendet, prüfen Sie, ob eine Migration zu einem Cloud-HSM oder einem On-Premises-HSM mit Zugriff über eine zentrale Signaturplattform sinnvoll ist. Da die USB-Token alle 15 Monate erneuert werden müssen, ist diese Migration voraussichtlich bereits im ersten Erneuerungszyklus kosteneffektiv.

Schritt 4 – Überprüfen Sie die Konfiguration der Zeitstempelung. Überprüfen Sie Ihre Signaturpipelines, um sicherzustellen, dass bei jedem Signaturvorgang RFC 3161-Zeitstempel mit SHA-256 angewendet werden und dass ein fehlender Zeitstempel als blockierender Fehler in Ihrer Pipeline behandelt wird.

Schritt 5 – Pipeline-Konfigurationen für dynamische Zertifikatsverweise aktualisieren. Überprüfen Sie alle CI/CD-Pipeline- Konfigurationen, Build-Skripte und Konfigurationen der Signaturtools, die auf Signaturzertifikate verweisen. Ersetzen Sie statische Bezeichner durch dynamische Verweise, die nicht bei jeder Verlängerung manuell aktualisiert werden müssen.

Schritt 6 – Evaluieren Sie die Automatisierung des Zertifikatslebenszyklusmanagements. Wenn Ihr Unternehmen eine große Anzahl von Zertifikaten über mehrere Teams oder Produkte hinweg verwaltet, sollten Sie eine dedizierte, zentrale Signaturplattform evaluieren, die die Erkennung, die Benachrichtigung über die Verlängerung und die in die Pipeline integrierte Bereitstellung automatisieren kann.

Wie CodeSign Secure von Encryption Consulting hilft

CodeSign Secure ist die zentralisierte, richtlinienbasierte Codesignaturplattform von Encryption Consulting. Sie wurde speziell für die Umgebung entwickelt, die durch die 460-Tage-Regelung beschleunigt wird: eine Umgebung, in der Signaturvorgänge automatisiert, Schlüssel zentral in einer HSM-gestützten Infrastruktur verwaltet und Ereignisse im Zertifikatslebenszyklus verfolgt und darauf reagiert werden müssen, ohne dass einzelne Entwickler aktiv werden müssen.

Zentralisiertes HSM-gestütztes Schlüsselmanagement

CodeSign Secure speichert alle privaten Signaturschlüssel in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen (HSMs) – das USB-Token-Modell entfällt somit vollständig. Die Plattform ist kompatibel mit Thales Luna, Entrust nCipher, Utimaco, Securosys und den gängigen Cloud-HSMs von AWS und Azure. Die privaten Schlüssel werden innerhalb des HSM generiert, niemals exportiert und sind ausschließlich über die Signatur-API der Plattform zugänglich.

Zertifikatslebenszyklus und Benachrichtigungen zur Erneuerung

CodeSign Secure verwaltet ein zentrales Verzeichnis aller verwalteten Zertifikate mit Ablaufdaten und konfigurierbaren Benachrichtigungen zur Verlängerung. Sicherheits- und Betriebsteams erhalten frühzeitig Benachrichtigungen vor Ablauf der Zertifikate, wodurch das Risiko, ein abgelaufenes Zertifikat zu entdecken, minimiert wird.

CI/CD-Pipeline-Integration

Die Plattform integriert sich nativ in Azure DevOps, Jenkins, GitLab CI und andere gängige Pipeline-Systeme über API- und Befehlszeilenschnittstellen. Signiervorgänge werden dynamisch über die Plattform mit dem aktuell gültigen Zertifikat der Pipeline durchgeführt, anstatt über eine statische Zertifikatsreferenz. Bei einer Zertifikatserneuerung werden die Signiervorgänge der Pipeline ohne Unterbrechung und ohne Aktualisierung der Pipeline-Konfiguration fortgesetzt.

Post-Quanten-Bereitschaft

Da die Zertifikatsbranche auf kürzere Gültigkeitsdauern umstellt, bereitet sie sich auch auf die Migration zur Post-Quanten-Kryptographie vor, die das NIST bereits standardisiert hat. CodeSign Secure v3.02 unterstützt ML-DSA (FIPS 204) für die Signaturerstellung durch die Bereitstellung abtrennbarer Signaturen. Dies ermöglicht es Unternehmen, ihre Codesignatur-Infrastruktur schrittweise auf quantenresistente Algorithmen umzustellen und gleichzeitig die Kompatibilität mit bestehenden Plattformen zu gewährleisten.

Häufig gestellte Fragen

Gilt die 460-Tage-Frist auch für Zertifikate, die ich bereits besitze?

Nein. Zertifikate, die vor dem 1. März 2026 ausgestellt wurden, behalten ihre ursprüngliche Gültigkeitsdauer und ihr Ablaufdatum. Die Begrenzung auf 460 Tage gilt nur für Zertifikate, die an oder nach diesem Datum ausgestellt oder verlängert werden; eine Nachfrist gibt es nicht.

Bedeutet eine kürzere Gültigkeitsdauer, dass ich mir weniger Sorgen um den Widerruf machen muss?

Nein. Eine bestätigte Kompromittierung des Schlüssels erfordert weiterhin innerhalb von 24 Stunden den Widerruf gemäß den Code Signing Baseline Requirements, und zwar für ein 460-Tage-Zertifikat, genau wie für das alte 39-Monats-Zertifikat. Eine kürzere Gültigkeitsdauer verringert lediglich das maximale Zeitfenster für ein Sicherheitsrisiko, falls eine Kompromittierung unentdeckt bleibt; sie ersetzt nicht die Notwendigkeit eines geprüften Widerrufsprozesses.

Muss ich mir noch Gedanken über den Ablauf des Zertifikats machen, wenn ich vertrauenswürdige Zeitstempel verwende?

Bei bereits signierter und ausgelieferter Software ist dies nicht der Fall: Ein gültiger RFC-3161-Zeitstempel gewährleistet die Verifizierbarkeit der Signatur auch nach Ablauf des Zertifikats. Sie müssen das Zertifikat jedoch weiterhin vor seinem Ablauf erneuern, um neue Versionen signieren zu können.

Ist die Umstellung von USB-Tokens im Rahmen dieser Änderung zwingend erforderlich?

Nicht zwingend erforderlich, aber aus wirtschaftlicher Sicht deutlich empfehlenswert. Die Hardwareanforderung gemäß FIPS 140-2 Level 2+ gilt unabhängig davon, ob ein Token oder ein HSM verwendet wird; ein 460-tägiger Erneuerungszyklus führt lediglich dazu, dass der wiederkehrende Aufwand für den physischen Token-Austausch, Verlust und CI/CD-Engpässe deutlich häufiger auftritt als bei einem 3-Jahres-Zyklus.

Worin unterscheidet sich dies von den CRA-Konformitätsanforderungen für die Codesignatur?

Es handelt sich um zwei separate Regelungen. Diese Abstimmung betrifft eine Branchenregel des CA/Browser Forums zum Zertifikatslebenszyklus; der EU Cyber ​​Resilience Act (CRA) stellt eine separate rechtliche Verpflichtung hinsichtlich der Firmware-Integrität auf Produktebene und der Offenlegung von Sicherheitslücken dar. Organisationen, die Produkte signieren, die unter den CRA fallen, müssen beide Anforderungen erfüllen; siehe CRA-Konformitätsarchitektur für sicheres Codesignieren für weitere Informationen zu den Überschneidungen.

Fazit

Die am 1. März 2026 in Kraft getretene Änderung der Gültigkeitsdauer von 460 Tagen für Codesignaturzertifikate markiert nicht das Ende dieser Entwicklung – sie ist ein Schritt in die Richtung, die das CA/Browser Forum seit Jahren konsequent verfolgt. Organisationen, die diese Änderungen am reibungslossten bewältigen, sind diejenigen, die das Zertifikatslebenszyklusmanagement als disziplinierte, automatisierte Funktion auf Infrastrukturebene behandeln – und nicht als periodische manuelle Aufgabe.

Für Entwicklungsteams, die noch immer auf USB-Tokens und manuelle Verlängerungserinnerungen angewiesen sind, bietet die Umstellung auf 460 Tage die Gelegenheit, die Nachhaltigkeit dieses Ansatzes zu überprüfen. Der Aufwand für den jährlichen Token-Austausch, die Aktualisierung der Pipeline-Konfiguration und die manuelle Nachverfolgung der Verlängerung mehrerer Zertifikate wird sich mit den immer kürzer werdenden Gültigkeitsdauern schnell summieren.

Bei Encryption Consulting ist unsere CodeSign Secure- Plattform darauf ausgelegt, diesen Übergang praktisch zu gestalten. Sie bietet Ihrem Team HSM-gestützte Schlüsselsicherheit, automatisiertes Zertifikatsmanagement und eine in die Pipeline integrierte Signierung, die Verlängerungen ohne manuelles Eingreifen durchführt.