Die neue Gültigkeitsänderung des Code-Signatur-Zertifikats verstehen

Codesignatur Die Signaturprüfung ist der Vertrauensmechanismus, der es einem Betriebssystem ermöglicht, zu bestätigen, wer eine Software veröffentlicht hat und ob sie seit der Signierung verändert wurde. In der Public-Key-Kryptografie enthält ein Zertifikat den öffentlichen Schlüssel, während der Herausgeber den zugehörigen privaten Schlüssel geheim hält. Ein Codesignaturzertifikat verknüpft die Identität des Herausgebers mit einem öffentlichen Schlüssel, und der zugehörige private Schlüssel erzeugt die Signatur, die Windows SmartScreen, Betriebssystem-Loader und Installationsprogramme überprüfen, bevor sie einer ausführbaren Datei, einem Treiber oder einem Installationsprogramm vertrauen.

Die Gültigkeitsänderung, eingeführt von CA/Browser Forum, Abstimmung CSC-31: Reduzierung der maximalen GültigkeitDiese Änderung trat am 1. März 2026 in Kraft. Dieser Artikel konzentriert sich auf diese Gültigkeitsänderung: Was ist die neue Grenze, die kryptografische Begründung dafür, wie interagiert sie mit Zeitstempelung und Widerruf, wen betrifft sie und welche konkreten Schritte sind zur Anpassung erforderlich?

Was die neue Gültigkeitsänderung besagt

Das CA/Browser-Forum (CA/B-Forum) Die CSC-31 ist der Verband der Zertifizierungsstellen und Zertifikatsnutzer, wie z. B. Browser- und Betriebssystemhersteller, der die Mindestanforderungen für öffentlich vertrauenswürdige Zertifikate festlegt. Am 13. Oktober 2025 wurde über den Antrag CSC-31 abgestimmt, der die Mindestanforderungen für Code-Signatur-Zertifikate ändert und die maximale Gültigkeitsdauer eines solchen Zertifikats von zuvor 39 Monaten auf 460 Tage reduziert. Die Änderung wurde von Microsoft vorgeschlagen, von Sectigo und eMudhra unterstützt und am 17. November 2025 verabschiedet. Grundvoraussetzungen für die Codesignierung, Version 3.10.0.

Die Beschränkung gilt sowohl für Organisationsvalidierungs- (OV) als auch für erweiterte Validierungs-Codesignaturzertifikate (EV). Sie regelt das bei der Ausstellung festgelegte Gültigkeitsfeld und gilt daher für alle Zertifikate, die am oder nach dem 1. März 2026 ausgestellt oder verlängert werden. Zertifikate Für vor diesem Datum ausgestellte Dokumente mit längerer Gültigkeitsdauer gilt die Gültigkeit bis zum angegebenen Ablaufdatum.

Die Zahlen

Attribut	Vorherige Anforderung	Gemäß CSC-31
Maximale Gültigkeit	39 Monate	460 Tage
Datum des Inkrafttretens	Unzutreffend	1. März 2026
Basisanforderungen-Version	v3.9	v3.10.0
Betroffene Zertifikatstypen	OV und EV	OV und EV

Obwohl die Abstimmung eine maximale Gültigkeitsdauer von 460 Tagen vorsieht, stellen einige Zertifizierungsstellen (CAs) in der Praxis Zertifikate mit einer Gültigkeitsdauer von 459 Tagen aus, um einen Puffer für mögliche Zeitabweichungen und Ausstellungsverzögerungen zu gewährleisten. DigiCert beispielsweise gibt eine Gültigkeitsdauer von 459 Tagen an, und SSL.com stellt aus demselben Grund Zertifikate mit einer Gültigkeitsdauer von 458 Tagen aus. Mehrere CAs haben den Verkauf von zwei- und dreijährigen Zertifikaten Ende 2025 im Vorfeld der Umstellung eingestellt; einjährige Zertifikate (366 Tage) sind nun Standard.

Die Gründe für eine kürzere Gültigkeitsdauer

Die Validitätsreduktion ist eine Anwendung eines etablierten Verfahrens. Schlüsselverwaltung Es handelt sich eher um ein Prinzip als um eine Reaktion auf einen einzelnen Vorfall. Ein Code-Signatur-Zertifikat bindet einen langlebigen privaten Signaturschlüssel an eine Identität. Je länger diese Bindung gültig ist, desto länger kann ein gestohlener oder missbrauchter Schlüssel vertrauenswürdige Signaturen erzeugen und desto größer ist die Menge an signierten Dokumenten, die ein Angreifer erstellen kann, bevor jemand eingreift.

