Beveiligde codeondertekening: Verkorte certificaatgeldigheid tot 460 dagen

Als u binnen uw organisatie codeondertekening beheert, is de branche onlangs van mening veranderd en is de deadline al verstreken. Op 1 maart 2026 is Ballot CSC-31, formeel aangenomen door het CA/Browser Forum op 17 november 2025, in werking getreden. Deze wijziging verkort de maximale geldigheidsduur van alle publiekelijk erkende codeondertekeningscertificaten van 39 maanden (ongeveer 3 jaar) naar 460 dagen (ongeveer 15 maanden). Elk codeondertekeningscertificaat dat op of na 1 maart 2026 is uitgegeven, moet aan deze nieuwe limiet voldoen.

Voor ontwikkelteams die tot nu toe werkten met een 'instellen en vergeten'-vernieuwingscyclus, waarbij elke twee of drie jaar een verlenging plaatsvond, verandert deze wijziging fundamenteel de rol van codeondertekening in het software-releaseproces. Wat voorheen een administratieve taak was die eens in de drie jaar plaatsvond, is nu een terugkerende, operationeel belangrijke verplichting die bewust beheerd en in de meeste gevallen geautomatiseerd moet worden.

In deze blog leggen we precies uit wat er is veranderd, waarom het CA/Browser Forum deze beslissing heeft genomen, wie er het meest door wordt getroffen en, belangrijker nog, wat uw team nu moet doen om aan de regelgeving te blijven voldoen en de ondertekeningsprocessen zonder onderbrekingen te laten verlopen.

De geldigheidsduur van een codeondertekeningscertificaat is 460 dagen, gedefinieerd als de maximale levensduur die het CA/Browser Forum toestaat voor een publiek vertrouwd codeondertekeningscertificaat dat is uitgegeven op of na 1 maart 2026. Dit is een verlaging ten opzichte van de 39 maanden onder Ballot CSC-31 (aangenomen op 17 november 2025), waardoor de frequentie waarmee elk ondertekeningscertificaat van een organisatie moet worden gecontroleerd, vernieuwd en, indien de sleutelopslag nog steeds afhankelijk is van fysieke tokens, fysiek vervangen, ruwweg verdrievoudigd wordt.

Key Takeaways

• Stemming CSC-31 werd op 14 oktober 2025 goedgekeurd, de IPR-beoordeling werd afgerond en het voorstel werd op 17 november 2025 formeel aangenomen (publicatie van Code Signing Baseline Requirements v3.10.0) en trad in werking op 1 maart 2026. Certificaten die vóór die datum zijn uitgegeven, behouden hun oorspronkelijke geldigheid; voor certificaten die op of na die datum zijn uitgegeven, geldt een maximale geldigheidsduur van 460 dagen, zonder respijtperiode.
• Dit is de meest gedetailleerde en gezaghebbende pagina over deze specifieke stemming en de operationele gevolgen ervan. Zie voor meer informatie over hoe dit aansluit op de afzonderlijke verplichtingen van de EU-cyberveiligheidsverordening met betrekking tot dezelfde ondertekeningsinfrastructuur. CRA-nalevingsarchitectuur voor veilige codeondertekeningDit omvat beide regimes samen, in plaats van de stemuitslag hier te herhalen.
• Een kortere geldigheidsduur vermindert de noodzaak tot voorbereiding op intrekking niet, maar verandert de berekening: een gecompromitteerde sleutel kan nu maximaal 460 dagen in plaats van 39 maanden blootgesteld worden, maar een bevestigde inbreuk vereist nog steeds intrekking binnen 24 uur volgens de basisvereisten, en niet op het moment dat het certificaat verloopt.
• USB-hardwaretokens, die acceptabel zijn bij een cyclus van 3 jaar, worden een terugkerende operationele kostenpost bij een cyclus van 15 maanden; dit is de meest voorkomende reden waarom organisaties na deze verandering overstappen op HSM-ondertekening, en niet ervoor.

