Bästa praxis för certifikathantering: 7 steg för 2026

Snabbt svar: Bästa praxis för certifikathantering för 2026 kombinerar kontinuerlig identifiering, centraliserad styrning och automatiserad förnyelse för att hålla offentliga TLS-certifikat giltiga under CA/Browser Forums krympande gränser på 200 dagar, 100 dagar och 47 dagar. De sju stegen nedan omfattar identifiering, policy, automatisering, domänomvalidering, övervakning, kvantberedskap och DevOps-integration.

Certifikathantering är praxisen att upptäcka, utfärda, förnya, övervaka och återkalla de digitala certifikat som säkrar en organisations system och kommunikation. Det har gått från en rutinmässig administrativ uppgift till en central cybersäkerhetsfunktion. I takt med att organisationer expanderar sin molnbaserade närvaro, anammar DevOps-metoder och ansluter fler tjänster, fortsätter antalet certifikat som distribueras i hela företaget att växa, och krympande giltighetsperioder tvingar team att ompröva hur digitalt förtroende hanteras dagligen.

Den största drivkraften bakom den förändringen är CA/Browser Forums beslut att förkorta den maximala giltighetsperioden för offentligt betrodda TLS-certifikat. Sedan den 15 mars 2026 har dessa certifikat utfärdats för maximalt 200 dagar, en minskning från 398 dagar. Taket sänks igen till 100 dagar den 15 mars 2027 och till bara 47 dagar den 15 mars 2029. Kortare livslängder minskar exponeringen för komprometterade nycklar och föråldrad kryptografi, men de mångdubblar också hur ofta varje certifikat behöver beröras.

Den operativa kostnaden för att göra detta fel är redan synlig. I DigiCerts Trust Pulse-undersökning från juli 2025 om företagscertifikatpraxis rapporterade 45 procent av organisationerna driftstopp kopplade till certifikatrelaterade incidenter föregående år, och 37.5 procent spårade ett avbrott specifikt till ett utgånget certifikat. Bland de drabbade rapporterade 31 procent förluster på 50 000 till 250 000 dollar och 18.5 procent förlorade mer än 250 000 dollar. Organisationer som fortfarande förlitar sig på kalkylblad, manuella förnyelsepåminnelser och fragmenterade lager kommer att ha svårt att hålla jämna steg i takt med att förnyelsecyklerna komprimeras ytterligare.

Den här artikeln går igenom sju bästa praxis för certifikathantering som hjälper organisationer att anpassa sig till kortare livslängder samtidigt som de förbättrar synlighet, efterlevnad och säkerhet. Artikeln avslutas med en beslutschecklista och en åtgärdsmatris för team så att PKI-, säkerhets-, plattforms- och efterlevnadsägare vet exakt vad de ska göra härnäst.

Key Takeaways

• Tre pelare, inte ett verktyg: kontinuerlig upptäckt, centraliserad styrning och automatiserad förnyelse täcker tillsammans de luckor som manuella processer lämnar öppna.
• Klockan går redan: Giltighetstiden för offentliga TLS minskade till 200 dagar den 15 mars 2026, faller till 100 dagar i mars 2027 och når 47 dagar i mars 2029, enligt CA/Browser Forum Ballot SC-081v3.
• Manuell förnyelse är en uppmätt risk, inte en hypotetisk: 45 % av organisationerna rapporterade certifikatrelaterade driftstopp under det senaste året, och 37.5 % kopplade ett avbrott direkt till ett utgånget certifikat (DigiCert, juli 2025).
• Förnyelse och domänvalidering är separata klockor: År 2029 måste certifikat bytas ut ungefär var 47:e dag medan domänkontroll måste bekräftas ungefär var 10:e dag, så att automatisera det ena utan det andra lämnar fortfarande ett gap.
• Privat PKI omfattas inte av CA/Browser Forum-reglerna: Interna certifikat för VPN, enheter och interna tjänster kan ha längre livslängder, även om kortare interna livslängder fortfarande är god praxis.
• Postkvantplanering bör börja nu: NIST:s utkast till tidslinje för IR 8547 pekar på att RSA och ECDSA avvecklas efter 2030 och förbjuds efter 2035, och en kryptografisk inventering är en förutsättning för den migreringen.
• Ägarskap måste vara tydligt: Beslutschecklistan och åtgärdsmatrisen senare i den här artikeln tilldelar specifika ansvarsområden till PKI-, säkerhets-, plattforms- och efterlevnadsteam.

