Säker kodsignering: Reducerad certifikatgiltighet till 460 dagar

Om du hanterar kodsignering för din organisation har branschen just ändrat reglerna, och deadline har redan passerat. Den 1 mars 2026 trädde Ballot CSC-31, formellt antagen av CA/Browser Forum den 17 november 2025, i kraft. Den minskar den maximala giltighetsperioden för alla offentligt betrodda kodsigneringscertifikat från 39 månader (cirka 3 år) till 460 dagar (cirka 15 månader). Alla kodsigneringscertifikat som utfärdas från och med den 1 mars 2026 måste följa denna nya gräns.

För utvecklingsteam som har arbetat med en förnyelsecykel där man bara kan ställa in allt, med förnyelse vartannat eller vart tredje år, förändrar denna förändring fundamentalt hur kodsignering passar in i programvarusläppsprocessen. Det som en gång vart tredje år var administrativ uppgift är nu en återkommande, operativt betydande skyldighet som måste hanteras medvetet och i de flesta fall automatiseras.

I den här bloggen går vi igenom exakt vad som har förändrats, varför CA/Browser Forum fattade detta beslut, vilka som påverkas mest och viktigast av allt, vad ert team bör göra just nu för att följa reglerna och fortsätta signeringsverksamheten utan avbrott.

460 dagars giltighetstid för kodsigneringscertifikat, definierad: den maximala livslängd som CA/Browser Forum tillåter för ett offentligt betrott kodsigneringscertifikat som utfärdats den 1 mars 2026 eller senare, en minskning från 39 månader enligt Ballot CSC-31 (antagen 17 november 2025), vilket ungefär tredubblar hur ofta varje signeringscertifikat som en organisation använder behöver spåras, förnyas och, om dess nyckellagring fortfarande är beroende av fysiska tokens, fysiskt ersättas.

Key Takeaways

• Omröstning CSC-31 röstades fram och godkändes den 14 oktober 2025, slutförde granskningen av immateriella rättigheter och antogs formellt den 17 november 2025 (publicering av Code Signing Baseline Requirements v3.10.0) och trädde i kraft den 1 mars 2026. Certifikat som utfärdats före det datumet behåller sin ursprungliga giltighetstid; allt som utfärdas på eller efter det datumet är begränsat till 460 dagar, utan respitperiod.
• Detta är den kanoniska, mest detaljerade sidan om just denna omröstning och dess operativa konsekvenser. För information om hur detta passar ihop med de separata skyldigheterna i EU:s cyberresilienslagstiftning som täcker samma signeringsinfrastruktur, se CRA-efterlevnadsarkitektur för säker kodsignering, vilket täcker båda systemen tillsammans snarare än att duplicera omröstningsdetaljerna här.
• Kortare giltighetstid minskar inte behovet av återkallningsberedskap, det ändrar matematiken: en komprometterad nyckel har nu högst 460 dagars potentiell exponering istället för 39 månader, men bekräftad kompromettering kräver fortfarande återkallelse inom 24 timmar enligt baslinjekraven, inte när certifikatet råkar löpa ut.
• USB-hårdvarutokens, som är acceptabla under en 3-årscykel, blir en återkommande driftskostnad under en 15-månaderscykel; detta är den enskilt vanligaste anledningen till att organisationer migrerar till HSM-baserad signering efter denna förändring, inte före den.

Vad som förändrades och när

CA/Browser Forums arbetsgrupp för kodsigneringscertifikat introducerade Ballot CSC-31 för att uppdatera grundkraven för utfärdande och hantering av offentligt betrodda kodsigneringscertifikat , version 3.9.

Här är tidslinjen:

Milestone	Datum
Omröstning CSC-31 föreslagen	september 2025
Valsedeln röstades fram och godkändes av CA/B-forumet	October 14, 2025
IPR-granskningsperiod avslutad, omröstning formellt antagen	November 17, 2025
Nya grundkrav för kodsignering v3.10.0 publicerade	November 17, 2025
Ny maximal giltighetstid på 460 dagar träder i kraft	Mars 1, 2026