Wat is er veranderd en wanneer?

De Code Signing Certificate Working Group van het CA/Browser Forum heeft stembiljet CSC-31 ingediend om de basisvereisten voor de uitgifte en het beheer van publiekelijk vertrouwde codeondertekeningscertificaten , versie 3.9, bij te werken.

Hier is de tijdlijn:

Milestone	Datum
Stembiljet CSC-31 voorgesteld	September 2025
Stemming goedgekeurd door CA/B Forum	October 14, 2025
De IPR-evaluatieperiode is afgerond en de stemming is formeel aangenomen.	November 17, 2025
Nieuwe basisvereisten voor codeondertekening v3.10.0 gepubliceerd	November 17, 2025
De nieuwe maximale geldigheidsduur van 460 dagen gaat in.	1 maart 2026

Certificaten die vóór 1 maart 2026 onder de oude regels zijn afgegeven, blijven geldig tot hun oorspronkelijke vervaldatum. Certificaten die op of na 1 maart 2026 worden afgegeven of verlengd, vallen echter onder de nieuwe maximale geldigheidsduur van 460 dagen. Er is geen respijtperiode voor nieuw afgegeven certificaten.

Waarom het CA/Browser Forum deze wijziging heeft doorgevoerd

De trend naar kortere certificatenlevensduur is niet willekeurig en ook niet nieuw. Het CA/Browser Forum verkort al jaren systematisch de geldigheidsduur van alle certificaattypen. De redenering hierachter is consistent en goed onderbouwd met beveiligingsprincipes.

1. De impact van een belangrijk compromis beperken: De privésleutel van een codeondertekeningscertificaat kan worden gecompromitteerd — door een datalek, ransomware, een interne dreiging of slechte praktijken bij het bewaren van sleutels. Onder de oude geldigheidsperiode van 39 maanden bleef een gecompromitteerde sleutel tot drie jaar bruikbaar voor een aanvaller, zelfs als het certificaat was ingetrokken (aangezien de controle op intrekking van certificaten inconsistent wordt toegepast op verschillende platforms).
   Een kortere levensduur beperkt direct de periode waarin een aanvaller kwetsbaar is. Als een sleutel op de eerste dag van een certificaat met een geldigheidsduur van 460 dagen wordt gecompromitteerd, heeft de aanvaller ongeveer 15 maanden de tijd om misbruik te maken in plaats van drie jaar.
2. Sterker sleutelbeheer: Wanneer een team zich drie jaar lang geen zorgen hoeft te maken over het ondertekeningscertificaat, verwateren de procedures voor sleutelopslag, toegangscontroles en auditsporen. Jaarlijkse of bijna jaarlijkse verlengingen dwingen organisaties ertoe hun infrastructuur voor ondertekening regelmatig te herzien: controleren wie toegang heeft, waar sleutels worden opgeslagen, of de opslagmethoden nog steeds aan de huidige normen voldoen en of de ondertekeningsworkflows nog steeds geschikt zijn.
3. Automatisering stimuleren: Iedere organisatie die code ondertekent met een publiekelijk erkend codeondertekeningscertificaat wordt hierdoor getroffen. Kortere geldigheidsperioden maken handmatig beheer steeds onpraktischer, wat de invoering van geautomatiseerde tools versnelt.

Het USB-tokenprobleem

Het is de moeite waard om even specifiek stil te staan ​​bij het probleem met de USB-hardwaretokens, omdat dit voor veel ontwikkelteams de grootste operationele uitdaging vormt die de wijziging van 460 dagen met zich meebrengt.

De basisvereisten van het CA/Browser Forum schrijven al jaren voor dat privésleutels voor publiekelijk vertrouwde codeondertekeningscertificaten moeten worden opgeslagen op hardware die voldoet aan de FIPS 140-2 Level 2- of Common Criteria EAL 4+-standaarden. Veel organisaties voldeden aan deze eis door codeondertekeningscertificaten uit te geven op USB-hardwaretokens die rechtstreeks door de certificeringsinstantie werden verzonden – een model dat voldeed aan de eis voor hardwarematige sleutelopslag zonder dat de organisatie een eigen HSM-infrastructuur hoefde te beheren.

