Nieuwe regels voor codeondertekening in 2025: hoe u voorop blijft lopen met CodeSign Secure 

Introductie 

Codeondertekening is een basisvereiste geworden voor softwareteams die willen aantonen dat hun code veilig, ongeschonden en daadwerkelijk van hen afkomstig is. Of u nu desktop-apps, mobiele APK's of containers verzendt, een geldig codeondertekeningscertificaat geeft gebruikers de zekerheid dat de code onderweg niet is gewijzigd. 

Onlangs heeft het CA/Browser Forum (de groep die de regels voor digitale certificaten vaststelt) een grote verandering doorgevoerd: onder Ballot CSC-31, aangenomen op 17 november 2025, daalt de maximale geldigheidsduur voor publiekelijk vertrouwde codeondertekeningscertificaten naar 460 dagen, ongeveer 15 maanden, voor elk certificaat dat is uitgegeven op of na 1 maart 2026.

Naleving van de 460-dagenregel voor codeondertekening, kort samengevat: Stemmingsvoorstel CSC-31 (aangenomen op 17 november 2025, Code Signing Baseline Requirements v3.10.0) beperkt de geldigheidsduur van publiekelijk vertrouwde codeondertekeningscertificaten tot 460 dagen voor certificaten die zijn uitgegeven op of na 1 maart 2026. Certificaten die vóór die datum zijn uitgegeven, behouden hun oorspronkelijke geldigheid tot de vervaldatum. Bevestigde compromittering van een sleutel vereist nog steeds intrekking door de certificeringsinstantie binnen 24 uur, ongeacht de geldigheidsperiode.

Key Takeaways

• De ingangsdatum is 1 maart 2026 voor certificaten die op of na die datum worden uitgegeven, niet februari 2025. Controleer dit rechtstreeks bij de betreffende instantie. de door CA/Browser Forum zelf gepubliceerde vereisten voordat er een nalevingsclaim wordt ingediend op basis van een specifieke datum.
• Deze site behandelt de stemming uitgebreider, met de volledige controlelijst en details over intrekking/tijdstempeling. Beveiligde codeondertekening: Verkorte certificaatgeldigheid tot 460 dagen.
• Een kortere geldigheidsduur verkort de maximale blootstellingsperiode na een beveiligingslek; het verandert niets aan de 24-uurs herroepingstermijn van de certificeringsinstantie zodra een beveiligingslek is bevestigd.

Dit is niet zomaar een kleine beleidsaanpassing. Als uw team gewend is om met certificaten van twee of drie jaar te werken, betekent dit dat u opnieuw moet nadenken over hoe u verlengingen, sleutelbeveiliging en automatisering beheert. Negeren hiervan kan leiden tot mislukte ondertekening, problemen met de build of zelfs niet-ondertekende releases. 

In de rest van dit artikel leggen we uit wat er verandert, hoe dit uw ondertekeningsworkflows beïnvloedt en hoe onze CodeSign Secure u kan helpen veilig en compliant te blijven zonder dat dit meer handmatig werk met zich meebrengt. 

Wat verandert er in de geldigheid van codeondertekening? 

Tot nu toe hadden de meeste codeondertekeningscertificaten een mooie, lange levensduur van wel 3 jaar (of 39 maanden, om precies te zijn). Dit maakte het eenvoudiger: je kon je certificaat aanschaffen, het gebruiken voor meerdere releases en het elke paar jaar verlengen. 

Dat gaat veranderen. 

Het CA/Browser Forum heeft besloten de maximale geldigheidsduur van deze certificaten te verkorten tot slechts 460 dagen, iets meer dan 15 maanden. Het doel is om de beveiliging te verbeteren en het risico te verkleinen dat sleutels met een lange geldigheidsduur worden blootgesteld of misbruikt. 

Belangrijke data om te weten 