Hur korta blir TLS-certifikat, och när

Tidsplanen fastställdes av Ballot SC-081v3 , som CA/Browser Forum godkände den 11 april 2025, och som Sectigo (ballotens sponsor) bekräftade offentligt den 14 april 2025. Den definierar en stegvis minskning av både den maximala giltigheten för offentligt betrodda TLS-certifikat och den period under vilken domänkontrollvalideringsdata (DCV) kan återanvändas. Den första fasen har redan trätt i kraft: sedan den 15 mars 2026 utfärdar ingen offentligt betrodd certifikatutfärdare ett TLS-certifikat som är giltigt i mer än 200 dagar. Certifikat som utfärdats före det datumet under den maximala tiden på 398 dagar förblir giltiga under sin ursprungliga period; 200-dagarstaket gäller endast för certifikat som utfärdats den 15 mars 2026 eller senare.

Giltigt datum	Maximal giltighetstid för TLS-certifikat	Maximal återanvändningsperiod för DCV
Fram till 14 mars 2026	398 DAYS	398 DAYS
Från 15 mars 2026	200 DAYS	200 DAYS
Från 15 mars 2027	100 DAYS	100 DAYS
Från 15 mars 2029	47 DAYS	10 DAYS

Två detaljer är viktigast för planeringen. För det första löper certifikatgiltighet och återanvändning av DCV enligt separata tidslinjer. År 2029 kommer ett certifikat att behöva bytas ut ungefär var 47:e dag, medan domänägande måste omvalideras ungefär var tionde dag, så att automatisera förnyelse ensamt kommer inte att räcka om domänvalideringen fortfarande är beroende av en person. För det andra utfärdar vissa certifikatutfärdare något under varje tak för att undvika kantfall vid gränsen, så bygg förnyelsekadenser med en bekväm buffert istället för att sikta på gränsen.

En punkt blir ofta feltolkad. Schemat gäller endast certifikat som autentiserar servrar som är nåbara på det publika internet. Certifikat som utfärdats från en organisations egen privata PKI , som används för interna tjänster, enhetsautentisering, VPN-åtkomst och liknande fall, regleras inte av dessa CA/Browser Forum-regler. Interna certifikat kan ha längre livslängder där det är vettigt, även om kortare privata livslängder fortfarande är en sund säkerhetspraxis. Att förstå denna gräns hjälper team att avgränsa arbetet korrekt istället för att antingen överkonstruera interna PKI eller förbise delar av den publika tillgången.

Sju bästa praxis för certifikathantering

1. Upprätta kontinuerlig certifikatidentifiering i alla miljöer

Effektiv certifikathantering börjar med insyn. En organisation kan inte säkra eller förnya ett certifikat som den inte vet existerar, och inventeringar är ofta ofullständiga eftersom modern infrastruktur är dynamisk: certifikat skapas, driftsätts, ersätts och tas bort på molnplattformar, containrar, API:er, utvecklingsmiljöer och tredjepartstjänster enligt sina egna scheman.

Många team förlitar sig fortfarande på regelbundna granskningar eller ett manuellt underhållet kalkylblad. Dessa metoder fungerade även när certifikattillgångarna var små och förändrades långsamt. I molnbaserade miljöer, där resursförsörjningen skedde automatiskt och kortlivade arbetsbelastningar kan existera i minuter, är ett kalkylblad föråldrat i samma ögonblick som det sparas.

Kontinuerlig certifikatidentifiering ger en organisation en live-inventering av varje certifikat i sin miljö. Utöver att bara lokalisera certifikat bör identifieringen fånga upp utgångsdatum, utfärdande myndigheter, distributionsplatser, certifikattyper, ägarskap och kryptografiska detaljer som nyckelstorlek och signaturalgoritm. Det är dessa metadata som låter säkerhetsteam identifiera risker, tilldela ansvar och förbereda förnyelser långt före utgångsdatumet, snarare än att reagera när något redan har gått sönder.

