De levensduur van codeondertekeningscertificaten wordt steeds korter.

Codeondertekeningscertificaten authenticeren software voordat deze de eindgebruikers bereikt. Ze bevestigen dat een binair bestand, installatieprogramma of update afkomstig is van een geverifieerde uitgever en niet is gewijzigd tijdens de overdracht. Jarenlang was het operationele model rondom deze certificaten eenvoudig: verkrijg een certificaat met een geldigheidsduur van meerdere jaren, bewaar het in een ontwikkelomgeving en verleng het wanneer de vervaldatum naderde. Dat model creëerde een stilzwijgend, maar reëel risico, omdat een certificaat dat 39 maanden geldig is, betekent dat een gecompromitteerde privésleutel gedurende die hele periode vertrouwd blijft, tenzij iemand het ontdekt en het certificaat tijdig intrekt.

Volgens CA/Browser Forum Ballot CSC-31, aangenomen op 17 november 2025 en opgenomen in de Code Signing Baseline Requirements versie 3.10.0, is de maximale geldigheidsduur voor publiekelijk vertrouwde codeondertekeningscertificaten verlaagd van 39 maanden naar 460 dagen, een afname van ongeveer 15 maanden. Elk codeondertekeningscertificaat dat op of na 1 maart 2026 is uitgegeven, moet aan deze limiet voldoen. Certificaten die vóór die datum zijn uitgegeven, blijven geldig tot hun natuurlijke vervaldatum, maar bij verlenging is de nieuwe termijn van toepassing.

Dit is geen op zichzelf staand geval. Het volgt dezelfde trend als TLS-certificaten , waarvan de geldigheidsduur is verkort van 398 dagen naar 200 dagen met ingang van 15 maart 2026, en die naar verwachting verder zal dalen naar 100 dagen op 15 maart 2027 en 47 dagen op 15 maart 2029, volgens CA/B Forum Ballot SC-081v3, dat in april 2025 is aangenomen. Codeondertekening en TLS komen steeds meer samen in hetzelfde principe: certificaten zouden niet langer geldig moeten zijn dan de vertrouwensvoorwaarden waaronder ze zijn uitgegeven. De industrie zet in op automatisering om dit praktisch te maken.

Deze blog beschrijft wat er is veranderd, waar de risico's liggen en wat organisaties moeten aanpakken vóór de volgende verlengingscyclus.

Waarom de geldigheidsduur van certificaten steeds korter wordt

De overstap naar kortere certificatenlevensduren is niet willekeurig. Het pakt twee problemen aan die al lange tijd bestaan ​​in openbare PKI-systemen: de kloof tussen het moment waarop een certificaat wordt gecompromitteerd en het moment waarop het daadwerkelijk niet meer wordt vertrouwd, en de trage overgang van organisaties naar sterkere cryptografische standaarden wanneer hun bestaande certificaten nog prima functioneren.

Wanneer een privésleutel voor het ondertekenen van documenten openbaar wordt gemaakt, blijft het bijbehorende certificaat geldig totdat het verloopt of wordt ingetrokken. Intrekking kent bekende betrouwbaarheidsproblemen. Certificaatintrekkingslijsten (CRL's) en het Online Certificate Status Protocol (OCSP) worden niet door alle platforms consequent gecontroleerd, en wanneer een intrekkingscontrole mislukt of een time-out bereikt, beschouwen de meeste systemen dit als een geslaagde controle in plaats van een geblokkeerde controle.

Het gevolg is dat een gecompromitteerd certificaat een bruikbaar aanvalsinstrument kan blijven zolang het vertrouwd wordt. Onder het vorige model met een geldigheidsduur van 39 maanden kon een compromittering van één enkele sleutel een organisatie potentieel meer dan drie jaar aan risico blootstellen. Met de nieuwe limiet van 460 dagen wordt de maximale blootstellingsperiode aanzienlijk verkort.

Het tweede probleem is dat organisaties de werkende certificaten vaak niet tijdig vervangen, zelfs niet wanneer er betere algoritmes beschikbaar zijn. De sector heeft dit ondervonden tijdens de uitfasering van SHA-1 en de overstap van 1024-bits RSA-sleutels. Beide overgangen sleepten veel langer aan dan nodig, omdat langlopende certificaten organisaties geen natuurlijke deadline boden om actie te ondernemen.

Kortere geldigheidsperioden veranderen dat. Elke verlenging is een kans om de huidige standaarden te implementeren. Dit is met name belangrijk nu, aangezien NIST in augustus 2024 zijn eerste post-kwantumcryptografiestandaarden heeft afgerond : FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA). Organisaties die hun certificaten regelmatig verlengen, zullen veel beter in staat zijn om kwantumresistente algoritmen te implementeren naarmate de platform- en CA-ondersteuning zich verder ontwikkelt.