Kryptoperioden in den NIST-Richtlinien zum Schlüsselmanagement

Dies entspricht direkt dem Konzept einer Kryptoperiode, das in definiert ist NIST-Sonderveröffentlichung 800-57 Teil 1 Revision 5, Empfehlung für das SchlüsselmanagementEine Kryptoperiode ist der Zeitraum, in dem ein Schlüssel zur Verwendung autorisiert ist. NIST Es wird empfohlen, die Gültigkeitsdauer zu begrenzen, um eine unbegrenzte Risikoakkumulation zu verhindern. Die Veröffentlichung modelliert jeden Schlüssel als durchlaufenden Zustand (Voraktivierung, aktiv, deaktiviert, kompromittiert, zerstört). Die Begrenzung der Zertifikatsgültigkeit auf 460 Tage begrenzt die aktive Laufzeit des zugehörigen Signaturschlüssels und gewährleistet so, dass Identitätsbindungen mindestens alle 15 Monate neu validiert werden. Die Rotation des Signaturschlüssels selbst erfordert die Generierung eines neuen Schlüsselpaares bei der Verlängerung, was der empfohlenen Vorgehensweise entspricht.

Empfehlungen speziell für die Codesignierung

Das NIST veröffentlichte außerdem einen Leitfaden speziell für diesen Anwendungsfall. NIST-Weißbuch zur Cybersicherheit, Sicherheitsüberlegungen zur CodesignierungDie Dokumentation erklärt, wie Codesignierung Integrität und Quellcodeauthentifizierung gewährleistet, und empfiehlt, Signaturschlüssel zu isolieren, sie in einem ausschließlich für Signaturfunktionen vorgesehenen Hardware-Sicherheitsmodul zu speichern, Entwicklungs- und Produktionssignatursysteme zu trennen und vor einem Signaturvorgang die Zustimmung mehrerer Personen einzuholen. Eine kürzere Gültigkeitsdauer verstärkt diese Kontrollen durch die erzwungene regelmäßige Neuausstellung, wodurch die Identität des Herausgebers erneut bestätigt und die Schlüsselbindung nach einem festen Zeitplan rotiert wird.

Wie Gültigkeit mit Signierung, Zeitstempelung und Widerruf interagiert

Um die Auswirkungen einer kürzeren Gültigkeitsdauer auf den Betrieb zu bewerten, muss das Verhältnis zwischen Zertifikat, Zeitstempel und Widerruf präzise definiert sein. Das Zertifikat legt den Zeitraum fest, in dem ein Signaturschlüssel als vertrauenswürdig gilt, der Zeitstempel dokumentiert die Erstellung einer Signatur, und der Widerruf entzieht dem Zertifikat das Vertrauen, bevor es regulär ablaufen würde.

Die Unterzeichnungsoperation

1. Der Herausgeber berechnet einen kryptografischen Hashwert des Artefakts unter Verwendung einer zugelassenen Hash-Funktion wie beispielsweise SHA-256.
2. Der Digest wird mit dem privaten Schlüssel signiert, wodurch die Signatur entsteht, die zusammen mit dem Zertifikat des Herausgebers und dessen Kette zu einem vertrauenswürdigen Stammzertifikat in das Artefakt eingebettet wird.
3. Zum Zeitpunkt der Verifizierung berechnet der Loader den Digest neu, überprüft die Signatur anhand des öffentlichen Schlüssels im Zertifikat und validiert die Zertifikatskette sowie den Gültigkeitsstatus des Zertifikats.

Warum eine kürzere Gültigkeitsdauer bereits signierte Software nicht beeinträchtigt

Eine häufige Befürchtung ist, dass kurzlebige Zertifikate dazu führen, dass bereits veröffentlichte Software nicht mehr validiert werden kann. Das ist jedoch nicht der Fall, solange die Signatur mit einem Zeitstempel versehen ist. Ein Zeitstempel einer vertrauenswürdigen Zertifizierungsstelle (Timestamp Authority) dokumentiert den Zeitpunkt der Signierung. Vorausgesetzt, das Zertifikat war zu diesem Zeitpunkt gültig, bleibt die Signatur für die gesamte Gültigkeitsdauer des Zeitstempels gültig, die in der Regel deutlich länger ist als die des Zertifikats. Aus diesem Grund lässt sich ein vor Jahren signierter Treiber auch dann noch installieren, wenn sein Signaturzertifikat längst abgelaufen ist.