Certifikat som utfärdats före den 1 mars 2026 enligt de tidigare reglerna förblir giltiga fram till sitt ursprungliga utgångsdatum. Dock omfattas alla certifikat som utfärdats eller förnyats den 1 mars 2026 av det nya taket på 460 dagar. Det finns ingen respitperiod för nyutfärdade certifikat.

Varför CA/Browserforumet gjorde denna ändring

Övergången mot kortare livslängder för certifikat är inte godtycklig och inte heller ny. CA/Browser Forum har systematiskt minskat certifikatgiltigheten för alla certifikattyper i åratal. Resonemanget är konsekvent och välgrundat i säkerhetsprinciper.

1. Begränsa explosionsradien för nyckelkompromittering: Den privata nyckeln till ett kodsigneringscertifikat kan komprometteras – genom dataintrång, ransomware, insiderhot eller dåliga nyckellagringsmetoder. Under den gamla giltighetsperioden på 39 månader förblev en komprometterad nyckel användbar för en angripare i upp till tre år, även om certifikatet återkallades (eftersom kontrollen av certifikatåterkallelse tillämpas inkonsekvent mellan plattformar).
   En kortare livslängd begränsar direkt exponeringsfönstret. Om en nyckel komprometteras på dag ett av ett 460-dagarscertifikat har angriparen ungefär 15 månader av potentiellt missbruk snarare än tre år.
2. Starkare nyckelhantering: När ett team inte behöver tänka på sitt signeringscertifikat på tre år tenderar nyckellagringspraxis, åtkomstkontroller och revisionsspår att försämras. Årliga eller nästan årliga förnyelser tvingar organisationer att regelbundet se över sin signeringsinfrastruktur – granska vem som har åtkomst, var nycklar lagras, om lagringsmetoderna fortfarande uppfyller gällande standarder och om signeringsarbetsflödena fortfarande är lämpliga.
3. Uppmuntra automatisering: Varje organisation som signerar kod med ett offentligt betrott kodsigneringscertifikat påverkas. Kortare giltighetsperioder gör manuell hantering alltmer opraktisk, vilket påskyndar införandet av automatiserade verktyg.

Problemet med USB-token

Det är värt att ägna en stund specifikt åt problemet med USB-hårdvarutoken, eftersom det representerar den enskilt största operativa utmaningen som skapats av 460-dagarsförändringen för många utvecklingsteam.

CA/Browser Forums grundkrav har i flera år krävt att privata nycklar för offentligt betrodda kodsigneringscertifikat lagras på hårdvara som uppfyller FIPS 140-2 nivå 2 eller Common Criteria EAL 4+-standarderna. För många organisationer uppfylldes detta krav genom att utfärda kodsigneringscertifikat på USB-hårdvarutokens som skickades direkt från certifikatutfärdaren – en modell som uppfyllde kravet på lagring av hårdvarunycklar utan att kräva att organisationen driver sin egen HSM-infrastruktur.

USB-tokenbaserad signering introducerade sina egna problem även under den gamla giltighetsperioden på 39 månader:

• Tokens kan förloras, skadas eller stjälas, och för att ersätta dem krävs ett nytt utfärdande av certifikatet.
• Signering krävde fysisk åtkomst till token, vilket skapade flaskhalsar för distansteam och automatiserade CI/CD-pipelines.
• Token kunde inte enkelt säkerhetskopieras, vilket skapade en enda felpunkt för signeringsoperationen.

Under en giltighetsperiod på 460 dagar återkommer alla dessa problem oftare. Logistiken kring tokens, som var hanterbar under en treårscykel, blir en återkommande operativ börda under en 15-månaderscykel.

Det praktiska svaret, och den riktning som branschen tydligt är på väg mot, är migrering från USB-tokens till molnbaserad eller lokal HSM-infrastruktur som nås via en centraliserad signeringsplattform. Denna metod lagrar den privata nyckeln i FIPS-kompatibel hårdvara, gör att signeringsoperationer kan utföras via API från vilket auktoriserat byggsystem som helst, eliminerar den fysiska tokenlogistiken helt och integreras naturligt med en centraliserad kodsigneringsplattform.

