Livslängden för kodsigneringscertifikat blir kortare

Kodsigneringscertifikat autentiserar programvara innan den når slutanvändare. De bekräftar att en binärfil, installationsprogram eller uppdatering kommer från en verifierad utgivare och inte har ändrats under transport. I åratal var den operativa modellen kring dessa certifikat enkel: skaffa ett med en flerårig giltighetsperiod, lagra det i en byggmiljö och förnya det när påminnelsen om utgångsdatum kom. Den modellen skapade en tyst men verklig risk, eftersom ett certifikat som är giltigt i 39 månader innebär att en komprometterad privat nyckel förblir betrodd under hela den perioden om inte någon upptäcker det och återkallar det i tid.

Enligt CA/Browser Forum Ballot CSC-31, antagen den 17 november 2025 och införlivad i Code Signing Baseline Requirements version 3.10.0, sänktes den maximala giltighetsperioden för offentligt betrodda kodsigneringscertifikat från 39 månader till 460 dagar, ungefär 15 månader. Alla kodsigneringscertifikat som utfärdats från och med den 1 mars 2026 måste uppfylla denna gräns. Certifikat som utfärdats före det datumet förblir giltiga tills deras naturliga utgångsdatum, men vid tidpunkten för förnyelse gäller den nya tidslinjen.

Detta är inte en isolerad händelse. Det följer samma utveckling som TLS-certifikat , som minskade från 398 dagar till 200 dagar från och med den 15 mars 2026, och planeras att minska ytterligare till 100 dagar den 15 mars 2027 och 47 dagar den 15 mars 2029, enligt CA/B Forum Ballot SC-081v3, som antogs i april 2025. Kodsignering och TLS konvergerar kring samma princip: certifikat bör inte överleva de förtroendevillkor under vilka de utfärdades. Branschen satsar på automatisering för att göra detta praktiskt möjligt.

Den här bloggen går igenom vad som förändrats, var risken ligger och vad organisationer behöver åtgärda inför nästa förnyelsecykel.

Varför certifikatens giltighetsperioder krymper

Övergången mot kortare livslängder för certifikat är inte godtycklig. Den åtgärdar två problem som har funnits med offentlig PKI under lång tid: gapet mellan när ett certifikat komprometteras och när det faktiskt slutar vara betrott, och hur långsamt organisationer går över till starkare kryptografiska standarder när deras befintliga certifikat fortfarande fungerar bra.

När en privat signeringsnyckel exponeras förblir certifikatet som är kopplat till den giltigt tills det antingen löper ut eller återkallas. Återkallelse har välkända tillförlitlighetsproblem. Certificate Revocation Lists (CRL) och Online Certificate Status Protocol (OCSP) kontrolleras inte konsekvent av alla plattformar, och när en återkallningskontroll misslyckas eller får tidsgränsen behandlar de flesta system det som ett godkänt snarare än ett block.

Resultatet blir att ett komprometterat certifikat kan förbli ett gångbart attackverktyg så länge det förblir tillförlitligt. Enligt den tidigare giltighetsmodellen på 39 månader kunde en komprometterad enskild nyckel potentiellt utsätta en organisation för mer än tre års risk. Med den nya gränsen på 460 dagar minskas det maximala exponeringsfönstret avsevärt.

Det andra problemet är att organisationer tenderar att inte ersätta fungerande certifikat i förtid, även när bättre algoritmalternativ finns tillgängliga. Branschen lärde sig detta under SHA-1-utfasningen och övergången från 1024-bitars RSA-nycklar. Båda övergångarna drog ut på tiden mycket längre än nödvändigt eftersom långlivade certifikat inte gav organisationer någon naturlig deadline att agera.

Kortare giltighetsperioder ändrar på det. Varje förnyelse är en möjlighet att anta nuvarande standarder. Detta är särskilt viktigt nu, med tanke på att NIST slutförde sina första post-kvantkryptografistandarder , FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), i augusti 2024. Organisationer som förnyar certifikat regelbundet kommer att vara mycket bättre positionerade för att anta kvantresistenta algoritmer i takt med att plattforms- och CA-stöd utvecklas.