• Maart 1, 2026: Elke publiekelijk vertrouwde certificaat voor codeondertekening Uitgiften op of na deze datum hebben een maximale geldigheidsduur van 460 dagen, conform stemming CSC-31 (aangenomen op 17 november 2025). 
• Vóór 1 maart 2026Certificaten die al zijn uitgegeven, behouden hun oorspronkelijke geldigheidsperiode tot ze vanzelf verlopen; de limiet geldt voor uitgifte en heruitgifte vanaf die datum, niet met terugwerkende kracht. 

Als u dus een certificaat met een langere geldigheidsduur heeft dat vóór 1 maart 2026 is afgegeven, blijft dit geldig volgens de oorspronkelijke termijn. Voor elk certificaat dat vanaf die datum wordt afgegeven of verlengd, geldt de maximale geldigheidsduur van 460 dagen. 

Dit betekent dat u uw abonnementen vaker moet verlengen, dat u alles beter moet bijhouden en dat er meer ruimte is voor fouten, tenzij u een systeem hebt dat ervoor zorgt dat alles op schema blijft. 

Waarom is deze verandering belangrijk?

Op het eerste gezicht lijkt het verkorten van de geldigheidsduur van certificaten misschien extra werk. Maar er zit een goede reden achter. 

Minder kans op misbruik van sleutels 

Hoe langer een certificaat geldig blijft, hoe groter het risico als er iets misgaat, bijvoorbeeld als een privésleutel uitlekt of wordt gestolen. Door de geldigheidsduur te verkorten tot 460 dagen, wordt de schade beperkt als een sleutel ooit wordt gecompromitteerd. Het is een aanpak van "minder tijd, minder risico". 

Stimuleert betere veiligheidsgewoonten 

Kortere levensduur betekent dat teams up-to-date moeten blijven met hoe ze certificaten en cryptografische algoritmen beheren. Het dwingt iedereen om sleutels en instellingen vaker te updaten, zodat ze niet langer jarenlang hoeven te "instellen en vergeten". 

Houdt u op de hoogte van de regels van de sector 

Deze wijziging is niet zomaar een suggestie; het is nu officieel opgenomen in de regels van het CA/Browser Forum. Als u wilt dat uw codeondertekeningscertificaten worden vertrouwd, moet u zich aan deze nieuwe regels houden. Tools zoals onze CodeSign Secure kunnen u helpen om aan de regelgeving te voldoen zonder dat certificaatbeheer een fulltime baan wordt.

Impact op organisaties en ontwikkelaars 

Deze nieuwe limiet van 460 dagen is niet alleen een wijziging in selectievakjes; het heeft invloed op de manier waarop teams software plannen, bouwen en uitbrengen. 

Meer verlengingen, vaker 

Omdat certificaten over iets meer dan een jaar verlopen, moet u ze vaker verlengen. Dat betekent dat u meer vervaldata in de gaten moet houden, pipelines moet bijwerken en ervoor moet zorgen dat er niets kapotgaat tijdens een release. Als u een verlenging mist, kunnen uw builds mislukken of kan uw ondertekende software waarschuwingen genereren. 

Sleutelbeheer wordt lastig 

Meer verlengingen betekenen ook meer sleutelparen die veilig beheerd moeten worden. Als u nog geen HSM's of veilige sleutelopslag gebruikt, is het nu tijd om daarover na te denken. Het kwijtraken van een privésleutel of het op de verkeerde plek opslaan ervan kan tot ernstige problemen leiden.

Budgetteren en plannen moeten worden bijgesteld 

Als u meerjarige certificaten hebt gekocht en deze een tijdje hebt gereserveerd, werkt die strategie niet meer. U zult nu vaker certificaten moeten kopen en beheren, dus het is de moeite waard om te bekijken hoe dit uw budget en interne processen beïnvloedt. 

Hier komt ons platform in beeld: geautomatiseerde verlengingen, sleutelopslag met HSM-integratie en een overzichtelijke manier om al je certificaten op één plek te beheren. Minder rommel, minder verrassingen. 

Best practices voor het beheren van kortere certificaatlevenscycli 

Nu certificaten iets meer dan een jaar geldig zijn, is het niet meer echt praktisch om alles handmatig bij te houden. Om last-minute gedoe en mislukte builds te voorkomen, is het tijd om de zaken wat aan te scherpen. 