Varför tidsstämpling blir ännu viktigare nu

En av de viktigaste tekniska övervägandena för kortare certifikatlivslängder är tidsstämpling. När ett kodsigneringscertifikat löper ut blir inte programvara som signerats med det certifikatet automatiskt opålitlig. Om signeringsåtgärden inkluderade en giltig RFC 3161-tidsstämpel från en betrodd tidsstämpelutfärdare (TSA) förblir signaturen verifierbar på obestämd tid – även efter att certifikatet har löpt ut. Tidsstämpeln ger kryptografiskt bevis på att signeringsåtgärden inträffade medan certifikatet var giltigt, och det beviset kvarstår bortom certifikatets giltighetsperiod.

Utan en tidsstämpel är den signerade artefaktens tillförlitlighet direkt kopplad till certifikatets giltighetsperiod. När certifikatet löper ut kommer verifieringssystem som kontrollerar certifikatets giltighet att avvisa signaturen. För all programvara med en livslängd längre än 15 månader, vilket inkluderar praktiskt taget alla företagsapplikationer, drivrutiner, firmware-avbildningar eller långlivade körbara filer, innebär en frånvarande eller felaktigt tillämpad tidsstämpel att programvaran så småningom kommer att förlora sin tillförlitliga status.

När certifikat förnyas årligen blir varje signerad artefakt som saknar en korrekt RFC 3161-tidsstämpel ett potentiellt problem inom 15 månader efter signering. De praktiska stegen här är:

• Kontrollera att din signeringsverktygskedja använder RFC 3161-tidsstämplar som standard för varje signeringsåtgärd.
• Konfigurera dina signeringspipelines så att en saknad tidsstämpel behandlas som ett signeringsfel och inte en varning.
• Se till att tidsstämplar tillämpas med SHA-256-hashning (inte SHA-1, som är i stort sett föråldrad).
• För artefakter med lång livslängd (firmware, drivrutiner, företagsprogramvara), kontrollera att din tidsstämplingskonfiguration har tillämpats korrekt på alla historiska artefakter också.

Återkallelse under det nya giltighetsfönstret

Kortare giltighetstid beskrivs ibland som att minskat behov av återkallelse. Det stämmer inte helt: det minskar den maximala exponeringen en kompromettering kan orsaka, men det ändrar inte själva återkallningsskyldigheten. Enligt Code Signing Baseline Requirements §4.9.1.1 måste en CA fortfarande återkalla ett certifikat inom 24 timmar efter att ha bekräftat att den privata nyckeln har komprometterats, på ett 460-dagars certifikat precis som på ett 39-månaders. Det som det kortare fönstret ändrar är taket: om en nyckel komprometteras dagen efter utfärdandet och förblir oupptäckt, sjunker det maximala fönstret som en angripare teoretiskt kan utnyttja den från ungefär tre år till cirka 15 månader.

Den praktiska implikationen för er granskningschecklista: bekräfta att er organisation, inom en timme efter misstanke om kompromettering, kan identifiera varje artefakt som signerats av ett specifikt certifikat. Att vänta på att ett certifikat helt enkelt ska löpa ut är inte en återkallelseplan, och den snabbare förnyelsetakten som denna förändring introducerar ersätter inte en testad komprometteringsåtgärd.

Gamla kontra nya krav, sida vid sida

Krav	Före den 1 mars 2026	Den 1 mars 2026 eller senare
Maximal giltighetstid för certifikatet	39 månader	460 DAYS
Förnyelsefrekvens (typisk)	Ungefär vart tredje år	Ungefär var 15:e månad
Tidslinje för återkallelse av bekräftad nyckelkompromettering	24 timmar (oförändrat)	24 timmar (oförändrat)
Privat nyckellagring	FIPS 140-2 Nivå 2+ eller Common Criteria EAL4+ hårdvara (sedan juni 2023)	Samma krav, oförändrat
Maximal teoretisk exponering från en oupptäckt nyckelkompromiss	Upp till ~39 månader	Upp till ~460 dagar

Checklista för granskning: Vad du bör göra just nu

