Giltighetstiden för kodsigneringscertifikat är det maximala antalet dagar som ett offentligt betrott kodsigneringscertifikat kan förbli giltigt innan det måste förnyas. Sedan den 1 mars 2026 har den siffran sjunkit till 460 dagar, en minskning från de 39 månader som team har förlitat sig på i åratal. Regeln kommer från CA/Browser Forum Ballot CSC-31 (antagen 17 november 2025, publicerad Code Signing Baseline Requirements v3.10.0), gruppen av certifikatutfärdare och webbläsarleverantörer som fastställer de regler som varje offentligt certifikat måste följa. Den här bloggen behandlar vad som förändras, hur signering och tidsstämpling fungerar, var privata nycklar måste finnas och hur man förbereder sig utan att behöva krångla i sista minuten.
Efterlevnad av kodsignering enligt 460-dagarsregeln, definierad: att hålla alla offentligt betrodda kodsigneringscertifikat som utfärdats från och med den 1 mars 2026 inom dess maximala giltighetstid på 460 dagar, med en testad återkallningsprocess, obligatorisk RFC 3161-tidsstämpling och HSM-baserad nyckellagring, allt centralt inventerat så att en 15-månaders förnyelsekadens inte överskrider manuell spårning.
Key Takeaways
- Omröstning CSC-31 antogs den 17 november 2025 (Code Signing Baseline Requirements v3.10.0); 460-dagarsgränsen trädde i kraft den 1 mars 2026 för certifikat utfärdade från och med det datumet.
- Den här webbplatsen behandlar denna omröstning mer ingående i Säker kodsignering: Reducerad certifikatgiltighet till 460 dagar och Livslängden för kodsigneringscertifikat blir kortare, och som en del av en efterlevnadsarkitektur med dubbla system i CRA-efterlevnadsarkitektur för säker kodsigneringBörja där för fullständig information om styrning av omröstningar och checklista för granskning; den här sidan fokuserar på byggpipeline och tidsstämplingsmekanik.
- Bekräftad nyckelkompromettering kräver fortfarande återkallelse av certifikatutfärdaren inom 24 timmar oavsett certifikatets giltighetstid; kortare giltighetstid sänker det maximala exponeringsfönstret, det ändrar inte den tidsfristen.
- En giltig RFC 3161-tidsstämpel håller redan levererad programvara verifierbar efter att signeringscertifikatet har löpt ut; det som stoppar är möjligheten att signera något nytt.
Vad som ändrades den 1 mars 2026
Regeln i sig är enkel. Alla kodsigneringscertifikat som utfärdats den 1 mars 2026 eller senare får inte ha en giltighetsperiod längre än 460 dagar, eller ungefär 15 månader. Certifikat som utfärdats före det datumet fortsätter att gälla enligt sitt ursprungliga schema tills de löper ut naturligt, så ett tag kommer du att ha en blandning av långlivade och kortlivade certifikat samtidigt. Regeln gäller lika för organisationsvaliderings- (OV) och förlängda validerings- (EV) certifikat, utan undantag för någon av typerna, och den speglar ett mönster som branschen redan arbetat igenom med TLS-certifikat. Kodsignering håller helt enkelt på att komma ikapp nu.
Resonemanget är enkelt ur ett riskperspektiv. Ett kodsigneringscertifikat representerar förtroende, och det förtroendet kvarstår så länge certifikatet är giltigt. Om den privata nyckeln bakom det någonsin blir stulen eller missbrukad, varar skadan exakt lika länge som certifikatet gör. Ett treårigt certifikat ger en angripare ett treårigt fönster för att fortsätta använda en stulen nyckel. Ett 460-dagars certifikat mer än hälften av det fönstret och tvingar organisationer att rotera nycklar enligt ett förutsägbart schema istället för att lämna dem orörda i åratal.
Kortare livslängder driver team mot automatisering nästan med våld, eftersom manuell certifikathantering snabbt bryts ner när förnyelse sker var 15:e månad istället för vart tredje år. Den övergången, från en sällsynt syssla till en rutinmässig operativ process, är egentligen poängen med regeln, mer än det specifika antalet valda dagar.
Hur kodsignering och tidsstämpling faktiskt fungerar tillsammans
När en utgivare signerar programvara skapas en hash, ett unikt fingeravtryck av koden som ändras fullständigt om ens en byte ändras. Den hashen signeras med utgivarens privata nyckel, vilket producerar en digital signatur som bifogas programvaran tillsammans med utgivarens offentliga certifikat. När en användare laddar ner filen beräknar deras operativsystem om hashen och kontrollerar den mot signaturen med den offentliga nyckeln. Om den matchar och certifikatet länkas tillbaka till en betrodd rot-CA visas programvaran som verifierad; om något har ändrats sedan signeringen misslyckas signaturen. Det är därför den privata nyckeln är så viktig, och varför reglerna kring var den finns blir allt strängare.
Detta väcker en uppenbar fråga: vad händer med programvara som du signerade för flera år sedan när certifikatet bakom den löper ut? Svaret är tidsstämpling, den enskilt viktigaste detaljen i denna övergång. När du signerar kod kan dina verktyg också skicka signaturen till en tidsstämpelutfärdare (TSA), en betrodd tredje part som registrerar kryptografiskt bevis på när signaturen skapades, enligt IETF RF C 3161 Time-Stamp Protocol , en standard som de flesta signeringsverktyg redan stöder.
När en tidsstämpel har bifogats kan operativsystemet bekräfta att signaturen skapades medan certifikatet fortfarande var giltigt, även efter att certifikatet har löpt ut. Förtroendet låses vid signeringsögonblicket, inte när någon öppnar filen, vilket är det som gör frekvent rotation fungerande överhuvudtaget.
Haken är att tidsstämpling inte är automatisk överallt. Vissa äldre byggskript hoppar över det, och vissa äldre verktyg verifierar det inte ordentligt. Med certifikat som nu löper ut ungefär var 15:e månad är det värt att granska din signeringsprocess idag för att bekräfta att varje byggprocess är korrekt tidsstämplad. Att få tidsstämplingen rätt är dock bara halva jobbet; den andra halvan är att se till att pipelinen kring det kan hålla jämna steg med certifikat som nu omsätts var 15:e månad istället för vartannat år.
Förbereda din byggpipeline
För de flesta team handlar den operativa effekten om ett fåtal konkreta förändringar. Byggsystem kan inte längre hårdkoda en certifikatsökväg och anta att den kommer att fungera i åratal; pipelines måste hämta det aktuella giltiga certifikatet dynamiskt istället för att peka på en statisk fil som så småningom blir inaktuell mitt i lanseringen. Signeringsmiljöer med luftgapp, vanliga inom industriell styrning, hälso- och sjukvård och myndighetsprogramvara, behöver ett förutsägbart schema för att importera nya certifikat, eftersom de ofta inte kan hämta en förnyelse automatiskt.
Fleråriga certifikatköp måste ge vika för mer frekvent budgetering för förnyelser och godkännande, och alla som hanterar EV- eller OV-certifikat behöver en förnyelsekalender som tar hänsyn till CA-valideringstid, vilket kan ta några dagar och aldrig bör vänta till sista minuten.
Inget av detta är svårt i sig. Den verkliga utmaningen är att signering historiskt sett har behandlats som en installationsuppgift som görs med några års mellanrum, inte en pågående process. Att arbeta igenom det som en kort sekvens gör övergången hanterbar. Börja med en fullständig inventering: lista alla kodsigneringscertifikat på byggservrar, CI/CD-pipelines, signeringsarbetsstationer och air-gapped-miljöer, registrera den utfärdande CA:n, utgivningsdatum, utgångsdatum och var varje privat nyckel finns. Detta avslöjar vanligtvis fler certifikat än team förväntar sig.
Gör sedan tidsstämpling icke-förhandlingsbart genom att granska dina signeringsskript för att bekräfta att varje version är tidsstämplad via en betrodd TSA. Automatisera sedan förnyelse och nyckelrotation där manuella steg återstår, eftersom manuell förnyelse inte skalas upp när certifikaten löper ut var 15:e månad. Slutligen, sätt upp en tydlig policy för nyckelstyrka, godkända algoritmer, obligatorisk HSM-certifieringsnivå och certifikatägande, och för en granskningslogg för varje signeringsåtgärd så att efterlevnadsgranskningar förblir smärtfria.
Några misstag dyker upp gång på gång. Här är några tips för att åtgärda dem:
- Anta inte att alla dina certifikat går ut samma datum; du kommer att ha en blandning av certifikat med lång och kort giltighetstid som samexisterar ett tag.
- Glöm inte att pipelines som byggs runt en statisk certifikatfil kommer att brytas i det ögonblick certifikatet löper ut, ofta mitt i lanseringen.
- Behandla inte tidsstämpling som valfritt, eftersom det är den viktigaste faktorn för om äldre signerad programvara förblir tillförlitlig.
- Lämna inte privata nycklar orörda vid förnyelser, eftersom det omintetgör mycket av den säkerhetsfördel som kortare giltighetstid är avsedd att ge.
Återkallelse blir inte enklare bara för att giltighetstiden är kortare
Enligt kodsigneringsgrundkraven §4.9.1.1 måste en certifikatutfärdare fortfarande återkalla ett certifikat inom 24 timmar efter att ha bekräftat att en privat nyckel har komprometterats, oavsett om certifikatet har en 460-dagarscykel eller den gamla 39-månaderscykeln. Kortare giltighetstid begränsar endast den maximala exponeringen om en kompromettering inte upptäcks; det ersätter inte att kunna identifiera, inom en timme, varje artefakt som ett givet certifikat har signerat. Bygg den kapaciteten innan du behöver den, inte under en incident.
Hanterat på detta sätt slutar kortare certifikatlivstider att vara ett krångel och blir en rutinmässig del av hur du levererar programvara. Och de vanor du bygger upp nu är precis vad nästa, större kryptografiska skifte kommer att kräva, så ansträngningen är aldrig bortkastad.
Hur detta kopplas till kryptoagilitet och postkvantberedskap
Samma färdigheter som du bygger upp för att hantera 460-dagars kodsigneringscertifikat, nämligen identifiering, automatisering och snabb rotation, är precis vad din organisation kommer att behöva för den bredare övergången mot postkvantkryptografi (PQC). NIST slutförde sina första postkvantstandarder i augusti 2024: FIPS 203 (ML-KEM) för nyckelinkapsling, och FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) för digitala signaturer. Dessa är slutgiltiga standarder, inte utkast, och organisationer förväntas planera kring dem idag.
Kodsignering har sin egen deadline som är värd att känna till. NSA:s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) kräver att programvaru- och firmwaresignering stöder och föredrar postkvantalgoritmer, särskilt de tillståndsfulla hashbaserade schemana LMS och XMSS (NIST SP 800-208), en fas som började 2025, med exklusiv användning som krävs senast 2030. Att bygga starka kryptografiska inventerings- och rotationsvanor nu, samtidigt som man arbetar sig igenom 460-dagarsövergången, placerar ditt team steget före den förändringen istället för att börja om från början senare.
Kryptoagilitet är förmågan att ersätta kryptografiska algoritmer, nycklar och certifikat med minimal störning av befintliga system, vilket gör det möjligt för organisationer att snabbt reagera på algoritmförfall, förändrade regelkrav eller nya hot utan att omforma sin signeringsinfrastruktur. I praktiken innebär detta att migrering till nya standarder, såsom de som krävs enligt CNSA 2.0 eller framtida post-kvantum-vägledning, blir en operativ förändring av kryptografisk policy snarare än en kostsam ingenjörsinsats.
Det ger också operativ motståndskraft. Om en signeringsalgoritm är föråldrad, en sårbarhet upptäcks eller myndighetsgodkännanden ändras, kan organisationer övergå till en alternativ algoritm utan att avbryta pipelines för programvarulansering. Under perioden efter kvantmigrering är den rekommenderade strategin hybrid kodsignering, där varje artefakt signeras med både en klassisk algoritm (som ECDSA eller RSA) och en postkvantalgoritm (som ML-DSA eller LMS). Detta gör det möjligt för förlitande parter att validera signaturer med hjälp av båda schemana, vilket bevarar interoperabilitet med befintliga system samtidigt som kryptografisk kontinuitet tillhandahålls i takt med att postkvantstöd blir utbrett.
Organisationer som redan har moderniserat sin kodsigneringsinfrastruktur med automatiserad hantering av certifikatlivscykeln, regelbunden certifikatrotation, säker nyckellagring i hårdvarubaserade miljöer och RFC 3161-kompatibel tidsstämpling är betydligt bättre positionerade för att anta nya algoritmer i takt med att standarder utvecklas. I praktiken är det mycket enklare att nå denna nivå av kryptoagilitet med specialbyggda verktyg och rätt expertis bakom det.
Hur krypteringskonsulting kan hjälpa
Att anpassa sig till kortare giltighetstid för kodsignering är mycket enklare när dina certifikat- och nyckelhanteringsrutiner redan är organiserade, snarare än utspridda över team och verktyg. Encryption Consulting arbetar med säkerhets-, PKI- och DevSecOps-team för att skapa struktur för just denna typ av övergång, med början i en tydlig bild av var varje certifikat och nyckel faktiskt finns idag.
Vårt team hjälper organisationer att bygga och modernisera sin infrastruktur för publika nycklar, och vår CodeSign Secure- plattform är specifikt byggd för att operationalisera metoderna i den här bloggen: HSM-baserad lagring av privata nycklar, policydrivna arbetsflöden för godkännande, automatisk tidsstämpling vid varje signeringsoperation och detaljerade revisionsloggar. CodeSign Secure inkluderar även inbyggt stöd för post-kvantumsigneringsalgoritmer som ML-DSA och LMS, så team som använder det nu startar inte ett andra migreringsprojekt när CNSA 2.0-deadlines når.
Utöver kodsignering hjälper vi till med bredare hantering av certifikatlivscykeln, nyckelhantering och efterlevnadskartläggning mot standarder som NIST och PCI DSS, så att din signeringsprocess håller både under granskning och attacker.
Slutsats
Övergången till 460-dagars kodsigneringscertifikat är en meningsfull förändring, men en hanterbar sådan om du börjar nu. Bygg en tydlig inventering av dina certifikat, gör tidsstämpling till standard, rotera privata nycklar vid varje förnyelse och automatisera där manuella steg återstår. Team som behandlar detta som rutinmässigt underhåll kommer knappt att märka övergången. Team som väntar kommer att känna av det i sitt releaseschema, troligen mer än en gång, eftersom detta är den första av flera förkortningar av certifikatens livslängd som ännu inte har kommit. Om du vill ha hjälp med att förbereda din kodsignering och certifikatlivscykelhantering för denna förändring, eller för vad som kommer efter den, är Encryption Consulting ett bra ställe att starta den konversationen.
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 giltighet och sitt utgångsdatum. Taket gäller endast för certifikat som utfärdats eller förnyats på eller efter det datumet.
Behöver jag fortfarande oroa mig för att certifikatet ska löpa ut om jag tidsstämplar allt?
För programvara som du redan har levererat, nej, en giltig RFC 3161-tidsstämpel håller den verifierbar. Du behöver fortfarande ett giltigt, outgånget certifikat för att signera en ny utgåva, så förnyelse måste fortfarande ske enligt schema.
Minskar kortare giltighetstid brådskan med återkallelseplanering?
Nej. Bekräftad nyckelkompromettering kräver fortfarande återkallelse inom 24 timmar enligt kodsigneringsgrundkraven, oavsett hur lång certifikatets giltighetsperiod är.