Het ondertekenen met USB-tokens bracht zelfs onder de oude geldigheidsperiode van 39 maanden al eigen problemen met zich mee:

• Tokens konden verloren, beschadigd of gestolen worden, en voor vervanging was een nieuwe uitgifte van het certificaat nodig.
• Voor het ondertekenen was fysieke toegang tot het token vereist, wat knelpunten veroorzaakte voor teams op afstand en geautomatiseerde CI/CD-pipelines.
• Tokens konden niet eenvoudig worden geback-upt, waardoor er een enkel zwak punt ontstond voor de ondertekeningsprocedure.

Bij een geldigheidsperiode van 460 dagen komen al deze problemen vaker terug. De tokenlogistiek die beheersbaar was bij een cyclus van drie jaar, wordt een terugkerende operationele last bij een cyclus van 15 maanden.

Het praktische antwoord, en de richting die de industrie duidelijk opgaat, is de migratie van USB-tokens naar een cloudgebaseerde of on-premises HSM-infrastructuur die toegankelijk is via een gecentraliseerd ondertekeningsplatform. Deze aanpak slaat de privésleutel op in FIPS-compatibele hardware, maakt het mogelijk om ondertekeningsbewerkingen via een API uit te voeren vanuit elk geautoriseerd buildsysteem, elimineert de logistiek van fysieke tokens volledig en integreert naadloos met een gecentraliseerd codeondertekeningsplatform.

Waarom tijdstempels nu nog belangrijker zijn

Een van de belangrijkste technische overwegingen bij kortere certificatenlevensduren is tijdstempeling. Wanneer een codeondertekeningscertificaat verloopt, wordt software die met dat certificaat is ondertekend niet automatisch als onbetrouwbaar beschouwd. Als de ondertekeningshandeling een geldige RFC 3161-tijdstempel van een vertrouwde Timestamping Authority (TSA) bevatte, blijft de handtekening onbeperkt verifieerbaar, zelfs nadat het certificaat is verlopen. De tijdstempel levert cryptografisch bewijs dat de ondertekeningshandeling plaatsvond toen het certificaat geldig was, en dat bewijs blijft geldig na de geldigheidsperiode van het certificaat.

Zonder tijdstempel is de betrouwbaarheid van het ondertekende document direct gekoppeld aan de geldigheidsperiode van het certificaat. Zodra het certificaat verloopt, zullen verificatiesystemen die de certificaatvaliditeit controleren de handtekening afwijzen. Voor alle software met een levensduur van meer dan 15 maanden, waaronder vrijwel alle bedrijfsapplicaties, drivers, firmware-images en langlopende uitvoerbare bestanden, betekent een ontbrekende of onjuist aangebrachte tijdstempel dat de software uiteindelijk zijn betrouwbare status verliest.

Bij jaarlijkse vernieuwing van certificaten vormt elk ondertekend document zonder een correcte RFC 3161-tijdstempel binnen 15 maanden na ondertekening een potentieel probleem. De praktische stappen zijn als volgt:

• Controleer of uw ondertekeningssoftware standaard RFC 3161-tijdstempels toepast op elke ondertekeningsbewerking.
• Configureer uw ondertekeningspipelines zodanig dat een ontbrekende tijdstempel wordt behandeld als een ondertekeningsfout en niet als een waarschuwing.
• Zorg ervoor dat tijdstempels worden toegepast met behulp van SHA-256-hashing (niet SHA-1, dat over het algemeen wordt afgekeurd).
• Controleer voor artefacten met een lange levensduur (firmware, drivers, bedrijfssoftware) of uw tijdstempelconfiguratie ook correct is toegepast op alle historische artefacten.

Intrekking binnen de nieuwe geldigheidsperiode