Om er organisation ännu inte har utvärderat effekterna av 460-dagarsförändringen, här är en praktisk utgångspunkt:

Steg 1 — Granska ditt inventarium för kodsigneringscertifikat. Identifiera alla offentligt betrodda kodsigneringscertifikat som din organisation använder. För varje certifikat registrerar du utgångsdatum, lagringsmetod (USB-token, HSM, moln-HSM, programvarubutik), vilka signeringsarbetsflöden eller pipelines som är beroende av det och vem som ansvarar för förnyelsen. Om du inte har denna information centralt dokumenterad är det första prioritet att skapa det inventariet.

Steg 2 — Identifiera certifikat som redan omfattas av de nya reglerna. Alla certifikat som utfärdas från och med den 1 mars 2026 är begränsade till 460 dagar. Identifiera vilka av dina certifikat som faller inom denna kategori och kalenderförnyelsehändelser med lämplig ledtid — planera förnyelse minst 30 till 60 dagar före utgångsdatum för att möjliggöra anskaffning, provisionering och pipeline-uppdateringar.

Steg 3 — Utvärdera din nyckellagringsinfrastruktur. Om din organisation använder USB-hårdvarutokens, utvärdera om det är lämpligt att migrera till en molnbaserad HSM eller en lokal HSM som nås via en centraliserad signeringsplattform. Med tanke på den återkommande logistiken kring förnyelse av USB-tokens med 15 månaders intervaller kommer denna migrering sannolikt att vara kostnadseffektiv inom den första förnyelsecykeln.

Steg 4 — Verifiera konfigurationen av tidsstämpling. Granska dina signeringspipelines för att bekräfta att RFC 3161-tidsstämplar tillämpas på varje signeringsåtgärd med hjälp av SHA-256 och behandla även en saknad tidsstämpel som ett blockeringsfel i din pipeline.

Steg 5 — Uppdatera pipelinekonfigurationer för dynamiska certifikatreferenser. Granska alla CI/CD-pipelinekonfigurationer , byggskript och signeringsverktygskonfigurationer som refererar till signeringscertifikat. Ersätt statiska identifierare med dynamiska referenser som inte behöver uppdateras manuellt vid varje förnyelse.

Steg 6 — Utvärdera automatisering av hantering av certifikatlivscykeln. Om din organisation hanterar ett betydande antal certifikat över flera team eller produkter, utvärdera en dedikerad centraliserad signeringsplattform som kan automatisera identifiering, förnyelseaviseringar och pipeline-integrerad distribution.

Hur Encryption Consultings CodeSign Secure hjälper

CodeSign Secure är Encryption Consultings centraliserade, policystyrda kodsigneringsplattform. Den utformades just för den miljö som 460-dagarsförändringen accelererar: en miljö där signeringsoperationer måste automatiseras, nycklar måste hanteras centralt i HSM-baserad infrastruktur och certifikatlivscykelhändelser måste spåras och åtgärdas utan att vara beroende av enskilda utvecklares medvetenhet.

Centraliserad HSM-baserad nyckelhantering

CodeSign Secure lagrar alla privata signeringsnycklar i FIPS 140-2 nivå 3-certifierade hårdvarusäkerhetsmoduler – vilket helt eliminerar USB-tokenmodellen. Plattformen integreras med Thales Luna, Entrust nCipher, Utimaco, Securosys och större moln-HSM:er från AWS och Azure. Privata nycklar genereras inuti HSM:n, exporteras aldrig och är endast tillgängliga via plattformens signerings-API.

Aviseringar om certifikatlivscykel och förnyelse

CodeSign Secure upprätthåller en centraliserad inventering av alla certifikat som hanteras, med insyn i utgångsdatum och konfigurerbara förnyelseaviseringar. Säkerhets- och driftteam får förhandsmeddelanden innan certifikaten löper ut, vilket eliminerar risken att upptäcka ett utgånget certifikat.

CI/CD Pipeline Integration