Kortere certificaten hebben een beperktere levensduur, waardoor de schade bij een beveiligingslek kleiner wordt, de afhankelijkheid van intrekkingsmechanismen die niet altijd werken afneemt en de cryptografische standaarden binnen het ecosysteem actueel blijven. Het toepassen hiervan op codeondertekeningscertificaten is een directe stap richting een sterkere beveiliging van de softwareleveringsketen . Stemming CSC-31 formaliseerde deze stap met een specifieke maximale geldigheidsduur en een vaste ingangsdatum voor alle publiekelijk vertrouwde codeondertekeningscertificaten.

Wat is er nu precies veranderd aan stembiljet CSC-31?

Het CA/B Forum-voorstel CSC-31 werd ingediend door Microsoft. De stemperiode sloot op 13 oktober 2025 en het voorstel werd formeel aangenomen op 17 november 2025, na de beoordelingsperiode voor intellectueel eigendom. Zeven van de negen leden van de Certificate Issuer-groep stemden voor, twee onthielden zich van stemming en er was geen tegenstem. De enige stem van de Certificate Consumer, uitgebracht door Microsoft, was eveneens voor. De beoordelingsperiode voor intellectueel eigendom sloot op 17 november 2025, zonder dat er uitsluitingsmeldingen werden ingediend.