• Automatiseer verlengingen waar u maar kunt: Als uw certificaatverlengingsproces nog steeds kalenderherinneringen en handmatige stappen omvat, wordt het snel saai. Het automatiseren van verlengingen, met name voor herhaalbare taken zoals het aanvragen, opnieuw uitgeven en installeren van certificaten, bespaart tijd en verkleint de kans dat u iets belangrijks mist. 
• Bewaar sleutels op veilige hardware: Het opslaan van privésleutels op lokale machines of gedeelde schijven is vragen om problemen. Het gebruik van HSM's (Hardware Security Modules) of cloudgebaseerde sleutelkluizen biedt u de bescherming die u nodig hebt, vooral nu certificaten vaker worden vernieuwd. Het helpt ook bij het voldoen aan compliance-vereisten. 
• Houd de vervaldatum en heruitgifte in de gaten: Stel waarschuwingen en dashboards in om bij te houden wanneer certificaten bijna verlopen. Dit is niet langer alleen maar een 'leuke extra'; het missen van een verlengingsperiode kan releases blokkeren of vertrouwensproblemen bij uw gebruikers veroorzaken. Een beetje inzicht is een groot voordeel. 

Ons platform is ontworpen om dit allemaal te regelen. Van automatisering van verlenging en HSM-integratie tot het bijhouden van vervaldata en veilige opslag: het helpt u alles op orde te houden met veel minder handmatige inspanning. 

Hoe CodeSign Secure codeondertekening vereenvoudigt onder de nieuwe regels

Nu certificaten nog maar 460 dagen geldig zijn, wordt alles handmatig doen al snel een vervelende klus. Daarom hebben we CodeSign Secure ontwikkeld : om het ondertekenen van code stressvrij te maken en het hele proces soepeler te laten verlopen.

• Gecentraliseerd sleutel- en certificaatbeheer: U hoeft niet langer te zoeken in gedeelde mappen, e-mails of op lokale computers naar de juiste sleutel of het juiste certificaat. Ons platform biedt u één plek om alles te beheren, of het nu gaat om een ​​webapp, mobiele release of desktop-installatieprogramma. 
• CI/CD-integratie: Ons platform werkt prima samen met de tools die u al gebruikt, zoals Bamboo, TeamCity, Azure DevOps, Jenkins, en anderen. Ondertekening wordt onderdeel van uw build-pipeline, niet iets dat u apart moet doen. 
• HSM-ondersteunde ondertekening met PKCS#11-ondersteuning: Uw privésleutels verlaten de beveiligde hardware nooit. Ons platform ondersteunt PKCS # 11, zodat het kan worden aangesloten op HSM's en uw ondertekeningssleutels beschermd blijven, ongeacht of u on-premises HSM's of cloudgebaseerde opties gebruikt. 
• Slimme waarschuwingen en automatisering van verlenging: Ons platform houdt je certificaten in de gaten en waarschuwt je voordat ze verlopen. Het verwerkt ook de verlengingsstappen op de achtergrond, zodat je je geen zorgen hoeft te maken over gemiste deadlines of mislukte builds. 

Kortom, met onze CodeSign Secure blijft u voldoen aan de nieuwe regels, zonder dat certificaatbeheer een fulltimebaan wordt. 

Migratiestrategie: van langlopende certificaten naar certificaten van 460 dagen

Als je certificaten met een looptijd van 2 of 3 jaar hebt gebruikt, kan de overstap naar de nieuwe 460-dagenregel een grote aanpassing lijken, maar dat hoeft niet zo te zijn. Met een beetje planning en de juiste tools kan de overgang vrij soepel verlopen. 