Diese Eigenschaft ist der Kern des Sicherheitsproblems, das durch die Gültigkeitsänderung behoben wird. Da eine mit einem Zeitstempel versehene Signatur die Gültigkeit des Zertifikats überdauert, generiert ein kompromittiertes Zertifikat auch nach dem Zeitpunkt der Kompromittierung weiterhin vertrauenswürdige Signaturen. Eine Verkürzung der Gültigkeit verringert dieses Zeitfenster für Sicherheitslücken, und ein Widerruf schließt es vollständig. Der Widerrufsstatus wird veröffentlicht über Zertifikatssperrlisten (CRLs) und der Online Certificate Status Protocol (OCSP)Eine Zertifizierungsstelle (CA) kann ein kompromittiertes Zertifikat widerrufen, sodass Prüfer Signaturen ablehnen, die darauf basieren. Da eine vor dem Widerrufsdatum erstellte, mit einem Zeitstempel versehene Signatur in der Regel gültig bleibt, muss die CA das Widerrufsdatum auf den vermuteten Zeitpunkt der Kompromittierung zurücksetzen, um zuvor erstellte Signaturen ungültig zu machen.

Aktuelle Vorfälle, die das Risiko verdeutlichen

Die Risiken, die durch langlebige und schlecht verwaltete Signaturzertifikate entstehen, sind keine bloße Theorie. Mehrere aktuelle Kampagnen belegen, warum das Ökosystem die Gültigkeitsdauer von Zertifikaten verkürzt und die damit verbundenen Kontrollen verschärft.

AnyDesk-Produktionslücke (2024)

Anfang 2024 bestätigte der Fernzugriffsanbieter AnyDesk laut einem Bericht, dass Angreifer in seine Produktionssysteme eingedrungen waren und Quellcode sowie private Codesignaturschlüssel gestohlen wurden. PiependerComputerDas Unternehmen reagierte, indem es die betroffenen Zertifikate widerrief und sein Signaturmaterial erneuerte. Vorfälle wie dieser verdeutlichen, warum begrenzte Zertifikatsgültigkeitsdauern wichtig sind, da sie den Zeitraum verkürzen, in dem ein gestohlenes Zertifikat missbraucht werden kann.

Hijack Loader und GHOSTPULSE haben Kampagnen unterzeichnet (Ende 2024).

Im Oktober 2024 dokumentierten Forscher Hijack Loader-Samples (auch bekannt als GHOSTPULSE und IDAT Loader), die mit legitimen Signaturen versehen waren. Code-Signing-ZertifikateDie Sicherheitslücke wurde durch die Social-Engineering-Technik von ClickFix ausgenutzt, die Nutzer dazu verleitet, PowerShell auszuführen. Ermittler fanden mehrere missbrauchte Zertifikate, die mit derselben Command-and-Control-Infrastruktur verknüpft waren. Die ausstellenden Behörden annullierten die Zertifikate innerhalb weniger Stunden bis zu einem Tag nach Benachrichtigung. Dieser Vorfall verdeutlicht, welchen Wert Angreifer gültigen Signaturen beimessen und welche Rolle ein schneller Widerruf bei der Eindämmung von Missbrauch spielt.

Missbrauch von kurzlebigen Microsoft Trusted Signing-Zertifikaten (2025)

Im März 2025 wurde beobachtet, wie Angreifer Malware signierten. Der Trusted Signing-Dienst von Microsoft verwendet Drei-Tage-Zertifikate.Dieser Fall verdeutlicht zwei unterschiedliche Dynamiken. Er zeigt, dass entschlossene Akteure weiterhin nach gültigen Signaturen suchen, demonstriert aber auch den defensiven Wert kurzlebiger, zentral ausgestellter Zertifikate: Die Anmeldeinformationen werden niemals an den Entwickler weitergegeben, können also nicht von einem Endpunkt gestohlen werden und laufen nahezu sofort ab und können widerrufen werden. Genau dieses Modell wird durch die Reduzierung der Gültigkeit gefördert.

Missbrauch von Fahrern mit Fahrerlaubnis im industriellen Maßstab (2020 bis 2025)