Plattformen integreras direkt med Azure DevOps, Jenkins, GitLab CI och andra större pipeline-system via både API- och kommandoradsgränssnitt. Signeringsåtgärder utförs med pipelinen som refererar till det aktuella giltiga certifikatet dynamiskt via plattformen snarare än via en statisk certifikatreferens. När ett certifikat förnyas fortsätter pipeline-signeringsåtgärderna utan avbrott och utan att kräva uppdateringar av pipeline-konfigurationen.

Postkvantberedskap

I takt med att certifikatindustrin övergår till kortare livslängder förbereder den sig också för den post-kvantkryptografiska migrering som NIST redan har standardiserat. CodeSign Secure v3.02 stöder ML-DSA (FIPS 204) för signering genom att tillhandahålla avtagbara signaturer, vilket gör det möjligt för organisationer att börja övergå till kvantresistenta algoritmer samtidigt som de bibehåller kompatibilitet med befintliga plattformar.

Vanliga frågor om partihandel med mat och dryck

Gäller 460-dagarsgränsen för certifikat jag redan har?

Nej. Certifikat som utfärdats före den 1 mars 2026 behåller sin ursprungliga giltighetsperiod och utgångsdatum. 460-dagarsgränsen gäller endast för certifikat som utfärdats eller förnyats på eller efter det datumet, utan respitperiod.

Betyder kortare giltighetstid att jag behöver oroa mig mindre för återkallelse?

Nej. Bekräftad nyckelkompromettering kräver fortfarande återkallelse inom 24 timmar enligt kodsigneringsgrundkraven, på ett 460-dagarscertifikat precis som på det gamla 39-månaderscertifikatet. Kortare giltighetstid sänker endast det maximala exponeringsfönstret om en kompromettering inte upptäcks; det ersätter inte behovet av en testad återkallningsprocess.

Behöver jag fortfarande oroa mig för att certifikatet löper ut om jag använder betrodd tidsstämpling?

För redan signerad, redan levererad programvara, nej: en giltig RFC 3161-tidsstämpel håller signaturen verifierbar efter att certifikatet har löpt ut. Du måste fortfarande förnya själva certifikatet innan det löper ut för att fortsätta signera nya utgåvor.

Är migrering av USB-tokens obligatoriskt enligt denna ändring?

Inte obligatoriskt, men starkt gynnat av förändringens ekonomiska aspekter. Samma hårdvarukrav för FIPS 140-2 Level 2+ gäller oavsett om du använder en token eller en HSM; en förnyelsecykel på 460 dagar gör bara den återkommande logistiken kring fysiska tokenbyten, förlust och CI/CD-flaskhalsar mycket vanligare än vad de var under en 3-årscykel.

Hur skiljer sig detta från CRA:s efterlevnadskrav för kodsignering?

De är separata system. Denna omröstning är en branschregel från CA/Browser Forum om certifikatlivscykel; EU:s Cyber ​​Resilience Act är en separat rättslig skyldighet om integritet och sårbarhetsinformation för firmware på produktnivå. En organisation som signerar CRA-produkter måste uppfylla båda; se CRA Compliance Architecture for Secure Code Signing för hur de överlappar varandra.

Slutsats

Ändringen av 460-dagars kodsigneringscertifikat som trädde i kraft den 1 mars 2026 är inte slutet på den här historien – det är ett steg i en riktning som CA/Browser Forum konsekvent har rört sig i åratal. De organisationer som kommer att hantera dessa förändringar med minst störning är de som behandlar certifikatlivscykelhantering som en disciplinerad, automatiserad funktion på infrastrukturnivå – inte som en periodisk manuell uppgift.

För utvecklingsteam som fortfarande förlitar sig på USB-tokens och manuella påminnelser om förnyelse är 460-dagarsförändringen rätt tillfälle att bedöma om den metoden är hållbar. Logistiken för årligt tokenbyte, uppdateringar av pipeline-konfiguration och manuell förnyelsespårning över flera certifikat kommer att snabbt förvärras i takt med att giltighetstiderna fortsätter att förkortas.

På Encryption Consulting är vår CodeSign Secure- plattform utformad för att göra den övergången praktisk, och ger ditt team HSM-baserad nyckelsäkerhet, automatiserad certifikathantering och pipeline-integrerad signering som hanterar förnyelser utan manuella ingrepp.