Inzicht in de nieuwe wijziging in de geldigheidsduur van codeondertekeningscertificaten

Codeondertekening is het vertrouwensmechanisme waarmee een besturingssysteem kan bevestigen wie een stuk software heeft gepubliceerd en of het sinds de ondertekening is gewijzigd. Bij cryptografie met publieke sleutels bevat een certificaat de publieke sleutel, terwijl de uitgever de bijbehorende privésleutel geheimhoudt. Een codeondertekeningscertificaat koppelt de identiteit van een uitgever aan een publieke sleutel, en de bijbehorende privésleutel genereert de handtekening die Windows SmartScreen, OS-loaders en installatieprogramma's controleren voordat ze een uitvoerbaar bestand, stuurprogramma of installatieprogramma vertrouwen.

De wijziging in de geldigheidsduur, geïntroduceerd door CA/Browser Forum, Ballot CSC-31: Maximum Validity Reduction , is op 1 maart 2026 van kracht geworden. Dit artikel richt zich op die wijziging: wat de nieuwe limiet is, de cryptografische redenering erachter, hoe deze samenhangt met tijdstempeling en intrekking, wie erdoor wordt getroffen en de concrete stappen die nodig zijn om zich aan te passen.

Wat de nieuwe wijziging in de geldigheid inhoudt

Het CA/Browser Forum (CA/B Forum) is het overkoepelende orgaan van certificeringsinstanties en certificaatgebruikers, zoals leveranciers van browsers en besturingssystemen, dat de basisvereisten voor publiekelijk vertrouwde certificaten definieert. Op 13 oktober 2025 werd de stemming over Ballot CSC-31 afgerond. Deze wijziging zet de Code Signing Baseline Requirements om de maximale geldigheidsduur van een code-signing certificaat te verlagen van 39 maanden naar 460 dagen. De wijziging werd voorgesteld door Microsoft en onderschreven door Sectigo en eMudhra, en werd op 17 november 2025 aangenomen als Code Signing Baseline Requirements versie 3.10.0.

De limiet geldt voor zowel Organization Validation (OV) als Extended Validation (EV) code-signing certificaten. Deze limiet bepaalt het geldigheidsveld dat bij uitgifte is ingesteld en is daarom van toepassing op elk certificaat dat op of na 1 maart 2026 is uitgegeven of verlengd. Certificaten die vóór die datum zijn uitgegeven met een langere geldigheidsduur blijven vertrouwd tot hun aangegeven vervaldatum.

De getallen

Kenmerk	Vorige vereiste	Onder CSC-31
Maximale geldigheid	39 maanden	460 dagen
Ingangsdatum	Niet van toepassing	1 maart 2026
Basisvereisten versie	v3.9	v3.10.0
Betreffende certificaattypen	OV en EV	OV en EV

Hoewel de stemming de maximale geldigheidsduur op 460 dagen vaststelt, geven sommige certificeringsinstanties in de praktijk certificaten uit met een geldigheidsduur van 459 dagen om rekening te houden met tijdsverschillen en vertraging bij de uitgifte. DigiCert beschrijft de uitrol bijvoorbeeld als een geldigheidsduur van 459 dagen, en SSL.com geeft certificaten uit met een geldigheidsduur van 458 dagen om dezelfde reden. Verschillende certificeringsinstanties zijn eind 2025 gestopt met de verkoop van certificaten met een geldigheidsduur van twee en drie jaar, en producten met een geldigheidsduur van één jaar (366 dagen) zijn nu de standaardoptie.

De redenen voor een kortere geldigheidsperiode

De verkorting van de geldigheidsduur is een toepassing van een beproefd principe voor sleutelbeheer, en geen reactie op een specifiek incident. Een codeondertekeningscertificaat koppelt een langdurige, privésleutel aan een identiteit. Hoe langer die koppeling geldig is, hoe langer een gestolen of misbruikte sleutel betrouwbare handtekeningen kan blijven genereren, en hoe groter het aantal ondertekende documenten dat een aanvaller kan creëren voordat iemand ingrijpt.