Kortare livslängder för certifikat minskar skadorna från en viktig kompromiss, minskar beroendet av återkallningsmekanismer som inte alltid fungerar och håller kryptografiska standarder aktuella i hela ekosystemet. Att tillämpa detta på kodsigneringscertifikat är ett direkt steg mot starkare säkerhet i programvaruleveranskedjan . Ballot CSC-31 formaliserade detta steg med en specifik maximal giltighetsgräns och ett fast ikraftträdandedatum för alla offentligt betrodda kodsigneringscertifikat.

Vad röstsedeln CSC-31 faktiskt förändrade

CA/B Forum-omröstningen CSC-31 föreslogs av Microsoft, och omröstningsperioden avslutades den 13 oktober 2025, och omröstningen antogs formellt den 17 november 2025, efter granskningsperioden för immateriella rättigheter. Sju av nio certifikatutfärdarmedlemmar röstade för, två nedlagda röster och ingen emot. Den enda rösten från certifikatkonsumenten, avgiven av Microsoft, var också för. Granskningsperioden för immateriella rättigheter avslutades den 17 november 2025, utan att några undantagsmeddelanden hade inkommit.

De uppdaterade grundkraven för kodsignering version 3.10.0 publicerades den 17 november 2025, med den nya giltighetsgränsen som trädde i kraft den 1 mars 2026. Kravet gäller alla offentligt betrodda kodsigneringscertifikat, det vill säga certifikat som utfärdats av CA:er vars rötter är inbäddade i operativsystem och webbläsares betrodda arkiv. Privata PKI som används för interna signeringsarbetsflöden regleras inte av CA/B-forumets regler, även om det är en rimlig strategi att anpassa interna rutiner till samma standard.

En praktisk detalj som är viktig: 460-dagarsgränsen beräknas från utfärdandedatumet, inte det datum då beställningen gjordes. Ett certifikat som begärdes före den 1 mars 2026, men utfärdades på eller efter det datumet, omfattas av det nya taket. De flesta certifikatutfärdare (CA) slutade utfärda 2- och 3-åriga kodsigneringscertifikat i slutet av februari 2026 för att upprätthålla tidsfristen ordentligt. Alla offentligt betrodda kodsigneringscertifikat som utfärdats från och med den 1 mars 2026 har en maximal giltighetstid på 460 dagar.

Att uppfylla 460-dagarsgränsen på papper är enkelt. Den svårare frågan är om den befintliga signeringsinfrastrukturen någonsin byggdes för att fungera enligt den takten.

Varför skyltinfrastruktur inte byggdes för detta

Hoppet från ett 39-månaderscertifikat till ett 460-dagarscertifikat låter som en enkel förändring av förnyelsekalendern. I praktiken blottlägger det strukturella problem i hur de flesta organisationer har konfigurerat sina signeringsarbetsflöden.

Det första är nyckellagring. Grundkraven för kodsignering kräver redan att privata nycklar för alla offentligt betrodda kodsigneringscertifikat, både standard Organization Validated (OV) och Extended Validation (EV), lagras i en hårdvarukryptografisk modul som uppfyller minst Federal Information Processing Standards (FIPS) 140-2 Level 2 eller Common Criteria EAL 4+. När FIPS 140-2-valideringar flyttas till den historiska listan den 21 september 2026 bör organisationer som upphandlar ny hårdvara prioritera moduler med aktiv FIPS 140-3-validering för att säkerställa fortsatt efterlevnad efter det datumet.

För vanliga OV-certifikat är hårdvarutokens, som USB-baserade enheter, ett vanligt val, men de skapar ett fysiskt hanteringsproblem. Tokens kan gå förlorade, de är knutna till specifika individer och förnyelse innebär att hårdvaran måste tillhandahållas på nytt. Med en 460-dagarscykel sker den processen varje år istället för vart tredje år, vilket skapar betydligt mer arbete och större möjligheter att saker går fel om de inte hanteras korrekt.

Det andra problemet är pipeline-integration. Många byggsystem signerar artefakter med hjälp av ett certifikat och en nyckel som manuellt placerats i en filsystemssökväg, miljövariabel eller post i hemlighetshanteraren. När certifikatet ersätts bryts något i den kedjan. Vid en 460-dagarscykel inträffar det avbrottet oftare. Team utan heltäckande automatisering för certifikatprovisionering, generering av certifikatsigneringsförfrågningar (CSR), interaktion med CA och distribution kommer att ha svårt att hantera detta schema på ett tillförlitligt sätt.