Allt eftersom giltighetstiderna krymper är en korrekt, kontinuerligt uppdaterad inventering skillnaden mellan en planerad förnyelse och ett oplanerat avbrott.

2. Implementera enhetlig styrning under hela certifikatets livscykel

Synlighet ensamt garanterar inte kontroll. Organisationer behöver också styrningspolicyer som definierar hur certifikat begärs, godkänns, utfärdas, förnyas och återkallas.

Utan centraliserad styrning är certifikatspridning nästan oundviklig. Olika team förvärvar och hanterar certifikat på egen hand, processer glider isär och skugg-PKI-certifikat dyker upp utanför säkerhetssynpunkt. Med tiden blir ägarskapet oklart och policytillämpningen fragmenteras i hela organisationen.

Ett moget styrningsramverk sätter konsekventa standarder för varje certifikatoperation: vem kan begära certifikat, vilka godkännandeflöden som gäller, hur förfrågningar valideras och vilka kryptografiska krav som måste uppfyllas före driftsättning. Styrning bör också integrera rollbaserade åtkomstkontroller kopplade till företagsidentitetssystem, så att endast behörig personal kan utföra certifikatrelaterade åtgärder från första början.

En omfattande revisionslogg är lika viktig. Varje utfärdande, förnyelse, ändring och återkallelse bör loggas automatiskt för att stödja efterlevnadsgranskningar och säkerhetsutredningar. Centraliserad styrning minskar operativa risker och håller certifikatpraxis i linje med säkerhetspolicy och lagstadgade skyldigheter.

Encryption Consultings CertSecure Manager är byggd kring samma tre pelare som den här artikeln beskriver. Den utför nätverks-, moln- och slutpunktsidentifiering för att upprätthålla en aktiv inventering, tillämpar policyer för begäran och godkännande med rollbaserad åtkomst och granskningsloggning, och automatiserar utfärdande, förnyelse och provisionering mellan flera certifikatutfärdare med hjälp av protokoll som ACME.

3. Automatisera certifikatförnyelse och livscykeloperationer

Kortare giltighetsperioder har förändrat ekonomin för certifikathantering. En uppgift som tidigare skedde en gång om året kommer snart att återkomma flera gånger om året för varje enskilt certifikat.

För organisationer som hanterar hundratals eller tusentals certifikat är manuell förnyelse helt enkelt inte skalbar. Även kompetenta team kämpar med att spåra utgångsdatum, koordinera förnyelser, säkra godkännanden och distribuera uppdaterade certifikat i tid. Ett enda webbcertifikat som en administratör förnyar manuellt är en mindre uppgift med en årlig kadens; med en sexveckors kadens blir samma uppgift en återkommande felkälla för hela förvaltningen.

Certifikatautomatisering är nu ett krav snarare än en bekvämlighet. Livscykelhanteringsplattformar integreras direkt med certifikatutfärdare och stöder protokoll som ACME, vilket gör att certifikat kan begäras, förnyas, driftsättas och roteras utan manuella åtgärder. Policydrivna arbetsflöden ersätter helt påminnelsemejl och manuella ärenden.

Fördelarna sträcker sig bortom sparad tid. Automatisering säkerställer att certifikat ersätts konsekvent och i tid, minskar risken för avbrott och låter certifikatverksamheten skalas upp utan en proportionell ökning av antalet anställda. När livslängden minskar mot 47 dagar blir automatisering det avgörande kännetecknet för ett fungerande program, eftersom manuell förnyelse med några veckors mellanrum inte är hållbar i företagsskala.

4. Lös problemet med domänvalidering, inte bara förnyelse

Automatiserad förnyelse täcker bara hälften av vad 47-dagars TLS-certifikat kommer att kräva. Den krympande återanvändningsperioden för DCV innebär att domänägande måste bevisas mycket oftare, ungefär var tionde dag år 2029.

Det är här som jokertecken- och multidomäncertifikat skapar friktion. Automatiserad utfärdande med ACME validerar kontroll per domän, och jokerteckencertifikat kräver generellt DNS-baserad validering med programmatisk åtkomst till DNS-leverantören. Ett multidomäncertifikat koncentrerar också risken, eftersom en validerings- eller återkallningshändelse kan påverka alla namn på certifikatet. Team som förlitar sig starkt på jokertecken för att minska antalet certifikat kan upptäcka att valet motarbetar dem när valideringsfrekvensen ökar.

