Förstå den nya giltighetsändringen för kodsigneringscertifikat

Kodsignering är den förtroendemekanism som låter ett operativsystem bekräfta vem som publicerade en programvara och om den har ändrats sedan signeringen. I kryptografi med offentlig nyckel innehåller ett certifikat den offentliga nyckeln, medan utgivaren håller motsvarande privata nyckel hemlig. Ett kodsigneringscertifikat binder en utgivares identitet till en offentlig nyckel, och den matchande privata nyckeln producerar signaturen som Windows SmartScreen, operativsystemets laddare och installationsprogram kontrollerar innan de litar på en körbar fil, drivrutin eller installationsprogram.

Giltighetsändringen, introducerad av CA/Browserforum, omröstning CSC-31: Maximal giltighetsreduktion, trädde i kraft den 1 mars 2026. Den här artikeln fokuserar på den giltighetsändringen: vad den nya gränsen är, det kryptografiska resonemanget bakom den, hur den interagerar med tidsstämpling och återkallelse, vem den påverkar och de konkreta steg som krävs för att anpassa sig.

Vad den nya giltighetsändringen säger

Ocuco-landskapet CA/Webbläsarforum (CA/B-forum) är den sammanslutning av certifikatutfärdare och certifikatkonsumenter, såsom webbläsar- och operativsystemleverantörer, som definierar grundkraven för offentligt betrodda certifikat. Den 13 oktober 2025 avslutades omröstningen om omröstning CSC-31, som ändrar grundkraven för kodsignering för att sätta den maximala giltighetstiden för ett kodsigneringscertifikat till 460 dagar, en minskning från det tidigare taket på 39 månader. Ändringen föreslogs av Microsoft och godkändes av Sectigo och eMudhra, och den antogs den 17 november 2025, som Grundkrav för kodsignering version 3.10.0.

Gränsen gäller för både kodsigneringscertifikat för organisationsvalidering (OV) och utökad validering (EV). Den styr giltighetsfältet som anges vid utfärdandet, så den gäller för alla certifikat som utfärdas eller förnyas den 1 mars 2026 eller senare. Certifieringar Utfärdade före det datumet med längre giltighetstid förblir tillförlitliga tills deras angivna utgångsdatum.

Numren

Attribut	Tidigare krav	Enligt CSC-31
Maximal giltighet	39 månader	460 DAYS
Giltigt datum	ej tillämplig	Mars 1, 2026
Baskravversion	v3.9	v3.10.0
Berörda certifikattyper	OV och EV	OV och EV

Även om omröstningen fastställer taket till 460 dagar, utfärdar vissa CA:er i praktiken vid 459 dagar för att lämna utrymme för klockförskjutning och utfärdandelatens. DigiCert beskriver till exempel sin utrullning som en giltighetstid på 459 dagar, och SSL.com utfärdar vid 458 dagar av samma anledning. Flera CA:er slutade sälja tvååriga och treåriga certifikat i slutet av 2025 inför förändringen, och ettåriga (366-dagars) produkter är nu standarderbjudandet.

Resonemanget bakom en kortare giltighetsperiod

Validitetsreduktionen är en tillämpning av en väletablerad nyckelhantering princip snarare än en reaktion på en enskild incident. Ett kodsigneringscertifikat binder en långlivad privat signeringsnyckel till en identitet. Ju längre bindningen är giltig, desto längre fortsätter en stulen eller missbrukad nyckel att producera betrodda signaturer, och desto större volym signerade artefakter kan en angripare skapa innan någon ingriper.

Kryptoperioder i NIST-vägledning för nyckelhantering

Detta kopplas direkt till konceptet kryptoperiod definierat i NIST Specialpublikation 800-57 Del 1 Revision 5, Rekommendation för nyckelhanteringEn kryptoperiod är den tidsperiod under vilken en nyckel är auktoriserad för användning. NIST rekommenderar att den begränsas så att risken inte ackumuleras i all oändlighet, och publikationen modellerar varje nyckel som att den rör sig genom tillstånden för aktivering, aktiv, inaktiverad, komprometterad och förstörd. Att begränsa certifikatets giltighetstid till 460 dagar innebär ett tak för den aktiva perioden för den associerade signeringsnyckeln, vilket garanterar att identitetsbindningar omvalideras minst var femtonde månad; att rotera själva signeringsnyckeln kräver att ett nytt nyckelpar genereras vid förnyelse, vilket är rekommenderad praxis.