De bijgewerkte versie 3.10.0 van de Code Signing Baseline Requirements is gepubliceerd op 17 november 2025, met een nieuwe geldigheidslimiet die ingaat op 1 maart 2026. Deze vereiste geldt voor alle publiekelijk vertrouwde code-ondertekeningscertificaten, oftewel certificaten uitgegeven door certificeringsinstanties (CA's) waarvan de rootcertificaten zijn opgenomen in de vertrouwensarchieven van besturingssystemen en browsers. Privé-PKI's die worden gebruikt voor interne ondertekeningsworkflows vallen niet onder de regels van het CA/B Forum, hoewel het afstemmen van interne werkwijzen op dezelfde standaard een redelijke aanpak is.

Een belangrijk praktisch detail: de limiet van 460 dagen wordt berekend vanaf de datum van uitgifte, niet vanaf de datum waarop de bestelling is geplaatst. Een certificaat dat vóór 1 maart 2026 is aangevraagd, maar op of na die datum is uitgegeven, valt onder de nieuwe limiet. De meeste certificeringsinstanties (CA's) zijn eind februari 2026 gestopt met het uitgeven van certificaten voor codeondertekening met een geldigheidsduur van 2 en 3 jaar om de deadline strikt te handhaven. Elk publiekelijk erkend certificaat voor codeondertekening dat vanaf 1 maart 2026 is uitgegeven, heeft een maximale geldigheidsduur van 460 dagen.

Het is op papier eenvoudig om aan de termijn van 460 dagen te voldoen. De lastigere vraag is echter of de bestaande infrastructuur voor het ondertekenen van documenten ooit is ontworpen om met dat tempo te werken.

Waarom de infrastructuur voor digitale handtekeningen hier niet op is gebouwd

De overstap van een certificaat van 39 maanden naar een certificaat van 460 dagen lijkt een simpele wijziging in de verlengingstermijn. In de praktijk legt het echter structurele problemen bloot in de manier waarop de meeste organisaties hun ondertekeningsprocessen hebben ingericht.

Het eerste punt betreft de opslag van sleutels. De Code Signing Baseline Requirements vereisen al dat privésleutels voor alle publiekelijk vertrouwde codeondertekeningscertificaten, zowel standaard Organization Validated (OV) als Extended Validation (EV), worden opgeslagen in een hardwarematige cryptografische module die voldoet aan ten minste Federal Information Processing Standards (FIPS) 140-2 Level 2 of Common Criteria EAL 4+. Aangezien FIPS 140-2-validaties op 21 september 2026 op de historische lijst komen te staan, zouden organisaties die nieuwe hardware aanschaffen prioriteit moeten geven aan modules met een actieve FIPS 140-3-validatie om te zorgen voor voortdurende naleving na die datum.

Voor standaard OV-certificaten worden vaak hardwaretokens zoals USB-apparaten gebruikt, maar dit brengt een probleem met zich mee op het gebied van fysiek beheer. Tokens kunnen verloren gaan, ze zijn gekoppeld aan specifieke personen en verlenging betekent dat de hardware opnieuw moet worden geconfigureerd. Bij een cyclus van 460 dagen vindt dit proces jaarlijks plaats in plaats van eens in de drie jaar, wat aanzienlijk meer werk met zich meebrengt en de kans op problemen vergroot als het niet goed wordt beheerd.

Het tweede probleem is de integratie van de pipeline. Veel buildsystemen ondertekenen artefacten met behulp van een certificaat en sleutel die handmatig in een bestandssysteempad, omgevingsvariabele of secrets manager-item zijn geplaatst. Wanneer het certificaat wordt vervangen, gaat er ergens in die keten een fout. Bij een cyclus van 460 dagen gebeurt die fout vaker. Teams zonder end-to-end automatisering van certificaatvoorziening, het genereren van Certificate Signing Requests (CSR's), de interactie met de certificeringsinstantie en de implementatie zullen merken dat dit schema moeilijk betrouwbaar te beheren is.

Het derde probleem is de inventaris. Een enkele organisatie kan tientallen codeondertekeningscertificaten hebben, verspreid over productlijnen, ontwikkelomgevingen en door externe partijen beheerde systemen. De teams die drie jaar geleden eigenaar waren van die certificaten, zijn mogelijk inmiddels vertrokken. Zonder een gecentraliseerd overzicht van wat er is, wie het bezit en wanneer het verloopt, wordt een vernieuwingscyclus van 460 dagen onbeheersbaar.

De structurele tekortkomingen in de infrastructuur voor het ondertekenen van certificaten zorgen niet alleen voor problemen bij verlenging; ze worden een ernstig risico zodra een certificaat in gevaar komt.

Wat gebeurt er als een codeondertekeningscertificaat wordt gecompromitteerd?

Een gecompromitteerd codeondertekeningscertificaat is niet zomaar een beveiligingsincident. Het is een operationele noodsituatie met een strikte deadline. Volgens de Code Signing Baseline Requirements versie 3.10.0 moet een certificeringsinstantie (CA) een codeondertekeningscertificaat intrekken binnen 24 uur nadat zij op de hoogte is gesteld dat het certificaat is gebruikt om malware te ondertekenen of dat de privésleutel is gestolen of openbaar gemaakt. Die termijn van 24 uur laat weinig ruimte voor een trage of ongeorganiseerde reactie.

Het directe probleem is de identificatie. Voordat een certificeringsinstantie (CA) actie kan ondernemen, moet het betreffende certificaat nauwkeurig worden geïdentificeerd: het serienummer, de uitgevende CA en de huidige intrekkingsstatus. Voor organisaties zonder een gecentraliseerde certificaatinventaris kan deze stap alleen al uren in beslag nemen. Als ondertekeningscertificaten verspreid zijn over teams, ontwikkelomgevingen en systemen van externe leveranciers zonder dat er één eigenaar is geregistreerd, is het vinden van het juiste certificaat onder druk niet eenvoudig.

Zodra een certificaat is ingetrokken, kan het niet meer worden gebruikt om iets nieuws te ondertekenen en publiceert de certificeringsinstantie (CA) de intrekking via haar CRL- en OCSP-infrastructuur. De controle op intrekking wordt echter niet consistent toegepast op alle platforms. Dit betekent dat een ingetrokken certificaat in sommige omgevingen nog enige tijd na de intrekking kan worden geaccepteerd, wat precies het gedrag is dat kortere certificatenlevensduren op de lange termijn moeten beperken.

Het vervangende certificaat moet vervolgens worden uitgegeven en geïmplementeerd in elke pipeline die afhankelijk was van het gecompromitteerde certificaat. Zonder gedocumenteerde pipeline-integratie en geautomatiseerde implementatie is dit wederom een ​​handmatige taak onder tijdsdruk. Organisaties met een door een Hardware Security Module (HSM) ondersteunde sleutelopslag zijn hier beter gepositioneerd, omdat de inbreuk doorgaans beperkt blijft tot het certificaat in plaats van de onderliggende hardware, en nieuwe sleutels binnen de HSM kunnen worden gegenereerd zonder dat fysieke tokens opnieuw hoeven te worden verstrekt aan alle teams.

De operationele les is eenvoudig: dezelfde tekortkomingen die een vernieuwingscyclus van 460 dagen moeilijk beheersbaar maken, zoals onvolledige certificaatinventarissen, handmatige ondertekeningsprocessen en in software opgeslagen privésleutels, zorgen er ook voor dat de incidentrespons trager en foutgevoeliger is. Het aanpakken van deze zwakke punten vóórdat een inbreuk plaatsvindt, is aanzienlijk goedkoper dan ze te proberen te verhelpen tijdens een actief incident.

Incidentafhandeling eindigt niet met het intrekken en vervangen van certificaten. Organisaties moeten ook begrijpen hoe tijdstempels de betrouwbaarheid en bruikbaarheid van eerder ondertekende software beïnvloeden.

De tijdstempelvraag die de meeste teams over het hoofd zien.

Een aspect van codeondertekening dat met name belangrijk is bij kortere certificatenlevensduur, is de tijdstempeling volgens RFC 3161. Wanneer een handtekening een vertrouwde tijdstempel van een Time-Stamping Authority (TSA) bevat , blijft de handtekening geldig tot na de vervaldatum van het certificaat.

De tijdstempel levert cryptografisch bewijs van wanneer de software is ondertekend, waardoor de handtekening geldig blijft, zelfs nadat het codeondertekeningscertificaat is verlopen, op voorwaarde dat de certificaatketen van de TSA geldig en betrouwbaar blijft op het moment van verificatie. Hierdoor verliest software die vóór het verlopen van het certificaat is ondertekend en gedistribueerd, niet automatisch het vertrouwen onder de nieuwe geldigheidslimiet van 460 dagen. 

Wat verandert, is de ondertekeningsreferentie zelf. Een geldig, niet-verlopen certificaat is vereist om nieuwe releases, nieuwe builds en bijgewerkte pakketten te ondertekenen. Zodra een codeondertekeningscertificaat is verlopen, kan het niet meer worden gebruikt om iets nieuws te ondertekenen, zelfs als oudere handtekeningen van dat certificaat nog geldig zijn. De impact is direct: elke onderbreking in de beschikbaarheid van certificaten stopt de softwarelevering. Bij een cyclus van 460 dagen biedt een gemiste verlenging geen drie jaar speling. Het stopt de pipeline op dag 461.

Deze operationele realiteit maakt één ding duidelijk: organisaties hebben workflows voor het ondertekenen van certificaten nodig die zijn ontworpen voor continue certificaatvernieuwing in plaats van incidentele certificaatvervanging.

Wat moet er veranderen in de workflows voor het ondertekenen van documenten?

Het voldoen aan de limiet van 460 dagen is slechts het begin. Het opzetten van een workflow die standhoudt tot de volgende verlaging, die waarschijnlijk zal plaatsvinden aangezien TLS-certificaten al op een meerjarig traject van verlagingen staan ​​gepland, vereist structurele veranderingen.

Begin met inventarisatie. Het beheren van codeondertekeningscertificaten met een vernieuwingscyclus van 460 dagen vereist inzicht in het aantal certificaten, de implementatie ervan, de processen die ervan afhankelijk zijn en de eigenaar van elk certificaat. Organisaties die nog steeds het oude model van 39 maanden hanteren, beschikken vaak niet over een bruikbare inventaris. Het opbouwen van deze inventaris is de eerste stap voordat andere processen geautomatiseerd of betrouwbaar beheerd kunnen worden.

Verplaats ondertekeningssleutels naar hardware. Privésleutels die zijn opgeslagen op bestandssystemen, ontwikkelmachines of buildservers moeten worden overgeplaatst naar een HSM (Hardware Security Module). HSM-gebaseerde opslag voldoet aan de FIPS 140-2 Level 2- minimumeisen die momenteel zijn vastgelegd in de Code Signing Baseline Requirements van het CA/B Forum, lost het probleem op van fysieke herinstallatie dat USB-tokens veroorzaken bij jaarlijkse verlengingscycli, en verkleint het risico dat een gecompromitteerde sleutel wordt gebruikt om kwaadaardige software te ondertekenen en te verspreiden. Omdat alle FIPS 140-2-validaties op 21 september 2026 naar de historische lijst worden verplaatst, moeten nieuwe hardware-aankopen zich richten op modules met een actieve FIPS 140-3-validatie.

Automatiseer het vernieuwingsproces. De CA/B Forum Code Signing Baseline Requirements schrijven automatisering niet voor, maar een cyclus van 460 dagen maakt handmatige vernieuwing onbetrouwbaar op grote schaal. Het genereren van Certificate Signing Requests (CSR's), de indiening bij de CA, de uitgifte en de implementatie moeten via een herhaalbare, controleerbare workflow verlopen in plaats van een handmatig proces dat enkele dagen voor de vervaldatum wordt gestart. Het Automatic Certificate Management Environment (ACME)-protocol, waar CA-ondersteuning beschikbaar is, elimineert handmatige stappen volledig uit het vernieuwingsproces.

Bereid je voor op de volgende verlaging. Codeondertekeningscertificaten volgen nu hetzelfde verlagingspad als TLS. Organisaties die vandaag de dag een infrastructuur voor geautomatiseerde ondertekening bouwen, kunnen toekomstige verlagingen van de geldigheidsduur opvangen zonder alles opnieuw te hoeven opbouwen. Organisaties die 460 dagen als een permanente limiet beschouwen, kunnen opnieuw met dezelfde problemen te maken krijgen wanneer de volgende stemming plaatsvindt.

Voor veel organisaties vereist het bereiken van dit niveau van operationele volwassenheid specialistische expertise, de juiste tools en een gefaseerde implementatiestrategie. Dat is waar Encryption Consulting bij kan helpen.

Hoe encryptieconsultancy kan helpen

CodeSign Secure is het codeondertekeningsbeheerplatform van Encryption Consulting, geschikt voor grote bedrijven, en is ontworpen om de infrastructuurcontrole te bieden die diverse sectoren nodig hebben.

Sleutelbeheer ondersteund door HSM

CodeSign Secure slaat alle privésleutels voor ondertekening op in FIPS 140-2 Level 3 gecertificeerde hardwarebeveiligingsmodules (HSM's) , en integreert met Thales Luna, Entrust nShield, Utimaco, Securosys en cloud-HSM's van AWS en Azure. Sleutelisolatie per product wordt afgedwongen op HSM-partitieniveau: elke productlijn ontvangt een eigen, specifieke sleutel die in de hardware wordt gegenereerd en nooit wordt geëxporteerd.

M-of-N ondertekeningsquorum en RBAC

Het op rollen gebaseerde toegangscontrolemodel van het platform dwingt M-van-N-goedkeuringsvereisten af ​​voor het ondertekenen van productiefirmware. Geen enkele persoon kan een ondertekeningsbewerking initiëren en goedkeuren. Ondertekeningsverzoeken, goedkeuringen en afwijzingen worden allemaal geregistreerd. De RBAC-configuratie zelf is controleerbaar en versiebeheerd, waardoor het gedocumenteerde ondertekeningsbeleid wordt geboden dat CRA-conformiteitsbeoordelingen vereisen.

Onveranderlijke auditlogboekregistratie

Elke ondertekeningsgebeurtenis in CodeSign Secure genereert een onveranderlijke logboekvermelding met de hash van het artefact, de sleutelidentificatie, het gebruikte certificaat, de goedkeurende identiteit en de RFC 3161-tijdstempel. De logboeken worden centraal opgeslagen, los van de infrastructuur voor ondertekening.

Ondersteuning voor platformonafhankelijke firmwareformaten

CodeSign Secure ondersteunt het ondertekenen van firmware-artefacten in alle formaten die een divers productportfolio vereist: .bin, .img, .hex, .fw, .dfu en .efi. Hiermee wordt voldaan aan de CRA-vereiste voor consistente controles over productlijnen heen, zonder dat de ondertekeningsinfrastructuur voor elk platform opnieuw hoeft te worden opgebouwd.

Ondersteuning voor post-kwantumcryptografie

CodeSign Secure v3.02 ondersteunt ML-DSA (FIPS 204, op beveiligingsniveaus ML-DSA-44, ML-DSA-65 en ML-DSA-87) en SLH-DSA (FIPS 205) van productiekwaliteit als afneembare handtekeningen naast klassieke algoritmen. Voor fabrikanten die producten bouwen met een CRA-ondersteuningsverplichting van vijf jaar of langer, is PQC-ondertekening vandaag de dag de architectuur die bescherming biedt tegen de HNDL-dreiging voordat een cryptografisch relevante kwantumcomputer (CRQC) beschikbaar komt.

Integratie van CI/CD-pijplijn

CodeSign Secure integreert met Azure DevOps , Jenkins , GitLab CI en andere belangrijke pipelineplatformen via API's en commandoregelinterfaces. Het ondertekenen van firmware is een gecontroleerde, door beleid afgedwongen fase in de buildpipeline, geen handmatige stap.

Organisaties die de overgangsperiode van 460 dagen doormaken, of het nu gaat om het beoordelen van hun huidige certificaatinventaris, het overzetten van sleutels naar hardware of het opzetten van geautomatiseerde vernieuwingsworkflows, kunnen contact opnemen met Encryption Consulting voor een praktische begeleiding. Het team werkt rechtstreeks samen met organisaties om hiaten in hun digitale infrastructuur te identificeren en een praktisch plan van aanpak op te stellen voordat de volgende vernieuwingscyclus druk met zich meebrengt.

Conclusie

CA/B Forum Ballot CSC-31 markeert een echte verschuiving in de manier waarop publiekelijk vertrouwde codeondertekeningscertificaten worden beheerd. De geldigheidsperiode van 39 maanden, waarop de meeste teams hun workflows baseerden, is niet langer beschikbaar. Organisaties die zich nog niet hebben aangepast, zullen binnenkort hun eerste verlenging van 460 dagen tegemoet zien, en de infrastructuurbeslissingen die op dat moment worden genomen, zullen bepalen of toekomstige verkortingen verstoringen veroorzaken of soepel verlopen.

De organisaties die hier goed mee omgaan, zijn niet degenen die een herinnering in hun agenda zetten en verdergaan. Zij zijn degenen die de limiet van 460 dagen beschouwen als het signaal dat het is: de industrie beweegt zich over de hele linie naar kortere certificatenlevensduren, TLS-certificaten staan ​​al op een meerjarig schema voor reductie en codeondertekening volgt nu hetzelfde pad. Het bouwen van een geautomatiseerde, controleerbare infrastructuur voor ondertekening betekent dat deze niet opnieuw hoeft te worden opgebouwd bij de volgende reductie.

Het CA/B Forum is consistent in zijn koers. De geldigheidsduur van certificaten zal steeds korter worden en handmatige verlengingsprocessen zullen steeds moeilijker vol te houden zijn. Organisaties die vandaag investeren in certificaatdetectie, hardwarematige sleutelopslag en geautomatiseerd beheer van de certificaatlevenscyclus voor codeondertekening , voldoen niet alleen aan een huidige vereiste. Ze leggen de basis voor elke toekomstige verkorting van de geldigheidsduur van certificaten.