Den praktiska lösningen är att automatisera domänvalideringen, vanligtvis genom DNS-integration eller ett ACME-arbetsflöde som omvaliderar utan att en människa är inblandad. Reservera jokertecken för fall där de verkligen hjälper, till exempel edge-proxyservrar, och föredra dedikerade certifikat där automatisering per domän är enklare att köra.

Att bygga dessa arbetsflöden nu, medan kadensen fortfarande är 200 dagar, undviker problem när fönstret krymper ytterligare.

5. Stärk övervakning och riskbaserad prioritering

Stark identifiering och automatisering kräver fortfarande kontinuerlig övervakning. Team behöver realtidsinsyn i certifikatens hälsa och riskexponering så att problem upptäcks innan de når produktion.

Övervakning bör visa utgångsstatus, distributionshälsa, kryptografisk styrka, valideringsstatus och ägarskap. Tillsammans gör dessa signaler att problem kan åtgärdas innan de påverkar kritiska tjänster snarare än efteråt.

I takt med att fastigheterna växer övergår många organisationer till en riskbaserad strategi istället för att behandla alla certifikat likadant. Åtgärder prioriteras utifrån affärspåverkan, internetexponering, applikationskritikalitet och efterlevnadsrelevans. Ett certifikat som skyddar en kundorienterad betaltjänst kräver större uppmärksamhet än ett i en intern utvecklingsmiljö.

Övervakningsstrategin bör också återspegla kortare livslängder. Tröskelvärden som är kalibrerade för årliga förnyelser ger inte tillräckligt med svarstid när certifikaten löper ut med några månaders mellanrum, så varningar måste utlösas tidigare och skickas till en tydligt ansvarig ägare.

6. Börja förbereda dig för postkvantkryptografi

Vid sidan av kortare livslängder måste organisationer förbereda sig för en omvandling som kommer att omforma PKI: övergången till postkvantkryptografi.

Framsteg inom kvantberäkning hotar de publika nyckelalgoritmer som ligger till grund för dagens PKI och digitala certifikat, inklusive RSA och ECC . Storskaliga kvantattacker är ännu inte praktiska, men planeringshorisonten börjar redan ta form. NIST:s utkast till övergångsplan, NIST IR 8547 , fortfarande ett initialt offentligt utkast vid lanseringen i november 2024, föreslår att kvantumsårbara algoritmer som RSA och ECDSA ska föråldras efter 2030 och förbjudas efter 2035.

Dessa datum är bindande för de federala systemen inom IR 8547:s tillämpningsområde, men rapporten har blivit den referenspunkt som industrin använder för att planera sin egen PQC-migrering . Enligt definitionen i NIST SP 800-131A innebär föråldrad att en algoritm fortfarande kan användas, men dess användning medför en viss säkerhetsrisk som dataägaren måste bedöma och acceptera, medan otillåten innebär att den inte längre får användas för det angivna syftet alls.

Insamlingen "Skörde-nu-dekryptera-senare", där krypterad data samlas in idag för dekryptering när kvanthårdvaran mognar, gör denna tidslinje relevant för långlivad data nu, inte senare.

Förberedelserna börjar med att förstå kryptografiska beroenden. Organisationer bör inventera de algoritmer som används, identifiera affärskritiska system som är beroende av dem och bedöma om deras certifikatutfärdare, applikationer och verktyg är redo att stödja de kvantresistenta standarder som NIST slutförde den 13 augusti 2024:

• ML-KEM för nyckelinkapsling, standardiserad från CRYSTALS-Kyber-inlämningen (FIPS 203).
• ML-DSA för digitala signaturer, standardiserad från CRYSTALS-Dilithium-inlämningen (FIPS 204).
• SLH-DSA, ett statslöst hashbaserat signaturalternativ standardiserat från SPHINCS+-inlämningen (FIPS 205).