Rekommendationer specifika för kodsignering

NIST publicerade också vägledning särskilt för detta användningsfall. NIST:s vitbok om cybersäkerhet, säkerhetsöverväganden för kodsignering, förklarar hur kodsignering levererar integritet och källautentisering, och den rekommenderar att isolera signeringsnycklar, lagra dem i en hårdvarusäkerhetsmodul som är begränsad till signeringsfunktioner, separera utvecklings- och produktionssystem för signering och kräva flera godkännare före en signeringsoperation. En kortare obligatorisk giltighetsperiod förstärker dessa kontroller genom att tvinga fram periodisk återutgivning, vilket omvaliderar utgivarens identitet och roterar nyckelbindningen enligt ett fast schema.

Hur giltighet interagerar med signering, tidsstämpling och återkallelse

För att utvärdera den operativa effekten av en kortare giltighetsperiod måste förhållandet mellan certifikatet, tidsstämpeln och återkallelsen vara exakt. Certifikatet definierar det fönster under vilket en signeringsnyckel är betrodd, tidsstämpeln registrerar när en signatur skapades, och återkallelsen återkallar förtroendet innan ett certifikat annars skulle löpa ut.

Signeringsoperationen

1. Utgivaren beräknar en kryptografisk sammanfattning av artefakten med hjälp av en godkänd hashfunktion som SHA-256.
2. Digesten signeras med den privata nyckeln, vilket producerar signaturen, som är inbäddad i artefakten tillsammans med utgivarens certifikat och dess kedja till en betrodd rot.
3. Vid verifieringstillfället beräknar laddaren om sammanfattningen, verifierar signaturen mot den publika nyckeln i certifikatet och validerar kedjan och certifikatets giltighetsstatus.

Varför en kortare giltighetsperiod inte bryter mot redan signerad programvara

En vanlig oro är att certifikat med kortare livslängd gör att tidigare utgiven programvara slutar valideras. Det kommer de inte att göra, så länge signaturen är tidsstämplad. En tidsstämpel från en betrodd tidsstämpelinstans registrerar signeringsögonblicket. Förutsatt att certifikatet var giltigt vid den tidpunkten förblir signaturen giltig under tidsstämpelns livslängd, vilket vanligtvis är mycket längre än certifikatet. Det är därför en drivrutin som signerades för flera år sedan fortfarande installeras trots att dess signeringscertifikat har löpt ut långt tidigare.

Samma egenskap är kärnan i säkerhetsproblemet som giltighetsändringen åtgärdar. Eftersom en tidsstämplad signatur överlever certifikatet fortsätter ett komprometterat certifikat att generera betrodda signaturer långt efter komprometteringsögonblicket. Att förkorta giltigheten begränsar exponeringsfönstret och återkallelsen stänger det. Återkallelsesstatus publiceras genom Listor över återkallade certifikat (CRL) och Online -certifikatstatusprotokoll (OCSP), och en CA kan återkalla ett komprometterat certifikat så att verifierare avvisar signaturer som förlitar sig på det. Eftersom en tidsstämplad signatur som gjorts före återkallningsdatumet i allmänhet förblir giltig, måste CA återställa återkallningsdatumet till den misstänkta tidpunkten för komprometteringen för att ogiltigförklara signaturer som skapats tidigare.

Nyligen inträffade händelser som illustrerar risken

Exponeringen som skapas av långlivade, dåligt styrda signeringsuppgifter är inte hypotetisk. Flera kampanjer på senare tid visar varför ekosystemet minskar certifikatens livslängd och skärper kringliggande kontroller.

AnyDesk produktionsintrång (2024)