• Begin met een certificaataudit: Allereerst: maak een lijst van al uw huidige codeondertekeningscertificaten. Noteer de uitgifte- en vervaldata, waar de sleutels zijn opgeslagen en welke projecten ervan afhankelijk zijn. Dit geeft u een duidelijk beeld van wat aandacht nodig heeft en wanneer. 
• Plan voor verlengingen en heruitgifte: Als u een meerjarig certificaat heeft dat vóór 1 maart 2026 is afgegeven, houd er dan rekening mee dat elke heruitgifte vanaf die datum slechts 460 dagen geldig is. Plan dus vooruit. Stel een verlengingskalender op, informeer uw ontwikkel-/releaseteams en voorkom stress op het laatste moment. 

CodeSign Secure maakt de overstap eenvoudiger 

Ons platform helpt u over te stappen op kortere certificaatcycli zonder uw workflow te verstoren. Het kan bestaande certificaten scannen en volgen, u waarschuwen wanneer het tijd is om ze te vervangen en heruitgifte afhandelen via geautomatiseerde processen. Of u nu één team of de hele organisatie overzet, ons platform houdt het proces overzichtelijk en veilig. 

Intrekking en tijdstempeling blijven van toepassing.

Een kortere geldigheidsduur verandert niets aan twee regels die sowieso al gelden, ongeacht de lengte van het certificaat: een certificeringsinstantie (CA) moet een certificaat binnen 24 uur intrekken nadat is vastgesteld dat de privésleutel is gecompromitteerd, en een geldige RFC 3161-tijdstempel zorgt ervoor dat software die u al hebt uitgebracht, verifieerbaar blijft zodra het ondertekeningscertificaat zelf is verlopen. Geen van beide is optioneel onder de nieuwe cyclus; sterker nog, een vernieuwingscyclus van 460 dagen maakt beide juist zichtbaarder, omdat u vaker gebruik zult maken van uw vernieuwings- en (idealiter nooit) intrekkingsprocessen.

Checklist voor nalevingsaudit

• Controleer de uitgiftedatum van elk certificaat aan de hand van 1 maart 2026 om te weten welke geldigheidsregel erop van toepassing is.
• Controleer of de privésleutels zijn opgeslagen op hardware die voldoet aan de FIPS 140-2 Level 2-norm (of Common Criteria EAL 4+) van het CA/Browser Forum.
• Zorg ervoor dat elke ondertekeningshandeling wordt voorzien van een tijdstempel via een betrouwbare TSA.
• Bevestig dat er een geteste en gedocumenteerde intrekkingsprocedure bestaat die binnen 24 uur kan worden uitgevoerd.
• Bevestig dat de automatische verlenging, en niet de agendaherinneringen, de certificaten volgens de nieuwe cyclus van 15 maanden verwerkt.

Conclusie 

Een kortere geldigheidsduur van certificaten klinkt misschien als meer werk, maar in werkelijkheid zorgt het ervoor dat iedereen betere gewoontes aanleert, de sleutelbeveiliging verbetert, updates sneller uitvoert en meer controle heeft over het ondertekeningsproces. 

Dat is waar onze CodeSign Secure echt in uitblinkt. Het is ontworpen om het zware werk voor u te doen, zodat u dat niet hoeft te doen. Of het nu gaat om het bijhouden van certificaten, het afhandelen van verlengingen, het beveiligen van privésleutels in HSM's of het rechtstreeks integreren in uw CI/CD-pipelines , ons platform zorgt ervoor dat uw codeondertekeningsproces soepel, veilig en toekomstbestendig blijft.

Laat de 460-dagenregel uw team niet vertragen.

Veelgestelde Vragen / FAQ

Wat is de daadwerkelijke ingangsdatum van de 460-dagenregel?

1 maart 2026, voor certificaten die op of na die datum zijn uitgegeven, onder stemming CSC-31 (aangenomen op 17 november 2025). Certificaten die vóór die datum zijn uitgegeven, blijven ongewijzigd totdat ze opnieuw moeten worden uitgegeven.

Verkort een kortere geldigheidsduur de intrekkingstermijn voor gecompromitteerde sleutels?

Nee. Een bevestigde inbreuk op de sleutel vereist nog steeds intrekking door de certificeringsinstantie binnen 24 uur volgens de basisvereisten voor codeondertekening, ongeacht de geldigheidsduur van het certificaat.