Cryptoperioden in de NIST-richtlijnen voor sleutelbeheer

Dit sluit direct aan op het concept van een cryptoperiode zoals gedefinieerd in NIST Special Publication 800-57 Part 1 Revision 5, Recommendation for Key Management . Een cryptoperiode is de tijdsspanne waarin een sleutel geautoriseerd is voor gebruik. NIST adviseert om deze periode te beperken, zodat risico's zich niet oneindig ophopen. De publicatie modelleert elke sleutel als doorlopend in de staten pre-activatie, actief, gedeactiveerd, gecompromitteerd en vernietigd. Het beperken van de geldigheidsduur van certificaten tot 460 dagen zorgt voor een maximum aan de actieve periode van de bijbehorende ondertekeningssleutel, wat garandeert dat identiteitskoppelingen minstens elke vijftien maanden opnieuw worden gevalideerd. Het roteren van de ondertekeningssleutel zelf vereist het genereren van een nieuw sleutelpaar bij verlenging, wat de aanbevolen werkwijze is.

Aanbevelingen specifiek voor codeondertekening

NIST heeft ook richtlijnen gepubliceerd die specifiek op dit gebruiksscenario zijn gericht. Het NIST Cybersecurity White Paper, Security Considerations for Code Signing , legt uit hoe codeondertekening zorgt voor integriteit en authenticatie van de broncode. Het beveelt aan om ondertekeningssleutels te isoleren, ze op te slaan in een hardwarebeveiligingsmodule die alleen voor ondertekeningsfuncties is bedoeld, ontwikkelings- en productiesystemen voor ondertekening te scheiden en meerdere goedkeurders te vereisen vóór een ondertekeningsbewerking. Een kortere verplichte geldigheidsperiode versterkt deze controles door periodieke heruitgifte af te dwingen, waardoor de identiteit van de uitgever opnieuw wordt gevalideerd en de sleutelbinding volgens een vast schema wordt geroteerd.

Hoe geldigheid samenhangt met ondertekening, tijdstempeling en intrekking

Om de operationele impact van een kortere geldigheidsperiode te evalueren, moet de relatie tussen het certificaat, de tijdstempel en de intrekking nauwkeurig worden vastgesteld. Het certificaat definieert de periode waarin een ondertekeningssleutel wordt vertrouwd, de tijdstempel registreert wanneer een handtekening is geplaatst en intrekking trekt het vertrouwen in voordat een certificaat anders zou verlopen.

De ondertekeningsprocedure

1. De uitgever berekent een cryptografische hash van het artefact met behulp van een goedgekeurde hashfunctie zoals SHA-256.
2. De digest wordt ondertekend met de privésleutel, waardoor de handtekening ontstaat. Deze handtekening wordt samen met het certificaat van de uitgever en de certificaatketen naar een vertrouwde root in het artefact ingebed.
3. Tijdens de verificatie berekent de loader de hash opnieuw, verifieert de handtekening aan de hand van de publieke sleutel in het certificaat en valideert de certificaatketen en de geldigheidsstatus van het certificaat.

Waarom een ​​kortere geldigheidsperiode geen problemen veroorzaakt met reeds ondertekende software

Een veelvoorkomende zorg is dat certificaten met een kortere geldigheidsduur ervoor zorgen dat eerder uitgebrachte software niet meer gevalideerd wordt. Dit is echter niet het geval, zolang de handtekening maar van een tijdstempel is voorzien. Een tijdstempel van een vertrouwde Timestamp Authority registreert het moment van ondertekening. Mits het certificaat op dat moment geldig was, blijft de handtekening geldig gedurende de geldigheidsduur van het tijdstempel, die doorgaans veel langer is dan de geldigheidsduur van het certificaat. Dit is de reden waarom een ​​driver die jaren geleden is ondertekend, nog steeds kan worden geïnstalleerd, ook al is het ondertekeningscertificaat al lang verlopen.