I början av 2024 bekräftade fjärråtkomstleverantören AnyDesk att angripare hade nått deras produktionssystem och att källkod och privata kodsigneringsnycklar hade stulits, enligt rapporter från BleepingComputerFöretaget svarade genom att återkalla de berörda certifikaten och rotera sitt signeringsmaterial. Incidenter som denna visar varför begränsade certifikatlivslängder är viktiga, eftersom de minskar den period under vilken ett stulet certifikat kan utnyttjas.

Hijack Loader och GHOSTPULSE signerade kampanjer (sent 2024)

I oktober 2024 dokumenterade forskare Hijack Loader-prover (även spårade som GHOSTPULSE och IDAT Loader) signerade med legitima kodsigneringscertifikat, levererat via ClickFix social engineering-teknik som lurar användare att köra PowerShell. Utredarna hittade flera missbrukade certifikat kopplade till samma kommando- och kontrollinfrastruktur, och de utfärdande myndigheterna annullerade dem inom timmar till en dag efter att de hade meddelats. Episoden visar både det värde angripare tillmäter giltiga signaturer och den roll snabb återkallelse spelar för att begränsa missbruk.

Missbruk av kortlivade Microsoft Trusted Signing-certifikat (2025)

I mars 2025 observerades angripare som signerade skadlig kod genom Microsofts betrodda signeringstjänst med tredagarscertifikatDet här fallet illustrerar två distinkta dynamiker. Det visar att beslutsamma aktörer fortfarande kommer att söka giltiga signaturer, men det demonstrerar också det defensiva värdet av kortlivade, centralt utfärdade certifikat: autentiseringsuppgifterna överlämnas aldrig till utvecklaren, så de kan inte stjälas från en slutpunkt, och de löper ut och kan återkallas nästan omedelbart. Den modellen är precis den riktning som giltighetsminskningen uppmuntrar.

Industriell skala av teckenförares misshandel (2020 till 2025)

En utredning från 2025 av Grupp-IB spårade en långvarig operation som samlade på sig fler än 80 certifikat och över 60 konton i Windows Hardware Compatibility Program och signerade fler än 620 skadliga Windows-kärndrivrutiner mellan 2020 och första kvartalet 2025, ofta med stulna certifikat eller certifikat som erhållits via nybildade skalbolag. Kärndrivrutiner körs på den mest privilegierade nivån i operativsystemet, så en giltig signatur på en skadlig drivrutin är extremt kraftfull. Kortare giltighetstid stoppar inte bedrägligt utfärdande i sig, men i kombination med lagring av hårdvarunycklar och snabb återkallelse minskar det livslängden för varje missbrukad autentiseringsuppgift.

Vem påverkas och i vilken grad

Alla organisationer som signerar programvara med ett offentligt betrott certifikat omfattas av 460-dagarsgränsen. Mängden operativa förändringar beror huvudsakligen på hur signeringsnycklar lagras och hur förnyelse hanteras.

Störst påverkan: arbetsflöden för fysisk hårdvarutoken

Sedan den 1 juni 2023 har CA/B-forumet krävt att privata nycklar för kodsignering genereras och lagras på hårdvarumöten. FIPS 140-2 Nivå 2 eller Common Criteria EAL 4+, vanligtvis en USB-token eller en HSM. Team som är beroende av fysiska USB-tokens som skickas av CA:n känner av denna förändring mest, eftersom varje förnyelse kan innebära provisionering och leverans av en ny token. Med en kadens på femton månader snarare än en på tre år sker det logistiska arbetet mycket oftare.

Lägsta påverkan: moln- och HSM-baserad signering

Organisationer som signerar via en molnsigneringstjänst eller ett nätverk HSM, där nycklar provisioneras och roteras över ett API, absorberar ändringen med liten friktion. För dem är en förnyelse till stor del en programvaruhändelse som kan automatiseras från början till slut. Asymmetrin är avsiktlig, eftersom den bredare policyinriktningen gynnar automatiserad, centralt hanterad signering framför manuell tokenhantering.