Det tredje problemet är lagerhållning. En enda organisation kan ha dussintals kodsigneringscertifikat utspridda över produktlinjer, byggmiljöer och entreprenörsstyrda system. De team som ägde dessa certifikat för tre år sedan kan ha gått vidare. Utan en centraliserad registrering av vad som finns, vem som äger det och när det löper ut blir en 460-dagars förnyelsecykel ohanterlig.

De strukturella bristerna i signeringsinfrastrukturen skapar inte bara förnyelsefriktion; de blir kritiska hinder i det ögonblick ett certifikat komprometteras.

Vad händer när ett kodsigneringscertifikat komprometteras

Ett komprometterat kodsigneringscertifikat är inte bara en säkerhetshändelse. Det är en operativ nödsituation med en strikt tidsfrist. Enligt Code Signing Baseline Requirements version 3.10.0 måste en certifikatutfärdare (CA) återkalla ett kodsigneringscertifikat inom 24 timmar efter att ha blivit meddelad att certifikatet användes för att signera skadlig kod eller att den privata nyckeln stals eller exponerades. Det 24-timmarsfönstret lämnar väldigt lite utrymme för en långsam eller oorganiserad respons.

Det omedelbara problemet är identifiering. Innan en CA kan agera måste certifikatet i fråga identifieras exakt: dess serienummer, den utfärdande CA:n och den aktuella återkallningsstatusen. För organisationer utan en centraliserad certifikatförteckning kan detta steg ensamt ta timmar. Om signering av certifikat är spridda över team, byggmiljöer och entreprenörssystem utan någon enskild ägare registrerad, är det inte lätt att hitta rätt certifikat under press.

När certifikatet väl har återkallats kan det inte användas för att signera något nytt, och CA kommer att publicera återkallelsen via sin CRL- och OCSP-infrastruktur. Återkallningskontroll tillämpas dock inte konsekvent på alla plattformar. Det innebär att ett återkallat certifikat fortfarande kan accepteras i vissa miljöer under en period efter återkallelsen, vilket är precis det beteende som kortare certifikatlivslängder är utformade för att begränsa över tid.

Ersättningscertifikatet måste sedan utfärdas och distribueras över varje pipeline som var beroende av den komprometterade. Utan dokumenterad pipeline-integration och automatiserad distribution är detta ytterligare en manuell insats under tidspress. Organisationer med nyckellagring baserad på Hardware Security Module (HSM) är bättre positionerade här eftersom komprometteringen vanligtvis är begränsad till certifikatet snarare än den underliggande hårdvaran, och ny nyckelgenerering kan ske inom HSM utan att fysiska tokens behöver omprovisioneras mellan team.

Den operativa lärdomen är enkel: samma luckor som gör en 460-dagars förnyelsecykel svår att hantera, såsom ofullständiga certifikatinventeringar, manuella signeringspipelines och programvarulagrade privata nycklar, är också de luckor som gör incidentresponsen långsammare och mer felbenägen. Att åtgärda dessa svagheter innan en kompromiss inträffar är betydligt billigare än att försöka åtgärda dem under en aktiv incident.

Incidenthantering slutar inte med återkallelse och ersättning av certifikat. Organisationer behöver också förstå hur tidsstämpling påverkar förtroendet och användbarheten hos tidigare signerad programvara.

Tidsstämplingsfrågan som de flesta team förbiser

En aspekt av kodsignering som är viktigare under kortare certifikatlivslängder är RFC 3161- tidsstämpling . När en signatur innehåller en betrodd tidsstämpel från en tidsstämpelutfärdare (TSA) förlängs giltigheten för den signaturen bortom certifikatets utgångsdatum.

Tidsstämpeln ger kryptografiskt bevis på när programvaran signerades, vilket gör att signaturen förblir giltig även efter att kodsigneringscertifikatet har löpt ut, förutsatt att TSA:s certifikatkedja förblir giltig och betrodd vid verifieringstillfället. Som ett resultat förlorar programvara som signerades och distribuerades innan certifikatet löpte ut inte automatiskt förtroendet under den nya giltighetsgränsen på 460 dagar. 