Eine Untersuchung von Gruppe-IB Wir verfolgten eine langjährige Operation, die über 80 Zertifikate und mehr als 60 Windows-Hardwarekompatibilitätsprogramm-Konten anhäufte und zwischen 2020 und dem ersten Quartal 2025 über 620 schädliche Windows-Kernel-Treiber signierte. Dabei wurden häufig gestohlene Zertifikate oder Zertifikate verwendet, die über neu gegründete Briefkastenfirmen erlangt wurden. Kernel-Treiber laufen auf der privilegiertesten Ebene des Betriebssystems, daher ist eine gültige Signatur auf einem schädlichen Treiber extrem wirkungsvoll. Eine kürzere Gültigkeitsdauer allein verhindert die betrügerische Ausstellung von Zertifikaten nicht, aber in Kombination mit der Speicherung von Hardware-Schlüsseln und dem schnellen Widerruf reduziert sie die Nutzungsdauer jedes missbrauchten Zertifikats.

Wer ist betroffen und in welchem ​​Ausmaß?

Organisationen, die Software mit einem öffentlich vertrauenswürdigen Zertifikat signieren, unterliegen der 460-Tage-Frist. Der Umfang der betrieblichen Änderungen hängt hauptsächlich davon ab, wie die Signaturschlüssel gespeichert und die Verlängerung gehandhabt wird.

Größte Auswirkung: Arbeitsabläufe mit physischen Hardware-Token

Seit dem 1. Juni 2023 verlangt das CA/B-Forum, dass private Schlüssel für die Codesignierung auf Hardware generiert und gespeichert werden. FIPS 140-2 Level 2 oder Common Criteria EAL 4+, typischerweise ein USB-Token oder ein HSM. Teams, die auf physische, von der Zertifizierungsstelle versandte USB-Token angewiesen sind, spüren diese Änderung am stärksten, da jede Verlängerung die Bereitstellung und den Versand eines neuen Tokens erfordert. Bei einem 15-monatigen statt eines dreijährigen Zyklus fällt dieser logistische Aufwand deutlich häufiger an.

Geringste Auswirkungen: Cloud- und HSM-basierte Signatur

Organisationen, die über einen Cloud-Signaturdienst oder ein Netzwerk signieren HSMSysteme, bei denen Schlüssel über eine API bereitgestellt und rotiert werden, bewältigen Änderungen reibungslos. Für sie ist eine Erneuerung im Wesentlichen ein Softwarevorgang, der vollständig automatisiert werden kann. Diese Asymmetrie ist beabsichtigt, da die übergeordnete Strategie die automatisierte, zentral verwaltete Signierung gegenüber der manuellen Token-Verwaltung bevorzugt.

Betriebliche Auswirkungen

Erneuerungshäufigkeit

Die Anhebung der Gültigkeitsdauer von 39 Monaten auf 460 Tage bedeutet, dass Zertifikate mindestens alle 15 Monate erneuert werden müssen. Innerhalb eines festen Zeitraums entspricht dies mehr als doppelt so vielen Erneuerungen. Für einen Herausgeber, der mehrere Signaturzertifikate für verschiedene Produkte und Build-Systeme verwendet, muss jede Erneuerung so geplant und durchgeführt werden, dass die Release-Pipelines nicht beeinträchtigt werden.

Automatisierungsanforderung

Die manuelle Nachverfolgung mithilfe von Tabellenkalkulationen und Kalendererinnerungen ist bei häufigeren Verlängerungen nur bedingt praktikabel. Eine versäumte Verlängerung kann eine Veröffentlichung blockieren oder Binärdateien ausliefern, die SmartScreen-Warnungen auslösen. Zertifikatslebenszyklusmanagement Die praktische Steuerung erfolgt durch Tools, die Signaturzertifikate erkennen, deren Ablauf überwachen und die Erneuerung über CA-APIs orchestrieren. Dieser Automatisierungsdruck treibt auch die parallele Reduzierung der TLS-Zertifikatslebensdauer auf 47 Tage bis 2029 gemäß der CA/Browser Forum-Abstimmung SC-081v3 voran.

Kontinuität durch Zeitstempelung

Da zeitgestempelte Signaturen auch nach Ablauf des Signaturzertifikats gültig bleiben, sollte jeder Signiervorgang einen Zeitstempel einer zuverlässigen Zertifizierungsstelle enthalten. Dies trennt die Langlebigkeit veröffentlichter Software von der kürzeren Gültigkeitsdauer des Zertifikats und verhindert, dass sich die Gültigkeitsänderung auf bereits im Einsatz befindlichen Code auswirkt.