Dessa är slutgiltiga standarder, till skillnad från tidslinjen för övergången till IR 8547, som fortfarande är i utkast. En kryptografisk inventering är en förutsättning för allt detta, eftersom en algoritm som ingen kan se är en algoritm som ingen kan migrera. Att bygga upp den inventeringen är vad Encryption Consulting kallar en kryptografisk materiallista (CBOM) , och disciplinen att uppdatera den när systemen förändras är en form av kryptoagilitet som lönar sig långt bortom den initiala PQC-övergången.

Själva övergången förväntas ske gradvis genom hybridimplementeringar som kombinerar klassiska och kvantresistenta algoritmer, vilket gör algoritmagilitet och storskalig testning avgörande. Organisationer i reglerade eller nationella säkerhetssammanhang bör också följa NSA:s CNSA 2.0-riktlinjer, som anger tidigare implementeringsförväntningar än den civila tidslinjen för IR 8547 och specificerar parameteruppsättningar som ML-KEM-1024 och ML-DSA-87.

Enligt CNSA 2.0 måste nya nationella säkerhetssystem stödja kvantresistenta algoritmer från och med januari 2027, med kategorispecifika deadlines för exklusiv användning som sträcker sig från 2030 till 2033 och en fullständig migrering förväntas ske senast 2035. Team som vill ha en strukturerad utgångspunkt kan granska Encryption Consultings PQC- beredskapsvägledning och CBOM:s inventering-till-underrättelsemetod för att omvandla en rå kryptografisk inventering till en prioriterad migreringsplan. Samma discipliner som gör kortlivade certifikat hanterbara, en komplett inventering, automatiserad distribution och policytillämpning, är exakt de discipliner som en PQC-migrering kräver.

7. Integrera certifikathantering med moln- och DevOps-ekosystem

Modern infrastruktur är byggd för hastighet. Applikationer skickas via CI/CD -pipelines, containrar skapas och förstörs dynamiskt och molnresurser skalas på begäran. Certifikathantering måste fungera inom dessa arbetsflöden snarare än att placeras bredvid dem som en separat process.

Integration med moln- och DevOps-plattformar gör att certifikat blir en del av automatiserad provisionering. Oavsett om resurser distribueras via Kubernetes , Terraform, molnbaserade tjänster eller andra infrastruktur-som-kod-ramverk, bör certifikatutfärdande och förnyelse ske automatiskt när tjänsterna kommer online. Integration med molnnyckellager och verktyg som cert-manager håller detta konsekvent över olika miljöer istället för ad hoc per team.

Utan den integrationen uppstår blinda fläckar där certifikat finns utanför centraliserad hantering. Dessa ohanterade certifikat ökar säkerhetsrisken, komplicerar efterlevnadsrapportering och ökar risken för oväntade avbrott.

Att integrera certifikathantering i moln- och DevOps-arbetsflöden förbättrar synligheten, ökar den operativa effektiviteten och håller certifikaten i linje med en infrastruktur som ständigt förändras.

Vanliga misstag som leder till certifikatavbrott

Trots ökad medvetenhet är avbrott orsakade av utgångna eller felaktigt hanterade certifikat fortfarande vanliga inom olika branscher. DigiCerts undersökning från juli 2025 visade att manuella påminnelser om förnyelse, ofullständiga lager och oklara ägarförhållanden fortfarande är normen hos nästan hälften av de organisationer som undersöktes.

Andra återkommande misstag inkluderar att inte planera för kortare giltighetsperioder, att förbise certifikat i molnmiljöer, att använda självsignerade certifikat i produktion och att försena förnyelser tills certifikaten närmar sig utgångsdatumet. Dessa problem ser ofta små ut tills de orsakar ett avbrott i tjänsten, ett kundvänt avbrott eller ett efterlevnadsfall.

Konsekvenserna är väl dokumenterade. I juli 2024 rapporterade Bank of England ett 91 minuter långt avbrott i CHAPS-avvecklingen orsakat av ett utgånget certifikat inom dess infrastruktur, vilket påverkade ett system som avvecklar betalningar med högt belopp i pund sterling. Risken är inte begränsad till tillgänglighet.

I Equifax-intrånget 2017 hade en nätverksövervakningsenhet varit inaktiv i cirka 19 månader på grund av ett utgånget certifikat, vilket lät inkräktare arbeta oupptäckta i 76 dagar och stjäla data om ungefär 147 miljoner människor, en incident som senare ledde till en förlikning på upp till 700 miljoner dollar. Att förhindra sådana här händelser kräver samma grund av insyn, styrning och automatisering som beskrivs i hela den här artikeln.