Det som ändras är själva signeringsuppgifterna. Ett giltigt, outgånget certifikat krävs för att signera nya utgåvor, nya byggen och uppdaterade paket. När ett kodsigneringscertifikat har löpt ut kan det inte användas för att signera något nytt, även om äldre signaturer från det certifikatet fortfarande är giltiga. Effekten är direkt: alla luckor i certifikattillgängligheten stoppar programvaruleveransen. Vid en 460-dagarscykel tillåter en missad förnyelse inte tre års spelrum. Det stoppar pipelinen på dag 461.

Dessa operativa realiteter gör en sak tydlig: organisationer behöver signeringsarbetsflöden utformade för kontinuerlig certifikatförnyelse snarare än sporadiskt certifikatbyte.

Vad som behöver ändras i signeringsarbetsflöden

Att uppfylla 460-dagarsgränsen är bara början. Att bygga ett arbetsflöde som håller även under nästa minskning, vilket är troligt med tanke på att TLS-certifikat redan är på en planerad flerårig minskningsväg, kräver strukturella förändringar.

Börja med identifiering. Att hantera kodsigneringscertifikat med en 460-dagars förnyelsecykel kräver att man vet hur många som finns, var de är distribuerade, vilka pipelines som är beroende av dem och vem som äger var och en. För organisationer som har kört på den gamla 39-månadersmodellen finns detta lager ofta inte i användbar form. Att bygga det är det första steget innan något annat kan automatiseras eller hanteras tillförlitligt.

Flytta signeringsnycklar till hårdvara. Privata nycklar som lagras på filsystem, utvecklarmaskiner eller byggservrar måste flyttas till en HSM. HSM-baserad lagring uppfyller FIPS 140-2 nivå 2 -minimum som CA/B Forum Code Signing Baseline Requirements för närvarande specificerar, tar bort problemet med fysisk omprovisionering som USB-tokens skapar vid årliga förnyelsecykler och minskar risken för att en komprometterad nyckel används för att signera och distribuera skadlig programvara. Eftersom alla FIPS 140-2-valideringar flyttas till den historiska listan den 21 september 2026 bör nya hårdvaruanskaffningar rikta in sig på moduler med aktiv FIPS 140-3-validering.

Automatisera förnyelseprocessen. CA/B Forum Code Signing Baseline Requirements kräver inte automatisering, men en 460-dagarscykel gör manuell förnyelse opålitlig i någon meningsfull skala. Generering av certifikatsigneringsförfrågningar (CSR), inlämning, utfärdande och distribution av CA bör ske genom ett repeterbart, granskningsbart arbetsflöde snarare än en manuell process som startas några dagar före utgångsdatum. ACME-protokollet ( Automatic Certificate Management Environment ), där CA-stöd finns tillgängligt, tar bort manuella steg helt från förnyelseprocessen.

Planera för nästa minskning. Kodsigneringscertifikat är nu på samma minskningsväg som TLS. Organisationer som bygger automatiseringsbaserad signeringsinfrastruktur idag kommer att kunna absorbera framtida giltighetsminskningar utan att behöva bygga om från grunden. Organisationer som behandlar 460 dagar som ett permanent tak kan möta samma störningar igen när nästa omröstning går igenom.

För många organisationer kräver det specialiserad expertis, lämpliga verktyg och en strategi för etappvis implementering att bygga upp denna nivå av operativ mognad. Det är där Encryption Consulting kan hjälpa till.

Hur krypteringskonsulting kan hjälpa

CodeSign Secure är Encryption Consultings plattform för kodsigneringshantering i företagsklass, utformad för att tillhandahålla de infrastrukturkontroller som branscher behöver.

HSM-baserad nyckelhantering

CodeSign Secure lagrar alla privata signeringsnycklar i FIPS 140-2 nivå 3-certifierade hårdvarusäkerhetsmoduler , som integreras med Thales Luna, Entrust nShield, Utimaco, Securosys och moln-HSM:er från AWS och Azure. Produktnyckelisolering tillämpas på HSM-partitionsnivå: varje produktlinje får sin egen dedikerade nyckel, som genereras inuti hårdvaran och aldrig exporteras.