Einhaltung der Vorschrift, da diese nun in Kraft getreten ist

Mit der nun geltenden 460-Tage-Frist müssen alle neuen und verlängerten Zertifikate diesen Anforderungen entsprechen. Die folgenden Schritte gewährleisten die Konformität einer Organisation und führen von einer manuellen, reaktiven Bearbeitung zu einem kontrollierten Lebenszyklus.

1. Erstellen Sie ein Inventar aller Code-Signaturzertifikate über alle Teams, Build-Server und Produkte hinweg und erfassen Sie den jeweiligen Eigentümer sowie den Speicherort der privaten Schlüssel.
2. Klassifizieren Sie die Schlüsselspeicherung nach Typ, indem Sie physische USB-Token-Workflows von Cloud- oder HSM-gestützten Schlüsseln trennen und die tokenbasierten für die Modernisierung priorisieren.
3. Setzen Sie auf die Automatisierung des Zertifikatslebenszyklusmanagements, um das Ablaufdatum zu überwachen, die Inhaber rechtzeitig vor Ablauf der Frist zu benachrichtigen und die Zertifikate, sofern unterstützt, über CA-APIs zu verlängern.
4. Erzwingen Sie die Vergabe eines Zeitstempels bei jedem Signiervorgang, damit die veröffentlichte Software auch nach Ablauf des Zertifikats gültig bleibt.
5. Härten Sie die Signaturumgebung gemäß den NIST-Richtlinien: HSM-gespeicherte Schlüssel, Trennung von Entwicklungs- und Produktionssignatur, Mehrparteiengenehmigung und isolierte Signatursysteme.
6. Führen Sie einen kompletten Erneuerungszyklus nach dem neuen Zeitplan durch, damit jede Erneuerung gemäß der 460-Tage-Regel ein Routinevorgang und keine Störung darstellt.
7. Die Bereitschaft zum Widerruf muss jederzeit gewährleistet sein, mit einem festgelegten Prozess zum schnellen Widerruf und zur Neusignierung, falls der Verdacht besteht, dass ein Schlüssel kompromittiert wurde, da das Ablaufdatum allein keinen ausreichenden Schutz bietet.

Die neuen Anforderungen mit CodeSign Secure von Encryption Consulting erfüllen

Eine kürzere Gültigkeitsdauer macht die Codesignierung zu einem wiederkehrenden Lebenszyklusproblem anstatt zu einer Aufgabe, die nur alle paar Jahre anfällt – und genau hier spielt eine zentrale Signaturplattform ihre Stärken aus. CodeSign Secure ist eine zentrale, sichere und skalierbare Codesignatur-Plattform, die Unternehmen dabei unterstützt, Code sicher und zuverlässig zu signieren, ohne Kompromisse bei Sicherheit oder Geschwindigkeit einzugehen. Sie ist für moderne DevOps-Umgebungen konzipiert und lässt sich nahtlos in CI/CD-Pipelines wie Azure DevOps, Jenkins und GitLab integrieren. Gleichzeitig gewährleistet sie durch strenge Zugriffskontrollen und Genehmigungsworkflows einen reibungslosen und regelkonformen Signaturprozess, insbesondere bei häufigeren Lizenzverlängerungen.

auf die Gültigkeitsänderung abgestimmte Fähigkeiten

Mehrere Funktionen von CodeSign Secure lassen sich direkt den Kontrollen zuordnen, zu denen die neue Obergrenze von 460 Tagen Unternehmen drängt:

• HSM-gestützte Schlüsselsicherheit. Private Schlüssel werden in FIPS 140-2 Level 3 HSMs gespeichert, die die Hardware-Speicheranforderungen des CA/Browser Forums übertreffen, mit Unterstützung für Entrust nCipher, Thales Luna, Utimaco und Securosys auf On-Premises- und Cloud-HSMs.
• Richtlinienbasierte Zugriffskontrolle. Die Integration mit Active Directory und Keycloak, die detaillierte rollenbasierte Zugriffskontrolle und mehrstufige Genehmigungsworkflows gewährleisten die Trennung von Zuständigkeiten. Daher wird kein Artefakt signiert, solange es nicht den erforderlichen Zertifikatstyp, die Signaturstufe und die erforderlichen Genehmigungen erfüllt. Dies implementiert direkt die vom NIST für die Codesignierung empfohlene Mehrparteiengenehmigung und Schlüsselisolation.
• Nahtlose CI/CD-Integration. Sicherheitsprüfungen und Integritätsvalidierungen verhindern, dass unsignierte Artefakte in die Produktion gelangen. Zentralisierte Nachverfolgung und sofortige Benachrichtigungen bei unautorisierten Signierungsversuchen gewährleisten die Konformität von Hochgeschwindigkeits-Pipelines auch bei häufigeren Erneuerungszyklen.
• Breites Spektrum an Format- und Plattformunterstützung. Die Signierung umfasst .exe-, .dll-, .jar-, .apk-, .dmg-Dateien, Docker-Container und Firmware-Binärdateien unter Windows, Linux und macOS und integriert sich mit einem benutzerdefinierten PKCS11-Wrapper und Tools wie Signtool, Jarsigner und JSign.
• Clientseitiges Hashing und sichere Zeitstempelung. Hashes werden clientseitig über einen benutzerdefinierten Key Storage Provider für das CNG-Framework von Microsoft generiert, und sichere Zeitstempel gewährleisten die Gültigkeit der Signatur nach Ablauf des Zertifikats, was bei kürzeren Gültigkeitszeiträumen unerlässlich ist.
• Umfassende Prüfprotokolle. Detaillierte Ereignisprotokolle erfassen jedes Genehmigungs-, Ablehnungs- und Unterzeichnungsereignis zur Überprüfung der Compliance und zur Untersuchung von Vorfällen. Die SIEM-Integration für Grafana, Loki und Splunk erfolgt über OpenTelemetry.
• Flexible Bereitstellungsmodelle. Organisationen können einen vollständig verwalteten Cloud-basierten Dienst mit integrierter HSM-Sicherheit und vollem API-Zugriff nutzen oder ihn lokal bereitstellen und dabei die Schlüssel in Cloud-HSMs, lokalen HSMs oder beidem verwalten.
• Unterstützung für Post-Quanten-Kryptographie. CodeSign Secure unterstützt die vom NIST anerkannten quantenresistenten Signaturverfahren ML-DSA und LMS direkt auf dem HSM sowie die Dual-Signatur, die ein klassisches RSA oder ECDSA Signatur mit einer postquantenmechanischen Signatur für einen graduellen Übergang.

Egal ob Sie Dutzende von Signaturidentitäten in verteilten Teams verwalten, Hochgeschwindigkeits-CI/CD-Pipelines betreiben oder in Branchen wie der Automobilindustrie, dem Gesundheitswesen oder der Finanztechnologie unter strengen Compliance-Vorgaben arbeiten, CodeSign Secure übernimmt den zusätzlichen Aufwand für die Erneuerung, der durch das 460-Tage-Limit entsteht, und macht die Codesignierung zu einem geregelten, automatisierten Lebenszyklus.

Fazit

Die Reduzierung der Gültigkeitsdauer von Codesignaturzertifikaten auf 460 Tage erzwingt eine kürzere kryptografische Periode für Signaturschlüssel, verringert das Zeitfenster für den Missbrauch kompromittierter Zertifikate und bringt die Codesignatur in Einklang mit dem automatisierungsgetriebenen Modell, das TLS bereits grundlegend verändert. Jüngste Vorfälle mit AnyDesk, Hijack Loader, Microsoft Trusted Signing und dem großflächigen Missbrauch signierter Treiber führen alle zu demselben Schluss: Langlebige, unzureichend regulierte Signaturzertifikate stellen ein Risiko dar, und die Begrenzung ihrer Gültigkeitsdauer ist eine sinnvolle Risikominderungsmaßnahme.

Für Organisationen, die Zertifikate noch manuell verwalten und auf physische Token setzen, bedeutet dies vor allem häufigere Erneuerungen. Für diejenigen, die die Codesignierung als automatisierten Lebenszyklus mit Erkennung, Überwachung, Zeitstempelung und hardwaregestützten Schlüsseln handhaben, ist die Umstellung hingegen nur eine geringfügige Anpassung. Da der Stichtag 1. März 2026 bereits verstrichen ist, ist die Umstellung nun keine Option mehr, sondern eine zwingende betriebliche Voraussetzung.