Bästa säkerhetsmetoder för långsiktig framgång

Stark certifikathantering sträcker sig bortom förnyelse. Organisationer bör skydda privata nycklar med hjälp av hårdvarusäkerhetsmoduler , tillämpa åtkomstkontroller med lägsta behörighet, genomföra regelbundna granskningar och kontinuerligt söka efter ohanterade certifikat i hela miljön. För användningsfall med hög säkerhet, leta efter HSM:er som är validerade enligt FIPS 140-3 , med valideringsnivån matchad med känsligheten hos de nycklar som skyddas.

Tydliga policyer för utvecklings- och testmiljöer hjälper till att förhindra återanvändning av produktionsnycklar och eliminera onödiga risker. Där offentliga certifikat har använts på nytt för intern autentisering är det vanligtvis det bättre långsiktiga valet att ersätta dem med certifikat från en hanterad privat PKI.

Dessa metoder minskar sannolikheten för att certifikatet komprometteras samtidigt som de stöder efterlevnad och operativ motståndskraft.

Beslutshantering och ägarmatris för certifikat

De sju metoderna ovan kan tolkas olika beroende på vilken typ av certifikat det gäller och vilket team som är närmast det. De två tabellerna nedan ger en snabb referens: en för att bestämma hur en given certifikatklass ska behandlas och en för att tilldela ägarskap mellan PKI-, säkerhets-, plattforms- och efterlevnadsteam.

Beslutschecklista per användningsfall

Användningsfall	Rekommendation	Operativ ägare	Förväntat resultat
TLS-certifikat för allmänheten	Automatisera utfärdande och förnyelse via ACME mot 200/100/47-dagarsschemat	Plattform / DevOps	Inga manuella förnyelsekontaktpunkter; inga avbrott på grund av utgångsdatum
Wildcard- eller multidomäncertifikat	Automatisera DNS-baserad DCV; begränsa användningen av jokertecken till edge-proxyservrar	PKI-teamet	Domänåtervalidering håller jämna steg med krympande återanvändningsfönster för DCV
Interna eller privata PKI-certifikat	Ställ in interna livslängder medvetet; anta inte att begränsningar för CA/Browser Forum gäller	PKI-teamet	Rätt storlek på validitet för intern risk, utan onödig kundbortfall
Äldre eller agentlösa system	Implementera lättviktiga agenter eller proxybaserad automatisering istället för manuell förnyelse	Plattform / Säkerhet	Äldre system fortsätter att använda samma automatiserade kadens som moderna
Kryptografisk algoritminventering	Bygg och underhåll en CBOM som täcker alla certifikatberoende system	Säkerhet / Efterlevnad	Migreringsklar synlighet inför övergången efter kvantumsgränsen

Ägare och åtgärdsmatris per team

Team	Huvudansvar	Vad göra här näst
PKI-teamet	Policy för certifikatutgivning, noggrannhet i identifiering, jokertecken och domänstrategi	Bekräfta att varje offentlig certifikatutfärdarsökväg stöder ACME; dokumentera vilka domäner som fortfarande är beroende av jokerteckenscertifikat och planera deras minskning
Säkerhetsteam	Riskprioritering, nyckelskydd, kryptografiskt inventering	Ställ upp eller granska CBOM; flagga affärskritiska system som fortfarande finns på RSA eller ECC för PQC-färdplanen
Plattform-/DevOps-teamet	CI/CD och infrastrukturintegration, automatiserad driftsättning	Skicka certifikatutfärdande till Kubernetes, Terraform eller befintliga infrastruktur-som-kod-pipelines istället för att hantera det som en sidouppgift
Compliance-teamet	Revisionslogg, regelanpassning, undantagsspårning	Bekräfta att revisionsloggningen registrerar varje utfärdande, förnyelse och återkallelse, och uppdatera interna policydokument för att återspegla giltighetsschemat för 2026 till 2029.

Hur krypteringskonsulting kan hjälpa