Operativ påverkan

Förnyelsefrekvens

Att höja tidsgränsen från 39 månader till 460 dagar innebär att certifikat måste bytas ut minst var femtonde månad. Över ett fast tidsfönster är det mer än dubbelt så många förnyelsehändelser. För en utgivare som kör flera signeringscertifikat över olika produkter och byggsystem måste varje förnyelse schemaläggas och köras utan att lanseringsprocessen stoppas.

Automatiseringskrav

Manuell spårning via kalkylblad och kalenderpåminnelser skalas dåligt i takt med att förnyelser blir vanligare. En missad förnyelse kan blockera en version eller skicka binärfiler som utlöser SmartScreen-varningar. Certifikat Lifecycle Management Verktyg som upptäcker signeringscertifikat, övervakar utgångsdatum och orkestrerar förnyelse via CA-API:er är den praktiska kontrollen. Det är samma automatiseringstryck som driver den parallella minskningen av TLS-certifikatens livslängd mot 47 dagar till 2029 enligt CA/Browser Forum Ballot SC-081v3.

Kontinuitet genom tidsstämpling

Eftersom tidsstämplade signaturer förblir giltiga även efter att signeringscertifikatet har löpt ut, bör varje signeringsåtgärd inkludera en tidsstämpel från en pålitlig tidsstämpelutfärdare. Detta skiljer den utgivna programvarans livslängd från certifikatets kortare livslängd och förhindrar att giltighetsändringen påverkar kod som redan finns i fältet.

Efterlevnad nu när kravet gäller

Med 460-dagarsgränsen som nu gäller måste varje nytt och förnyat certifikat uppfylla kraven. Följande steg säkerställer att en organisation uppfyller kraven och går från manuell, reaktiv hantering till en kontrollerad livscykel.

1. Inventera alla kodsigneringscertifikat över team, byggservrar och produkter, registrera ägaren och var varje privat nyckel lagras.
2. Klassificera nyckellagring efter typ, separera fysiska USB-token-arbetsflöden från moln- eller HSM-baserade nycklar, och prioritera de tokenbaserade för modernisering.
3. Använd automatisering av certifikatlivscykelhantering för att övervaka utgångsdatum, varna ägare före deadlines och förnya via CA-API:er där det stöds.
4. Tillämpa tidsstämpling vid varje signering så att utgiven programvara förblir giltig efter att certifikatet har löpt ut.
5. Härda signeringsmiljön enligt NIST-riktlinjer: HSM-lagrade nycklar, separering av utvecklings- och produktionssignering, godkännande av flera parter och isolerade signeringssystem.
6. Kör en fullständig förnyelsecykel enligt det nya schemat så att varje förnyelse under 460-dagarsregeln är rutinmässig snarare än störande.
7. Bibehåll beredskap för återkallelse, med en definierad process för att snabbt återkalla och signera på nytt om en nyckel misstänks vara komprometterad, eftersom utgångsdatum ensamt inte är tillräckligt skydd.

Möt det nya kravet med Encryption Consultings CodeSign Secure

En kortare giltighetsperiod gör kodsignering till ett återkommande livscykelproblem snarare än en uppgift som inträffar en gång vartannat år, vilket är precis där en centraliserad signeringsplattform förtjänar sin plats. CodeSign Secure är en centraliserad, säker och skalbar kodsigneringsplattform byggd för att hjälpa organisationer att signera kod säkert utan att offra säkerhet eller hastighet. Den är utformad för moderna DevOps-miljöer och integreras med CI/CD-pipelines som Azure DevOps, Jenkins och GitLab, samtidigt som den tillämpar strikta åtkomstkontroller och godkännandearbetsflöden som håller signeringsprocessen ren och kompatibel i takt med att förnyelser blir vanligare.

Funktioner anpassade till giltighetsförändringen

Flera CodeSign Secure-funktioner kopplas direkt till de kontroller som det nya 460-dagarstaket driver organisationer mot:

• HSM-baserad nyckelsäkerhet. Privata nycklar lagras i FIPS 140-2 nivå 3 HSM:er, vilket överträffar CA/Browser Forums krav på hårdvarulagring, med stöd för Entrust nCipher, Thales Luna, Utimaco och Securosys över lokala och molnbaserade HSM:er.
• Policydriven åtkomstkontroll. Integration med Active Directory och Keycloak, detaljerad rollbaserad åtkomstkontroll och arbetsflöden för godkännande i flera steg framtvingar separation av uppgifter, så ingen artefakt signeras om den inte uppfyller den obligatoriska certifikattypen, signeringssteget och godkännandena. Detta implementerar direkt det flerpartsgodkännande och den nyckelisolering som NIST rekommenderar för kodsignering.
• Sömlös CI/CD-integration. Säkerhetskontroller för releaser och integritetsvalidering förhindrar att osignerade artefakter når produktion, med centraliserad spårning och omedelbara aviseringar om obehöriga signeringsförsök, vilket håller höghastighetspipelines kompatibla genom mer frekventa förnyelsecykler.
• Brett format och plattformsstöd. Signering täcker .exe, .dll, .jar, .apk, .dmg, Docker-containrar och firmware-binärfiler i Windows, Linux och macOS, och integreras med en anpassad PKCS11-omslag och verktyg som Signtool, Jarsigner och JSign.
• Klientsidig hashing och säker tidsstämpling. Hashkoder genereras på klienten via en anpassad Key Storage Provider för Microsofts CNG-ramverk, och säkra tidsstämplar bevarar signaturgiltigheten efter att certifikatet har löpt ut, vilket är viktigt under kortare giltighetsperioder.
• Omfattande revisionsloggar. Detaljerade händelseloggar registrerar varje godkännande-, avslags- och signeringshändelse för efterlevnad och incidentutredning, med SIEM-integration för Grafana, Loki och Splunk via OpenTelemetry.
• Flexibla distributionsmodeller. Organisationer kan köra en fullständigt hanterad molnbaserad tjänst med inbyggd HSM-säkerhet och fullständig API-åtkomst eller distribuera lokalt samtidigt som de hanterar nycklar i moln-HSM:er, lokala HSM:er eller båda.
• Stöd för post-kvantkryptografi. CodeSign Secure stöder de NIST-erkända ML-DSA- och LMS-kvantumresistenta signaturschemana direkt på HSM, tillsammans med dubbelsignering som parar ihop en klassisk RSA eller ECDSA signatur med en post-kvantumsignatur för en gradvis övergång.

Oavsett om du hanterar dussintals signeringsidentiteter över distribuerade team, kör höghastighets CI/CD-pipelines eller arbetar under strikta efterlevnadsmandat inom sektorer som fordonsindustrin, sjukvården eller fintech, absorberar CodeSign Secure den extra förnyelsekostnaden som 460-dagarsgränsen introducerar och förvandlar kodsignering till en styrd, automatiserad livscykel.

Slutsats

Att minska giltighetstiden för kodsigneringscertifikat till 460 dagar tvingar fram en kortare kryptoperiod för signering av nycklar, begränsar fönstret inom vilket ett komprometterat certifikat kan missbrukas och anpassar kodsignering till den automatiseringsdrivna modell som redan omformar TLS. Nyligen inträffade incidenter som involverade AnyDesk, Hijack Loader, Microsoft Trusted Signing och storskaligt missbruk av signerade drivrutiner pekar alla mot samma slutsats: långlivade, löst styrda signeringsuppgifter är en belastning, och att begränsa deras livslängd är en förnuftig åtgärd.

För organisationer som fortfarande spårar certifikat manuellt och förlitar sig på fysiska tokens är den främsta konsekvensen mer frekventa förnyelser. För de som behandlar kodsignering som en automatiserad livscykel med identifiering, övervakning, tidsstämpling och hårdvarubaserade nycklar är förändringen en mindre justering. Med ikraftträdandedatumet den 1 mars 2026 nu passerat är det inte längre valfritt att slutföra den förändringen utan ett aktuellt operativt krav.