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.
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.
- 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. - 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.
- 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å.
Vad du borde 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.
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.