M-of-N-signeringsquorum och RBAC

Plattformens rollbaserade åtkomstkontrollmodell tillämpar krav på M-of-N-godkännande för signering av produktionsfirmware. Ingen enskild individ kan initiera och godkänna en signeringsoperation. Signeringsförfrågningar, godkännanden och avslag loggas alla. Själva RBAC-konfigurationen är granskningsbar och versionskontrollerad, vilket ger den dokumenterade signeringspolicy som CRA-överensstämmelsebedömningar kräver.

Oföränderlig granskningsloggning

Varje signeringshändelse i CodeSign Secure genererar en oföränderlig loggpost som registrerar artefaktens hash, nyckelidentifieraren, det använda certifikatet, den godkännande identiteten och RFC 3161-tidsstämpeln. Loggarna är centraliserade och lagras separat från signeringsinfrastrukturen.

Stöd för firmwareformat över flera plattformar

CodeSign Secure stöder signering av firmware-artefakter i alla format som en varierad produktportfölj kräver: .bin, .img, .hex, .fw, .dfu och .efi, vilket uppfyller CRA:s krav på konsekventa kontroller över produktlinjer utan att behöva bygga om signeringsinfrastrukturen för varje plattform.

Stöd för postkvantkryptografi

CodeSign Secure v3.02 stöder ML-DSA i produktionsklass (FIPS 204, på säkerhetsnivåerna ML-DSA-44, ML-DSA-65 och ML-DSA-87) och SLH-DSA (FIPS 205) som avtagbara signaturer vid sidan av klassiska algoritmer. För tillverkare som bygger produkter med CRA-supportskyldigheter på över fem år är PQC-signering idag den arkitektur som skyddar mot HNDL-hotet innan en kryptografiskt relevant kvantdator (CRQC) anländer.

CI/CD Pipeline Integration

CodeSign Secure integreras med Azure DevOps , Jenkins , GitLab CI och andra större pipeline-plattformar via API- och kommandoradsgränssnitt. Firmware-signering är ett kontrollerat, policystyrt steg i byggpipelinen, inte ett manuellt steg.

Organisationer som arbetar med 460-dagarsövergången, oavsett om det gäller att utvärdera nuvarande certifikatinventering, flytta nycklar till hårdvara eller bygga automatiserade förnyelsearbetsflöden, kan kontakta Encryption Consulting för en praktisk konsultation. Teamet arbetar direkt med organisationer för att identifiera luckor i deras signeringsinfrastruktur och bygga en praktisk väg framåt innan nästa förnyelsecykel skapar press.

Slutsats

CA/B Forum-omröstningen CSC-31 markerar ett verkligt skifte i hur offentligt betrodda kodsigneringscertifikat hanteras. Den 39-månaders giltighetstid som de flesta team byggde sina arbetsflöden kring är inte längre tillgänglig. Organisationer som ännu inte har anpassat sig kommer snart att ställas inför sin första 460-dagars förnyelse, och de infrastrukturbeslut som fattas då kommer att avgöra om framtida minskningar orsakar störningar eller hanteras smidigt.

De organisationer som navigerar detta bra är inte de som lägger till en kalenderpåminnelse och fortsätter. Det är de som behandlar 460-dagarsgränsen som den signal den är: branschen rör sig mot kortare certifikatlivslängder över hela linjen, TLS-certifikat har redan en bekräftad flerårig reduktionsplan, och kodsignering är nu på samma väg. Att bygga en automatiserad, granskningsbar signeringsinfrastruktur innebär nu att man inte behöver bygga om den igen vid nästa reduktion.

CA/B-forumet har varit konsekvent i sin inriktning. Certifikatens livslängd kommer att fortsätta att förkortas, och manuella förnyelseprocesser kommer att bli allt svårare att upprätthålla. Organisationer som investerar i identifiering, hårdvarubaserad nyckellagring och automatiserad kodsignering av certifikatlivscykelhantering idag uppfyller inte bara ett befintligt krav. De bygger grunden som kommer att bära dem genom varje framtida minskning av certifikatgiltigheten.