De sju metoderna i den här artikeln syftar till en enda verksamhetsmodell byggd på identifiering, styrning och automatisering. Encryption Consulting levererar den modellen genom en kombination av plattformskapacitet och rådgivande expertis, så att organisationer kan gå från fragmenterade, manuella processer till ett hanterat program innan kortare giltighetsperioder får full effekt.

CertSecure Manager är plattformen för hantering av certifikatlivscykeln som utför kontinuerlig identifiering över nätverksslutpunkter, molnplattformar och lokala certifikatarkiv för att upprätthålla en aktiv inventering, registrera utgångsdatum, utfärdande myndigheter, nyckelstorlekar och signaturalgoritmer för varje certifikat som hittas. Detta minskar den synlighetsbrist som gör både automatisering av förnyelser och post-kvantumplanering omöjlig utan den.

På styrningssidan upprätthåller CertSecure Manager policyn vid begäran. Den definierar vilka auktoriteter och certifikatprofiler som är tillåtna för varje användningsfall, tillämpar rollbaserade åtkomstkontroller kopplade till företagsidentitet, dirigerar begäranden genom godkännandearbetsflöden och registrerar varje utfärdande, förnyelse och återkallelse i en manipulationssäker revisionslogg. Icke-kompatibla begäranden blockeras snarare än korrigeras i efterhand, vilket förhindrar att skugg-PKI bildas från första början.

För automatisering integreras plattformen direkt med flera certifikatutfärdare och stöder protokoll som ACME, så utfärdande, förnyelse, provisionering och återkallelse kan ske utan manuella steg. Den ansluter till molnnyckellager och DevOps-verktyg, vilket gör att certifikat kan distribueras som en del av normal provisionering snarare än som en separat uppgift. Lättviktsagenter utökar samma automatisering till äldre system som inte använder moderna protokoll, vilket är det som gör en 47-dagars förnyelsekadens operativt realistisk snarare än ambitiös.

Privat PKI körs enligt dina egna regler snarare än CA/Browser Forum-schemat, men det behöver fortfarande struktur. EC:s PKI-as-a-Service tillhandahåller en hanterad privat förtroendehierarki för interna tjänster, enhets- och användarautentisering och arbetsbelastningsidentitet, medan HSM-as-a-Service skyddar de underliggande privata nycklarna i dedikerad hårdvara. Tillsammans ger de samma disciplin till interna certifikat som den här artikeln rekommenderar för publika certifikat.

För den längre övergången bygger CBOM Secure en kryptografisk materiallista som registrerar vilka algoritmer som används i hela databasen, och den synlighet på algoritmnivå som eventuell post-kvantmigrering är beroende av. Därifrån översätter EC:s PQC Advisory Services och PQC Center of Excellence den inventeringen till en fasad migreringsplan, inklusive var hybrid klassiska och kvantresistenta implementeringar är lämpliga under övergången.

För organisationer som är osäkra på var de står idag kan EC:s krypteringsrådgivningstjänster bedöma certifikattillgångarna, kvantifiera den operativa effekten av kortare livslängder och definiera en färdplan mot identifiering, styrning och automatisering, så att programmet skalas upp med förnyelsecykler istället för att reagera på varje ny deadline under press.

Slutsats

Certifikathanteringslandskapet förändras snabbt. Med en giltighetstid för offentligt betrodda TLS redan begränsad till 200 dagar och fortsatt att sjunka mot 47 dagar år 2029, skyddar inte längre manuella processer och fragmenterad insyn en organisation, och data stöder detta: nästan hälften av de företag som undersöktes av DigiCert i mitten av 2025 hade redan upplevt certifikatrelaterade driftstopp.

Framgång beror nu på en strategi som bygger på kontinuerlig identifiering , stark styrning och omfattande automatisering, med domänvalidering automatiserad i samband med förnyelse snarare än att lämnas i efterhand. Organisationer som lägger dessa grunder på plats kommer att vara redo för mer frekventa förnyelser, undvika kostsamma avbrott och vara positionerade för den längre övergången till post-kvantkryptografi.