Diezelfde eigenschap vormt de kern van het beveiligingsprobleem dat de wijziging van de geldigheidsduur aanpakt. Omdat een handtekening met tijdstempel langer geldig is dan het certificaat zelf, blijft een gecompromitteerd certificaat vertrouwde handtekeningen genereren, zelfs lang na het moment van de inbreuk. Het verkorten van de geldigheidsduur verkleint die periode van kwetsbaarheid, en intrekking sluit deze volledig af. De intrekkingsstatus wordt gepubliceerd via Certificate Revocation Lists (CRL's) en het Online Certificate Status Protocol (OCSP) , en een certificeringsinstantie (CA) kan een gecompromitteerd certificaat intrekken, zodat verificatoren handtekeningen die erop gebaseerd zijn, afwijzen. Omdat een handtekening met tijdstempel die vóór de intrekkingsdatum is gemaakt over het algemeen geldig blijft, moet de CA de intrekkingsdatum terugzetten naar het vermoedde tijdstip van de inbreuk om handtekeningen die eerder zijn geproduceerd ongeldig te verklaren.

Recente incidenten die het risico illustreren

De risico's die ontstaan ​​door langlopende, slecht beheerde ondertekeningscertificaten zijn niet hypothetisch. Verschillende recente campagnes laten zien waarom het ecosysteem de geldigheidsduur van certificaten verkort en de bijbehorende controles aanscherpt.

AnyDesk-productielek (2024)

Begin 2024 bevestigde AnyDesk, leverancier van oplossingen voor toegang op afstand, dat aanvallers toegang hadden gekregen tot hun productiesystemen en dat broncode en privésleutels voor codeondertekening waren gestolen, aldus een bericht van BleepingComputer . Het bedrijf reageerde door de getroffen certificaten in te trekken en het ondertekeningsmateriaal te vernieuwen. Incidenten zoals deze tonen aan waarom een ​​beperkte geldigheidsduur van certificaten belangrijk is, omdat dit de periode verkort waarin een gestolen certificaat kan worden misbruikt.

Hijack Loader en GHOSTPULSE hebben campagnes getekend (eind 2024)

In oktober 2024 documenteerden onderzoekers samples van Hijack Loader (ook bekend als GHOSTPULSE en IDAT Loader) die waren ondertekend met legitieme code-ondertekeningscertificaten . Deze samples werden verspreid via de ClickFix-social-engineeringtechniek, die gebruikers ertoe verleidt PowerShell uit te voeren. Onderzoekers ontdekten meerdere misbruikte certificaten die gekoppeld waren aan dezelfde command-and-control-infrastructuur. De uitgevende instanties annuleerden de certificaten binnen enkele uren tot een dag nadat ze op de hoogte waren gesteld. Deze gebeurtenis laat zien hoeveel waarde aanvallers hechten aan geldige handtekeningen en hoe belangrijk snelle intrekking is om misbruik tegen te gaan.

Misbruik van kortstondige Microsoft Trusted Signing-certificaten (2025)

In maart 2025 werd waargenomen dat aanvallers malware ondertekenden via Microsofts Trusted Signing-service met behulp van certificaten met een geldigheidsduur van drie dagen . Deze casus illustreert twee verschillende dynamieken. Het laat zien dat vastberaden actoren nog steeds op zoek zullen gaan naar geldige handtekeningen, maar het toont ook de defensieve waarde aan van kortstondige, centraal uitgegeven certificaten: de inloggegevens worden nooit aan de ontwikkelaar overhandigd, waardoor ze niet van een endpoint kunnen worden gestolen, en ze verlopen en kunnen vrijwel onmiddellijk worden ingetrokken. Dat model is precies de richting die de verkorting van de geldigheidsduur stimuleert.

Grootschalig misbruik van verkeersborden door chauffeurs (2020 tot 2025)

Een onderzoek van Group-IB uit 2025 bracht een langlopende operatie aan het licht waarbij meer dan 80 certificaten en meer dan 60 Windows Hardware Compatibility Program-accounts werden verzameld en tussen 2020 en het eerste kwartaal van 2025 meer dan 620 kwaadaardige Windows-kernelstuurprogramma's werden ondertekend. Hierbij werden vaak gestolen certificaten of certificaten verkregen via nieuw opgerichte schijnbedrijven gebruikt. Kernelstuurprogramma's draaien op het hoogste geprivilegieerde niveau van het besturingssysteem, waardoor een geldige handtekening op een kwaadaardig stuurprogramma extreem krachtig is. Een kortere geldigheidsduur voorkomt frauduleuze uitgifte op zich niet, maar in combinatie met hardwarematige sleutelopslag en snelle intrekking verkort het de nuttige levensduur van elk misbruikt certificaat.

Wie wordt erdoor getroffen en in welke mate?

Elke organisatie die software ondertekent met een publiekelijk erkend certificaat, is onderworpen aan de limiet van 460 dagen. De mate van operationele verandering hangt voornamelijk af van hoe ondertekeningssleutels worden opgeslagen en hoe de verlenging wordt afgehandeld.

Grootste impact: workflows voor fysieke hardwaretokens

Sinds 1 juni 2023 vereist het CA/B Forum dat privésleutels voor codeondertekening worden gegenereerd en bewaard op hardware die voldoet aan FIPS 140-2 Level 2 of Common Criteria EAL 4+, meestal een USB-token of een HSM. Teams die afhankelijk zijn van fysieke USB-tokens die door de CA worden verzonden, merken deze verandering het meest, omdat elke verlenging het inrichten en verzenden van een nieuw token met zich meebrengt. Met een vernieuwingstermijn van vijftien maanden in plaats van drie jaar komt dit logistieke werk veel vaker voor.

Laagste impact: cloud- en HSM-gebaseerde ondertekening

Organisaties die gebruikmaken van een cloudgebaseerde ondertekeningsservice of een netwerk- HSM , waarbij sleutels via een API worden aangemaakt en geroteerd, kunnen de verandering zonder veel problemen doorvoeren. Voor hen is een verlenging grotendeels een software-evenement dat volledig geautomatiseerd kan worden. Deze asymmetrie is opzettelijk, aangezien het bredere beleid de voorkeur geeft aan geautomatiseerde, centraal beheerde ondertekening boven handmatige tokenverwerking.

Operationele impact

Vernieuwingsfrequentie

Het verhogen van de maximale geldigheidsduur van 39 maanden naar 460 dagen betekent dat certificaten minstens elke vijftien maanden vervangen moeten worden. Over een vaste periode betekent dit meer dan twee keer zoveel vernieuwingsmomenten. Voor een uitgever die meerdere ondertekeningscertificaten gebruikt voor verschillende producten en buildsystemen, moet elke vernieuwing worden ingepland en uitgevoerd zonder de releaseprocessen te vertragen.

Automatiseringsvereiste

Handmatig bijhouden via spreadsheets en agendaherinneringen is niet schaalbaar naarmate verlengingen vaker voorkomen. Een gemiste verlenging kan een release blokkeren of leiden tot het verzenden van binaire bestanden die SmartScreen-waarschuwingen activeren. Tools voor certificaatlevenscyclusbeheer die ondertekeningscertificaten detecteren, de vervaldatum bewaken en de verlenging via CA-API's orkestreren, bieden de praktische oplossing. Deze druk om certificaten te verlengen is ook de drijvende kracht achter de parallelle verkorting van de levensduur van TLS-certificaten naar 47 dagen in 2029, zoals voorgesteld in het CA/Browser Forum-referendum SC-081v3.

Continuïteit door middel van tijdstempels

Omdat handtekeningen met een tijdstempel geldig blijven nadat het ondertekeningscertificaat is verlopen, moet elke ondertekeningsbewerking een tijdstempel van een betrouwbare tijdstempelautoriteit bevatten. Dit scheidt de lange levensduur van uitgebrachte software van de kortere levensduur van het certificaat en voorkomt dat een wijziging in de geldigheid de code beïnvloedt die al in gebruik is.

Nu de vereiste van kracht is, moet hieraan voldaan worden.

Nu de termijn van 460 dagen van kracht is, moet elk nieuw en verlengd certificaat hieraan voldoen. De volgende stappen zorgen ervoor dat een organisatie aan de regelgeving blijft voldoen en dat de handmatige, reactieve afhandeling overgaat naar een gecontroleerde levenscyclus.

1. Inventariseer alle codeondertekeningscertificaten binnen alle teams, buildservers en producten, en registreer de eigenaar en de locatie waar elke privésleutel is opgeslagen.
2. Classificeer de belangrijkste opslagmethoden op basis van type, waarbij fysieke USB-tokenworkflows worden gescheiden van cloud- of HSM-gebaseerde sleutels, en geef prioriteit aan de tokengebaseerde methoden voor modernisering.
3. Implementeer automatisering van certificaatlevenscyclusbeheer om de vervaldatum te bewaken, eigenaren tijdig te waarschuwen en, waar mogelijk, certificaten te verlengen via CA-API's.
4. Dwing het toevoegen van een tijdstempel af bij elke ondertekeningshandeling, zodat vrijgegeven software geldig blijft na het verlopen van het certificaat.
5. Beveilig de ondertekeningsomgeving volgens de NIST-richtlijnen: gebruik HSM-sleutels, scheid ontwikkelings- en productieondertekening, goedkeuring door meerdere partijen en geïsoleerde ondertekeningssystemen.
6. Voer een volledige verlengingscyclus uit volgens het nieuwe schema, zodat elke verlenging onder de 460-dagenregel routineus verloopt in plaats van storend te zijn.
7. Zorg voor een paraatheid bij intrekking, met een vastgestelde procedure om sleutels snel in te trekken en opnieuw te ondertekenen als er een vermoeden bestaat dat een sleutel is gecompromitteerd, aangezien het verlopen van een sleutel op zich geen voldoende bescherming biedt.

Voldoen aan de nieuwe eis met CodeSign Secure van Encryption Consulting

Een kortere geldigheidsperiode maakt codeondertekening tot een terugkerend probleem in de levenscyclus van een taak die slechts eens in de paar jaar voorkomt. Precies hier bewijst een gecentraliseerd ondertekeningsplatform zijn waarde. CodeSign Secure is een gecentraliseerd, veilig en schaalbaar codeondertekeningsplatform dat is ontwikkeld om organisaties te helpen code met vertrouwen te ondertekenen zonder in te leveren op veiligheid of snelheid. Het is ontworpen voor moderne DevOps-omgevingen en integreert met CI/CD-pipelines zoals Azure DevOps, Jenkins en GitLab. Tegelijkertijd worden strikte toegangscontroles en goedkeuringsworkflows afgedwongen, waardoor het ondertekeningsproces schoon en conform de regelgeving blijft, ook naarmate verlengingen vaker voorkomen.

Mogelijkheden afgestemd op de geldigheidsverandering

Verschillende CodeSign Secure-functionaliteiten sluiten direct aan op de controles die de nieuwe termijn van 460 dagen organisaties oplegt:

• Sleutelbeveiliging met HSM-ondersteuning. Privésleutels worden opgeslagen in FIPS 140-2 Level 3 HSM's, waarmee ruimschoots wordt voldaan aan de hardware-opslagvereisten van het CA/Browser Forum. Er is ondersteuning voor Entrust nCipher, Thales Luna, Utimaco en Securosys, zowel voor on-premises als cloud-HSM's.
• Toegangscontrole op basis van beleid. Integratie met Active Directory en Keycloak, gedetailleerde op rollen gebaseerde toegangscontrole en goedkeuringsworkflows in meerdere stappen zorgen voor functiescheiding, zodat geen enkel document wordt ondertekend tenzij het voldoet aan het vereiste certificaattype, de ondertekeningsfase en de goedkeuringen. Dit implementeert direct de goedkeuring door meerdere partijen en de sleutelisolatie die NIST aanbeveelt voor codeondertekening.
• Naadloze CI/CD-integratie. Beveiligingscontroles en integriteitsvalidatie bij releases voorkomen dat niet-ondertekende artefacten de productieomgeving bereiken. Dankzij gecentraliseerde tracking en directe waarschuwingen bij ongeautoriseerde ondertekeningspogingen blijven pipelines met hoge snelheid compliant, zelfs bij frequentere vernieuwingscycli.
• Brede ondersteuning voor diverse formaten en platformen. De ondertekening omvat .exe-, .dll-, .jar-, .apk- en .dmg-bestanden, Docker-containers en firmwarebestanden voor Windows, Linux en macOS, en integreert met een aangepaste PKCS11-wrapper en tools zoals Signtool, Jarsigner en JSign.
• Hashing en veilige tijdstempeling aan de clientzijde. Hashes worden aan de clientzijde gegenereerd via een aangepaste Key Storage Provider voor het CNG-framework van Microsoft, en beveiligde tijdstempels zorgen ervoor dat de handtekening geldig blijft na het verlopen van het certificaat, wat essentieel is bij kortere geldigheidsperioden.
• Uitgebreide audit trails. Gedetailleerde gebeurtenislogboeken registreren elke goedkeuring, afwijzing en ondertekening voor naleving en incidentonderzoek, met SIEM-integratie voor Grafana, Loki en Splunk via OpenTelemetry.
• Flexibele implementatiemodellen. Organisaties kunnen kiezen voor een volledig beheerde, in de cloud gehoste service met ingebouwde HSM-beveiliging en volledige API-toegang, of voor een on-premises oplossing waarbij sleutels worden beheerd in cloud-HSM's, on-premises HSM's of beide.
• Ondersteuning voor post-kwantumcryptografie. CodeSign Secure ondersteunt de door NIST erkende kwantumresistente ondertekeningsschema's ML-DSA en LMS rechtstreeks op de HSM, samen met dubbele ondertekening die een klassieke RSA of combineert. ECDSA Een signatuur met een post-kwantumsignatuur voor een geleidelijke overgang.

Of u nu tientallen ondertekeningsaccounts beheert binnen gedistribueerde teams, snelle CI/CD-pipelines uitvoert of werkt onder strikte compliance-eisen in sectoren zoals de auto-industrie, de gezondheidszorg of de fintech-sector, CodeSign Secure neemt de extra verlengingskosten van de 460-dagenlimiet voor zijn rekening en maakt van codeondertekening een gecontroleerde, geautomatiseerde levenscyclus.

Conclusie

Het verkorten van de geldigheidsduur van codeondertekeningscertificaten tot 460 dagen zorgt voor een kortere cryptoperiode voor ondertekeningssleutels, verkleint de periode waarin een gecompromitteerd certificaat kan worden misbruikt en brengt codeondertekening in lijn met het automatiseringsmodel dat TLS al aan het hervormen is. Recente incidenten met AnyDesk, Hijack Loader, Microsoft Trusted Signing en grootschalig misbruik van ondertekende stuurprogramma's wijzen allemaal op dezelfde conclusie: langlopende, losjes gereguleerde ondertekeningscertificaten vormen een risico, en het beperken van hun levensduur is een verstandige maatregel.

Voor organisaties die certificaten nog handmatig bijhouden en afhankelijk zijn van fysieke tokens, is het belangrijkste gevolg dat certificaten vaker moeten worden vernieuwd. Voor organisaties die codeondertekening als een geautomatiseerde levenscyclus beschouwen met detectie, monitoring, tijdstempeling en hardwarematige sleutels, is de verandering een kleine aanpassing. Nu de ingangsdatum van 1 maart 2026 is verstreken, is het voltooien van deze overstap niet langer optioneel, maar een operationele vereiste.