Een kortere geldigheidsduur wordt soms omschreven als een vermindering van de noodzaak tot intrekking. Dat klopt niet helemaal: het verkleint de maximale blootstelling die een inbreuk kan veroorzaken, maar het verandert niets aan de intrekkingsplicht zelf. Volgens de Code Signing Baseline Requirements §4.9.1.1 moet een CA een certificaat nog steeds binnen 24 uur intrekken nadat is vastgesteld dat de privésleutel is gecompromitteerd, zowel voor een certificaat met een geldigheidsduur van 460 dagen als voor een certificaat met een geldigheidsduur van 39 maanden. Wat de kortere periode wel verandert, is de maximale periode waarin een aanvaller de sleutel kan misbruiken: als een sleutel de dag na uitgifte wordt gecompromitteerd en dit niet wordt ontdekt, daalt de maximale periode waarin een aanvaller deze theoretisch zou kunnen misbruiken van ongeveer drie jaar naar ongeveer 15 maanden.

De praktische implicatie voor uw auditchecklist: bevestig dat uw organisatie binnen een uur na een vermoeden van een inbreuk elk artefact kan identificeren dat is ondertekend met een specifiek certificaat. Wachten tot een certificaat simpelweg verloopt, is geen intrekkingsplan, en de snellere vernieuwingsfrequentie die deze wijziging met zich meebrengt, is geen vervanging voor een geteste reactie op een inbreuk.

Oude versus nieuwe eisen, naast elkaar.

eis	Vóór 1 maart 2026	Op of na 1 maart 2026
Maximale geldigheidsduur van het certificaat	39 maanden	460 dagen
Vernieuwingsfrequentie (typisch)	Ongeveer elke 3 jaar	Ongeveer elke 15 maanden
Tijdschema voor intrekking van sleutels bij bevestigde inbreuk op de beveiliging	24 uur (ongewijzigd)	24 uur (ongewijzigd)
Opslag van privésleutels	FIPS 140-2 Level 2+ of Common Criteria EAL4+ hardware (sinds juni 2023)	Dezelfde eis, ongewijzigd
Maximale theoretische blootstelling als gevolg van een onopgemerkt sleutelcompromitteerd geval	Tot ongeveer 39 maanden	Tot ongeveer 460 dagen

Auditchecklist: Wat u nu moet doen

Als uw organisatie de impact van de 460-dagenwijziging nog niet heeft beoordeeld, is dit een praktisch uitgangspunt:

Stap 1 — Controleer uw inventaris van codeondertekeningscertificaten. Identificeer elk openbaar vertrouwd codeondertekeningscertificaat dat uw organisatie gebruikt. Noteer voor elk certificaat de vervaldatum, de opslagmethode (USB-token, HSM, cloud-HSM, softwareopslag), welke ondertekeningsworkflows of -pipelines ervan afhankelijk zijn en wie verantwoordelijk is voor de verlenging. Als u deze informatie niet centraal hebt gedocumenteerd, is het aanmaken van een inventaris de eerste prioriteit.

Stap 2 — Identificeer certificaten die al onder de nieuwe regels vallen. Elk certificaat dat op of na 1 maart 2026 is uitgegeven, heeft een geldigheidsduur van maximaal 460 dagen. Bepaal welke van uw certificaten in deze categorie vallen en plan verlengingsmomenten met voldoende voorbereidingstijd in — plan de verlenging ten minste 30 tot 60 dagen vóór de vervaldatum om tijd te hebben voor aanschaf, inbedrijfstelling en updates van de pijplijn.

Stap 3 — Beoordeel uw belangrijkste opslaginfrastructuur. Als uw organisatie USB-hardwaretokens gebruikt, evalueer dan of migratie naar een cloud-HSM of een on-premises HSM met toegang via een gecentraliseerd ondertekeningsplatform geschikt is. Gezien de terugkerende logistiek van het vernieuwen van USB-tokens met tussenpozen van 15 maanden, zal deze migratie waarschijnlijk al binnen de eerste vernieuwingscyclus kosteneffectief zijn.