Övergången till kortlivade certifikat är redan igång. Ett praktiskt första steg är att bygga en komplett, kontinuerligt uppdaterad inventering av varje certifikat du innehar, och sedan använda den insynen för att prioritera automatisering där förnyelsefrekvensen och affärspåverkan är störst. För att bedöma var ditt certifikatprogram står idag och vilka kortare livslängder som kommer att krävas, kontakta teamet på Encryption Consulting.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från Bästa praxis för certifikathantering: 7 steg för 2026?

Certifikathantering vilar nu på tre pelare som arbetar tillsammans: kontinuerlig identifiering för att veta vilka certifikat som finns, centraliserad styrning för att kontrollera hur de utfärdas och godkänns, och automatisering för att hantera förnyelser i en takt som manuella processer inte kan matcha. I takt med att giltigheten för offentliga TLS minskar från 200 dagar till 47 dagar år 2029, riskerar man att behandla en pelare som valfri, vilket innebär att de andra två är i fara.

Varför är detta viktigt för hanteringen av företagscertifikats livscykel?

Kortare giltighetsperioder multiplicerar hur ofta varje certifikat i ett certifikatsystem behöver förnyas och omvalideras. En organisation som hanterar tusentals certifikat i en 47-dagarscykel istället för en årlig certifikatcykel kör en fundamentalt annorlunda verksamhet, och program som byggts för den gamla kadensen kommer att hamna på efterkälken utan förändringar i verktyg och processer.

Vilka team ansvarar för att agera utifrån denna vägledning?

PKI-, säkerhets-, plattforms- eller DevOps- och compliance-team äger var och en en del av detta. PKI-team hanterar utgivningspolicy och domänstrategi, säkerhetsteamen äger riskprioritering och kryptografisk inventering, plattformsteamen integrerar certifikat i CI/CD- och infrastrukturpipelines, och compliance-teamen upprätthåller revisionsspårningen och regelanpassningen. Ägarmatrisen tidigare i den här artikeln bryter ner specifika nästa steg för varje grupp.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell förnyelse ökar risken för missade utgångsdatum, inkonsekventa godkännanden och skugg-PKI-certifikat som inte får centraliserad synlighet. DigiCerts undersökning från juli 2025 visade att 45 % av organisationerna upplevde certifikatrelaterade driftstopp under föregående år, varav 37.5 % av incidenterna var specifikt kopplade till ett utgånget certifikat, och ungefär en tredjedel av de drabbade organisationerna rapporterade ekonomiska förluster på 50 000 dollar eller mer.

Hur minskar automatisering risken för certifikatavbrott?

Automatisering ersätter manuell spårning och påminnelsedriven förnyelse med policydrivna arbetsflöden som begär, förnyar, distribuerar och roterar certifikat enligt schema med hjälp av protokoll som ACME. Den konsekvensen eliminerar de mänskliga fel som orsakar de flesta utgångsrelaterade avbrott, och det gör att certifikatverksamheten kan skalas upp utan att öka personalstyrkan allt eftersom giltighetstiderna krymper.

Vilka mätvärden bör teamen följa efter implementeringen?

Spåra certifikatinventeringens fullständighet (procentandel certifikat under aktiv förvaltning), tid till förnyelse kontra dagar kvar innan utgång, antalet certifikat som förnyats manuellt kontra automatiskt, lyckad validering av domänkontroll och fullständighet i revisionsloggen för varje utfärdande-, förnyelse- och återkallelseshändelse.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

200-dagarsgränsen som har varit i kraft sedan mars 2026 är det första av tre steg mot den maximala gränsen på 47 dagar som träder i kraft i mars 2029, med ett mellanliggande steg på 100 dagar i mars 2027. Varje metod i den här artikeln, från identifiering till automatisering av domänomvalidering, är en grund för att bekvämt arbeta med den slutliga kadensen snarare än att kämpa för att uppnå den år 2029.

Hur ska detta hanteras i multimoln- eller hybrid-PKI-miljöer?

Multimoln- och hybridmiljöer behöver identifiering och automatisering som fungerar identiskt på varje plattform snarare än en separat process per molnleverantör. Det innebär att integrera certifikatutfärdande med varje leverantörs inbyggda verktyg och med orkestreringslager som Kubernetes och Terraform, samtidigt som man bibehåller en centraliserad inventering och en styrningspolicy så att certifikat som utfärdas i olika moln inte glider in i inkonsekventa standarder.