Stap 4 — Controleer de tijdstempelconfiguratie. Controleer uw ondertekeningspipelines om te bevestigen dat RFC 3161-tijdstempels worden toegepast op elke ondertekeningsbewerking, met behulp van SHA-256, en behandel een ontbrekende tijdstempel als een blokkerende fout in uw pipeline.

Stap 5 — Werk de pipelineconfiguraties bij voor dynamische certificaatverwijzingen. Controleer alle CI/CD-pipelineconfiguraties , buildscripts en configuraties van ondertekeningstools die verwijzen naar ondertekeningscertificaten. Vervang statische identificaties door dynamische verwijzingen die niet handmatig hoeven te worden bijgewerkt bij elke verlenging.

Stap 6 — Evalueer de automatisering van het certificaatlevenscyclusbeheer. Als uw organisatie een aanzienlijk aantal certificaten beheert voor meerdere teams of producten, overweeg dan een speciaal, gecentraliseerd platform voor certificaatondertekening dat de detectie, waarschuwingen voor verlenging en geïntegreerde implementatie in de pipeline kan automatiseren.

Hoe CodeSign Secure van Encryption Consulting helpt

CodeSign Secure is het gecentraliseerde, op beleid gebaseerde platform voor het ondertekenen van code van Encryption Consulting. Het is specifiek ontworpen voor de omgeving die de 460-dagenwijziging versnelt: een omgeving waarin ondertekeningsprocessen geautomatiseerd moeten zijn, sleutels centraal beheerd moeten worden in een HSM-ondersteunde infrastructuur en gebeurtenissen in de certificaatlevenscyclus moeten worden bijgehouden en afgehandeld zonder dat individuele ontwikkelaars hiervan op de hoogte hoeven te zijn.

Gecentraliseerd sleutelbeheer met HSM-ondersteuning

CodeSign Secure slaat alle privésleutels voor ondertekening op in FIPS 140-2 Level 3 gecertificeerde hardwarebeveiligingsmodules (HSM's), waardoor het USB-tokenmodel volledig overbodig wordt. Het platform integreert met Thales Luna, Entrust nCipher, Utimaco, Securosys en belangrijke cloud-HSM's van AWS en Azure. Privésleutels worden gegenereerd binnen de HSM, nooit geëxporteerd en zijn alleen toegankelijk via de ondertekenings-API van het platform.

Certificaatlevenscyclus en -vernieuwing: waarschuwingen

CodeSign Secure beheert een gecentraliseerd overzicht van alle certificaten, met inzicht in de vervaldatum en configureerbare waarschuwingen voor verlenging. Beveiligings- en operationele teams ontvangen tijdig een melding voordat certificaten verlopen, waardoor het risico op het ontdekken van een verlopen certificaat wordt geëlimineerd.

Integratie van CI/CD-pijplijn

Het platform integreert naadloos met Azure DevOps, Jenkins, GitLab CI en andere belangrijke pipeline-systemen via zowel API- als commandoregelinterfaces. Ondertekeningsbewerkingen worden uitgevoerd door de pipeline die dynamisch via het platform verwijst naar het actuele, geldige certificaat, in plaats van naar een statische certificaatreferentie. Wanneer een certificaat wordt vernieuwd, worden de ondertekeningsbewerkingen van de pipeline zonder onderbreking voortgezet en is het niet nodig om de pipelineconfiguratie aan te passen.

Post-kwantum gereedheid

Naarmate de certificaatindustrie overstapt op kortere levensduur, bereidt ze zich ook voor op de migratie naar post-kwantumcryptografie, die NIST al heeft gestandaardiseerd. CodeSign Secure v3.02 ondersteunt ML-DSA (FIPS 204) voor ondertekening door middel van verwijderbare handtekeningen, waardoor organisaties hun infrastructuur voor codeondertekening kunnen overzetten naar kwantumresistente algoritmen met behoud van compatibiliteit met bestaande platforms.

Veelgestelde Vragen / FAQ

Geldt de termijn van 460 dagen ook voor certificaten die ik al heb?

Nee. Certificaten die vóór 1 maart 2026 zijn uitgegeven, behouden hun oorspronkelijke geldigheidsperiode en vervaldatum. De limiet van 460 dagen geldt alleen voor certificaten die op of na die datum zijn uitgegeven of verlengd, zonder respijtperiode.

Betekent een kortere geldigheidsduur dat ik me minder zorgen hoef te maken over intrekking?

Nee. Een bevestigde inbreuk op de sleutel vereist nog steeds intrekking binnen 24 uur volgens de Code Signing Baseline Requirements, op een certificaat met een geldigheidsduur van 460 dagen, net als bij het oude certificaat van 39 maanden. Een kortere geldigheidsduur verkort alleen de maximale blootstellingsperiode als een inbreuk onopgemerkt blijft; het vervangt niet de noodzaak van een getest intrekkingsproces.

Moet ik me nog steeds zorgen maken over het verlopen van certificaten als ik gebruik maak van vertrouwde tijdstempels?

Voor reeds ondertekende en uitgebrachte software geldt het volgende: een geldige RFC 3161-tijdstempel zorgt ervoor dat de handtekening na het verlopen van het certificaat verifieerbaar blijft. U moet het certificaat zelf echter wel verlengen vóór de vervaldatum om nieuwe releases te kunnen blijven ondertekenen.

Is het verplicht om na deze wijziging over te stappen van USB-tokens naar een ander type token?

Niet verplicht, maar wel sterk aanbevolen vanuit economisch oogpunt. Dezelfde FIPS 140-2 Level 2+ hardwarevereiste geldt ongeacht of u een token of een HSM gebruikt; een vernieuwingscyclus van 460 dagen zorgt er alleen voor dat de terugkerende logistieke problemen rond de vervanging, het verlies en de CI/CD-knelpunten van fysieke tokens veel vaker voorkomen dan bij een cyclus van 3 jaar.

Hoe verschilt dit van de CRA-nalevingsvereisten voor codeondertekening?

Het zijn twee aparte regelgevingen. Deze stemming betreft een brancheregel van CA/Browser Forum over de levenscyclus van certificaten; de EU Cyber ​​Resilience Act is een aparte wettelijke verplichting met betrekking tot de integriteit van firmware op productniveau en de openbaarmaking van kwetsbaarheden. Een organisatie die producten onder de CRA-regelgeving ondertekent, moet aan beide voldoen; zie CRA Compliance Architecture for Secure Code Signing voor meer informatie over de overlapping tussen beide.

Conclusie

De wijziging van de 460-dagen geldigheidsduur van codeondertekeningscertificaten, die op 1 maart 2026 van kracht werd, is niet het einde van dit verhaal. Het is een stap in een richting die het CA/Browser Forum al jaren consequent nastreeft. De organisaties die deze veranderingen met de minste verstoring zullen doorstaan, zijn de organisaties die certificaatlevenscyclusbeheer beschouwen als een gedisciplineerde, geautomatiseerde functie op infrastructuurniveau – en niet als een periodieke handmatige taak.

Voor ontwikkelteams die nog steeds afhankelijk zijn van USB-tokens en handmatige herinneringen voor verlenging, is de overgang naar 460 dagen het juiste moment om te beoordelen of die aanpak houdbaar is. De logistiek van jaarlijkse tokenvervanging, updates van de pipelineconfiguratie en handmatige controle van de verlenging voor meerdere certificaten zal snel toenemen naarmate de geldigheidsperioden korter worden.

Bij Encryption Consulting is ons CodeSign Secure- platform ontworpen om die overgang praktisch te maken. Het biedt uw team HSM-ondersteunde sleutelbeveiliging, geautomatiseerd certificaatbeheer en in de pipeline geïntegreerde ondertekening die verlengingen afhandelt zonder handmatige tussenkomst.