47-dagars TLS-certifikat

Snabbt svar: CA/Browser Forums omröstning SC-081v3 minskar den maximala livslängden för publika TLS-certifikat från 398 dagar till 47 dagar i mars 2029, fasat upp till 200 dagar under 2026 och 100 dagar under 2027, och återanvändning av domänvalidering minskar till 10 dagar. Manuell förnyelse kan inte hålla jämna steg, vilket gör automatiserad hantering av certifikatlivscykeln avgörande för PKI-, säkerhets-, plattforms- och compliance-team.

TLS-certifikat (Transport Layer Security), fortfarande allmänt kallade SSL-certifikat efter sitt föregångarprotokoll, är de digitala autentiseringsuppgifter som säkrar anslutningen mellan en webbläsare och en webbplats. De krypterar trafik, verifierar att en webbplats är den den utger sig för att vara och utlöser hänglåsikonen som webbläsare visar för en korrekt säker anslutning. Om certifikathanteringen gör fel försvinner hänglåset, tillsammans med kundernas förtroende.

Den grunden kommer snart att testas under en mycket snävare tidsram. CA/Browser Forum, branschorganisationen för certifikatutfärdare och webbläsarleverantörer som sätter reglerna för allmänhetens förtroende på webben, har godkänt en gradvis minskning av den maximala livslängden för certifikat som upphör vid 47 dagar i mars 2029. Ändringen, som stöds enhälligt av Apple, Google, Mozilla och Microsoft, komprimerar också hur länge en slutförd domänvalidering kan återanvändas, vilket stramar åt hela certifikatutfärdande- och förnyelsecykeln. För organisationer som fortfarande förlitar sig på kalkylblad och manuella förnyelsekalendrar är detta den tidsfrist som förvandlar certifikathantering från en tillfällig syssla till en kontinuerlig operativ disciplin.

Key Takeaways

• CA/Browser Forums omröstning SC-081v3, godkänd den 11 april 2025, minskar den maximala giltighetstiden för offentliga TLS-certifikat från 398 dagar till 47 dagar senast den 15 mars 2029, i tre faser: 200 dagar (mars 2026), 100 dagar (mars 2027) och 47 dagar (mars 2029).
• Återanvändning av domänkontrollvalidering (DCV) krymper parallellt, från 398 dagar ner till 10 dagar år 2029, så domänägande måste verifieras på nytt mycket oftare.
• En undersökning från DigiCert Trust Pulse (2 juli 2025) visade att 45 % av företagen upplevde certifikatrelaterade driftstopp under det senaste året, och 37.5 % av dessa avbrott kunde spåras till utgångna certifikat.
• Manuell certifikatspårning kan inte upprätthålla 47-dagars förnyelsecykler på företagsnivå; automatisering via ACME och en plattform för certifikatlivscykelhantering (CLM) blir ett krav, inte ett alternativ.
• PKI-, säkerhets-, plattforms-, DevOps- och compliance-team har alla sina egna åtgärdspunkter inför deadlines i mars 2026 och 2027, vilka beskrivs i effektmatrisen senare i den här artikeln.
• Tidigare förslag, inklusive Googles förslag från 2023 om 90-dagarscertifikat, blev inte den antagna standarden. Det nuvarande, bindande kravet är 47-dagarsschemat enligt Ballot SC-081v3.

Officiell policytidlinje för 47-dagars TLS-certifikat

Varje deadline nedan kommer från en enda, bindande källa: CA/Browser Forum Ballot SC-081v3, godkänd den 11 april 2025 med 29 röster för och ingen emot. Tabellen listar ikraftträdandedatum, det krav som träder i kraft, vem det påverkar, vilken åtgärd som ska vidtas och den officiella källan för verifiering.

Giltig datum	Krav	Vilka påverkas	Åtgärd behövs	Källa
Mars 15, 2026	Maximal giltighetstid: 200 dagar Återanvändning av DCV: 200 dagar	Alla offentligt betrodda TLS-certifikat (DV, OV, EV)	Flytta certifikatspårning från kalkylblad; pilotprojekt för ACME-baserad utfärdande	Omröstning för CA/Webbläsarforum SC-081v3
Mars 15, 2027	Maximal giltighetstid: 100 dagar Återanvändning av DCV: 100 dagar	Alla offentligt betrodda TLS-certifikat	Automatisera förnyelse för alla internetanslutna certifikat; utöka identifieringen till interna och molnutfärdade certifikat	Omröstning för CA/Webbläsarforum SC-081v3
Mars 15, 2029	Maximal giltighetstid: 47 dagar Återanvändning av DCV: 10 dagar	Alla offentligt betrodda TLS-certifikat	Fullständig CLM-automatisering med permanent eller skriptad DCV på plats; manuell förnyelse är inte längre genomförbar	Omröstning för CA/Webbläsarforum SC-081v3

Policykällor: DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 % av organisationerna rapporterade certifikatrelaterad driftstopp och 37.5 % kopplade avbrott till utgångna certifikat. Fullständig rapport: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations . CA/Browser Forum Ballot SC-081v3, tillkännagav via Sectigo (14 april 2025), bekräftar det etappvisa schemat till 200 dagar (mars 2026), 100 dagar (mars 2027) och 47 dagar (mars 2029). Fullständigt tillkännagivande: sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days.

Hur certifikatens livslängd blev kortare

Siffran 47 dagar är inte ett plötsligt hopp. Maximal giltighetstid för certifikat har haft en nedåtgående trend i över ett decennium:

• 2011: Certifikat var giltiga i upp till 8 till 10 år, och prioriterade bekvämlighet framför kryptografisk flexibilitet.
• 2015: Minskad till 3 år eftersom branschen insåg säkerhetskostnaden för nycklar med lång livslängd.
• 2018: Reducerad till 2 år, drivet av snabbare framsteg inom kryptanalys och tryck från CA/Browser Forum.
• 2020: Reducerades till 398 dagar (cirka 13 månader) i september, det tak som gällde fram till 2026-fasen av SC-081v3.
• 2025 till 2029: Valsedeln SC-081v3 har en giltighetstid ner till 200 dagar, sedan 100 dagar och sedan 47 dagar, det schema som den här artikeln täcker.

Vad som förändras och varför det är viktigt

Övergången från 398-dagars till 47-dagars certifikat skedde inte i ett steg, och det landade inte där branschen först förväntade sig. År 2023 föreslog Google att livslängden för TLS-certifikat skulle minskas från 398 dagar till 90 dagar, och Apple drev vidare med ett förslag på 47 dagar. Efter ungefär två års diskussioner i CA/Browser Forum och en formell omröstning bestämde sig branschen för Apples siffra på 47 dagar, levererad genom det etappvisa SC-081v3-schemat. Om en källa fortfarande räknar med 90 dagar som den kommande standarden, ska det betraktas som föråldrat: det godkända, bindande kravet är 47 dagar senast i mars 2029, uppnått genom de mellanliggande stegen på 200 dagar och 100 dagar som tas upp ovan.

Organisationer som fortfarande kör föråldrade protokoll som TLS 1.0 eller TLS 1.1, eller förlitar sig på svaga krypteringssviter som RC4 eller SHA-1, står inför en svårare övergång. Dessa protokoll och algoritmer är sårbara för attacker som POODLE och BEAST, och de flesta nuvarande webbläsare och certifikatutfärdare stöder dem inte längre. Kortare certifikatlivslängder och strängare valideringspolicyer gör TLS 1.2 (helst TLS 1.3) och moderna krypteringssviter som AES-GCM och Elliptic Curve Cryptography (ECC) till ett praktiskt krav snarare än en bästa praxis: AES-GCM lägger till autentiserad kryptering som hjälper till att förhindra datamanipulation, och ECC ger stark säkerhet med kortare, snabbare nycklar.

Argumenten för kortare livslängder

Kortare giltighetsperioder är ett direkt och enkelt sätt att höja en organisations säkerhetsbaslinje. Fördelarna visar sig inom fyra områden.

• Minskad attackyta: Ett komprometterat certifikat är bara användbart för en angripare under en kort tidsperiod. I april 2025 upptäckte SSL.com en brist i sin domänvalideringsprocess som ledde till felaktig utfärdande av 11 TLS-certifikat, vilka kunde ha stödt förfalskade webbplatser eller man-in-the-middle-attacker. Certifikaten återkallades inom 24 timmar, men incidenten visade hur snabbt ett valideringsgap kan förvandlas till exponering när certifikat lever i månader snarare än veckor.
• Snabbare kryptografisk uppdatering: Täta förnyelser skapar naturliga kontrollpunkter för att pensionera föråldrade algoritmer och rotera nycklar, vilket är ännu viktigare efter att Mozilla och Google började misstro Entrust-utfärdade certifikat år 2024. Kortare livslängder gör det enklare att byta certifikatutfärdare och minskar beroendet av ett enskilt långsiktigt förtroendeankare.
• Rengöringscertifikatinventering: Täta förnyelser visar på glömda eller föräldralösa certifikat som annars skulle ligga ohanterade i åratal. Cisco har rapporterat att tätare förnyelsecykler hjälpte deras team att identifiera och dra tillbaka föräldralösa certifikat som skapat onödiga risker.
• Starkare anpassning till molnet och DevOps: Tillfällig, molnbaserad infrastruktur behandlar redan autentiseringsuppgifter som kortlivade. Certifikatlivscykler som matchar det mönstret integreras smidigare med CI/CD-pipelines och minskar antalet inaktuella autentiseringsuppgifter som finns i en miljö.

De operativa riskerna

Inget av detta kommer gratis. Att komprimera förnyelsecyklerna med upp till åtta gånger per år multiplicerar den operativa belastningen på team som fortfarande hanterar certifikat manuellt.

• Exponentiell förnyelsevolym: Att gå från 398-dagars till 47-dagars certifikat innebär upp till åtta förnyelser per år istället för en. En organisation som hanterar 500 certifikat manuellt skulle behöva behandla ungefär 4 000 förnyelser årligen, vilket en arbetsbelastning som manuella processer realistiskt sett inte kan absorbera.
• Manuella processer misslyckas under belastning: Microsoft Teams drabbades av ett tre timmar långt avbrott 2019 när ett utgånget autentiseringscertifikat spärrade ut ungefär 20 miljoner användare. En kortare, noggrant övervakad förnyelsecykel i kombination med automatisering skulle sannolikt ha upptäckt utgången långt i förväg; utan automatisering blir samma gap bara farligare i takt med att förnyelsefrekvensen ökar.
• Avbrott blir mer sannolika utan automatisering: Enligt rapporten State of Machine Identity Management från 2022 upplevde cirka 81 % av organisationerna minst ett certifikatrelaterat avbrott det året. Google Voice drabbades av ett globalt avbrott 2021 kopplat till ett utgånget TLS-certifikat, och Cisco SD-WAN-enheter har slutat fungera ute på fältet när ett hårdvarucertifikat har upphört att gälla.
• Efterlevnadsexponeringen ökar: I Equifax-intrånget gick ett utgånget certifikat från en övervakningsenhet obemärkt förbi i 19 månader, under vilken tid företaget hade 324 utgångna SSL-certifikat, varav 79 på kritiska övervakningssystem. Kortare livslängder utan motsvarande synlighet mångdubblar antalet certifikat som kan löpa ut på just detta sätt.

Påverkan per team och datum

Tidslinjen för SC-081v3 berör mer än certifikatteamet. Här är vad som ändras för de fyra grupper som vanligtvis delar äganderätten till TLS-certifikat, och den första åtgärden var och en bör vidta.

Team	Vilka förändringar	Första åtgärden	Måldatum
PKI- och certifikatteamet	Förnyelsefrekvensen fördubblas ungefär 2026 och igen 2027, och ökar sedan kraftigt 2029.	Slutför en fullständig certifikatidentifiering och inventering i lokala, moln- och hybridmiljöer	Innan den 2026 mars
Säkerhetsteam	Kortare giltighetstid minskar utnyttjandefönstret för en komprometterad nyckel, men bara om återkallelse och övervakning hålls i takt	Bekräfta att OCSP-häftning och CRL-distribution är korrekt konfigurerade och aktivt övervakade	Innan den 2026 mars
Plattforms- och DevOps-teamet	CI/CD-pipelines, lastbalanserare och applikationskonfigurationer byggda kring långlivade certifikat måste stödja ACME-baserad förnyelse	Integrera ACME-klienter och DNS- eller HTTP-valideringsautomation i distributionspipelines	Innan den 2027 mars
Efterlevnadsteam	Revisionsbevis måste återspegla intyg som nu ändras betydligt oftare än en gång om året	Flytta rapporteringen av certifikatinventering till en kontinuerlig, automatiserad modell istället för en ögonblicksbild från en viss tidpunkt	Pågående, före mars 2027

47-dagars checklista för certifikatberedskap

• Inventera alla certifikat i lokala, moln- och hybridmiljöer, inklusive kortlivade och internt utfärdade certifikat.
• Identifiera alla system som fortfarande antar en certifikatlivscykel på 90 dagar, ett år eller längre.
• Implementera ACME eller ett motsvarande protokoll för automatiserad utfärdande och förnyelse.
• Konfigurera beständig eller automatiserad domänkontrollvalidering så att förnyelse inte är beroende av ett manuellt steg.
• Ställ in utgångsaviseringar i god tid före deadline, inte bara vid tidpunkten för misslyckandet.
• Tilldela en namngiven ägare för varje certifikat och varje automatiseringsarbetsflöde.
• Utvidga samma disciplin till interna PKI och privata certifikat. De är inte bundna av CA/Browser Forum-regler, men de medför samma operativa risk.

Automatisering: Den enda gångbara vägen framåt

Med förnyelser som sker med några veckors mellanrum istället för varje år, slutar manuell certifikathantering att vara enbart obekvämt och blir en belastning. CA/Browser Forums egen motivering för Ballot SC-081v3 behandlar automatisering som det grundläggande antagandet, inte en valfri uppgradering, och regelverk som HIPAA, DORA och PCI DSS lägger allt större vikt vid certifikathantering som en del av bredare krav på digitalt förtroende.

Organisationer som hanterar stora certifikatinventarier behöver fortfarande lösa flera problem innan automatiseringen fungerar smidigt från början till slut.

• Automatisk återkallelse: Att återkalla ett certifikat i realtid och säkerställa att alla beroende system återspeglar ändringen är svårare än det låter i stor skala.
• Snabb spridning: Återkallningsstatus måste nå OCSP-svarare och CRL:er snabbt, annars förblir inaktuella, sårbara certifikat betrodda längre än de borde.
• OCSP-häftning och CRL-hantering: Båda kräver noggrann konfiguration så att webbläsare och system får aktuell återkallningsinformation utan ökad latens.
• Beroendehantering: Certifikat har vanligtvis program- eller tjänsteberoenden som behöver samordnas vid förnyelse eller återkallelse.
• Revision och synlighet: Automatiserade åtgärder måste loggas och spåras för att stödja efterlevnadskrav och felsökning.
• Risk för driftstopp: Felaktigt konfigurerad automatisering kan orsaka exakt de avbrott den var avsedd att förhindra.

Om det görs på rätt sätt minskar automatisering risken för fel och driftstopp samtidigt som det förbättrar kostnadseffektiviteten och granskningsberedskapen. I takt med att förnyelsefrekvensen ökar mot deadline 2029, går automatisering från att vara en konkurrensfördel till att vara ett grundläggande krav för att förbli säker och efterleva regelverket.

Rekommenderade steg för att implementera automatisering

Dessa steg återspeglar den sekvens som organisationer har funnit mest tillförlitlig när de övergår till manuell certifikathantering.

1. Genomför en fullständig granskning av det nuvarande certifikatinventariet.
2. Identifiera varje plattform och system som kräver automatisering.
3. Välj en lösning för hantering av certifikatlivscykeln som täcker hela arbetsflödet för förnyelse och återkallelse.
4. Integrera CLM-plattformen med befintlig infrastruktur och DevOps-pipelines.
5. Definiera tydliga policyer för förnyelse, utfärdande och återkallelse.
6. Schemalägg regelbundna efterlevnadskontroller och rapportering.

Migreringsfärdplan för 47-dagars certifikatberedskap

Att bli redo för 47-dagarscertifikat är inte ett enskilt projekt. Det byggs upp i etapper, och varje steg utökas naturligt till det bredare arbetet med kryptoagilitet som de flesta PKI- och säkerhetsteam redan har på sin färdplan.

1. Upptäck och inventera: Kör certifikatidentifiering över lokal, moln- och hybridinfrastruktur innan du utvärderar något automatiseringsverktyg. En kryptografisk upptäckt och inventering plattformar som CBOM Secure avslöjar certifikat och kryptografiska tillgångar som manuell spårning vanligtvis missar.
2. Automatisera utfärdande och förnyelse: Flytta först internetbaserade certifikat till ACME-baserad utfärdande och förnyelse, eftersom dessa medför den mest omedelbara affärsrisken om de löper ut.
3. Utöka kryptoflexibiliteten bortom TLS: Certifikatautomatisering är en del av en större kryptoagilitetspraxis. Kombinera det med en levande inventering, som behandlas mer ingående i hur en kryptografisk stycklista förvandlar lager till information, så algoritm- och nyckeländringar kan rullas ut utan brandövning.
4. Bygg mot post-kvantumberedskap: Kortare TLS-livslängder och den kommande post-kvantumövergången delar samma underliggande krav: förmågan att ändra kryptografiskt material snabbt och säkert. Team som bygger upp den styrkan nu kan granska PQC-beredskap vägledning och PQC:s kompetenscentrum att utöka certifikatautomatisering till en bredare kvantsäker migreringsplan.

Hur Encryption Consultings CertSecure Manager kan hjälpa till

CertSecure Manager från Encryption Consulting är byggt för den operativa verkligheten med kortare certifikatlivslängder. I takt med att förnyelsecyklerna komprimeras till närmare 47 dagar, går automatisering från att vara en bra idé till den mekanism som hindrar certifikat från att bli en källa till avbrott.

Automatiserad certifikatupptäckt och inventering

CertSecure Manager upptäcker certifikat i lokala miljöer, molnmiljöer och hybridmiljöer, inklusive självsignerade certifikat som ofta inte hanteras. En centraliserad inventering gör det möjligt att se alla certifikat som ska förnyas långt innan 47-dagarsfristen skapar press.

Avancerad ACME-protokollintegration

Genom att stödja ACME-protokollet automatiserar CertSecure Manager utfärdande och förnyelse på ett standardiserat och säkert sätt, vilket eliminerar de manuella stegen som uppdelas när förnyelser sker med några veckors mellanrum istället för en gång om året.

Automatisk förnyelse, återutgivning och återkallelse

CertSecure Manager håller certifikaten uppdaterade automatiskt och återkallar komprometterade eller onödiga certifikat utan att behöva vänta på en manuell supportförfrågan. Det minskar både säkerhetsrisken för ett kvarvarande certifikat och den administrativa bördan av att spåra förnyelsedatum manuellt.

Efterlevnad och rapportering

CertSecure Manager kör automatiserade efterlevnadskontroller mot standarder som PCI DSS, GDPR och ISO, och genererar revisionsklara rapporter på begäran. Det förvandlar certifikatefterlevnad från en manuell, punktvis övning till något som ett efterlevnadsteam kan göra närhelst en revisor ber om det.

Integrations- och förnyelseagenter

CertSecure Manager integreras med verktyg som Terraform, Ansible och Azure Key Vault, och automatiserar certifikatprovisionering och distribution i CI/CD-pipelines över databaser och webbservrar inklusive Apache, IIS och NGINX. Förnyelseagenter skräddarsydda för varje tjänst håller certifikaten aktuella med minimal manuell intervention, vilket är precis den kapacitet som 47-dagarsschemat kräver i stor skala.

Slutsats

Övergången till 47-dagars TLS-certifikat är ett tydligt exempel på hur digitala förtroendestandarder utvecklas för att möta moderna hot. Kortare livslängder minskar avsevärt det fönster som en angripare kan utnyttja ett komprometterat certifikat, men de kräver också en nivå av automatisering och synlighet som manuella processer inte kan leverera. Organisationer som börjar med identifiering, snabbt går över till automatiserad utfärdande och förnyelse, och utvidgar samma disciplin till sin bredare kryptografiska egendom kommer att möta deadlines 2026, 2027 och 2029 utan de avbrott som manuella metoder tenderar att orsaka.

Encryption Consulting erbjuder ett komplett utbud av certifikat- och kryptografitjänster, inklusive PKI-revisioner, PKI-design och optimering för företag, krypteringsrevisioner och kodsignering via CodeSign Secure- plattformen. Vi stöder Zero Trust-initiativ och tillhandahåller kontinuerlig rådgivning om efterlevnad tillsammans med starka identitets- och krypteringsmetoder , så att din organisation förblir skyddad, kompatibel och redo för vad som kommer efter 47-dagars certifikat.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste lärdomen från 47-dagars TLS-certifikat?

Den viktigaste slutsatsen är att giltigheten för publika TLS-certifikat krymper till 47 dagar i mars 2029 enligt CA/Browser Forum Ballot SC-081v3, med mellanliggande steg på 200 dagar år 2026 och 100 dagar år 2027. Återanvändning av domänvalidering minskar till 10 dagar under samma period. Manuell certifikathantering kan inte upprätthålla den förnyelsefrekvensen, vilket gör automatiserad hantering av certifikatlivscykeln till ett kortsiktigt krav snarare än ett framtida övervägande.

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

Företag med hundratals eller tusentals certifikat kommer att se förnyelsevolymen öka från en gång om året till så ofta som var 47:e dag, ungefär en åttafaldig ökning. Plattformar för hantering av certifikatlivscykeln som tidigare var valfria blir operativt nödvändiga, eftersom manuell spårning och kalkylbladsbaserade förnyelsekalendrar inte kan hålla jämna steg med den frekvensen utan en betydande risk för missade deadlines.

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

PKI- och certifikatteam, säkerhetsteam, plattforms- och DevOps-team samt compliance-team delar alla ansvaret. PKI-team äger identifiering och inventering, säkerhetsteam äger återkallelse och övervakning, plattformsteam äger pipeline-automation och compliance-team äger revisionsbevis. Effekt- och åtgärdsmatrisen tidigare i den här artikeln bryter ner vad varje grupp bör prioritera före deadlines i mars 2026 och 2027.

Vilka risker ökar om detta hanteras manuellt?

Manuell hantering ökar risken för missade förnyelser, oplanerade avbrott och efterlevnadsbrister. 2022 års rapport om tillståndet för maskinidentitetshantering visade att cirka 81 % av organisationerna upplevde ett certifikatrelaterat avbrott under ett enda år, och incidenter som avbrotten i Microsoft Teams och Google Voice kunde båda spåras tillbaka till utgångna certifikat som manuella processer inte lyckades upptäcka i tid.

Hur minskar automatisering risken för certifikatavbrott?

Automatisering eliminerar beroendet av att en person kommer ihåg ett förnyelsedatum. ACME-baserad utfärdande, ihållande domänvalidering och integration med CI/CD-pipelines gör att certifikat kan förnyas enligt schema utan manuella åtgärder, medan automatiserad övervakning kan flagga fel innan de orsakar driftstopp. Detta är ännu viktigare eftersom förnyelsecyklerna komprimeras från 398 dagar till 47 dagar, eftersom marginalen för mänskliga fel krymper i takt med certifikatets livslängd.

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

Team bör spåra andelen framgångsrika certifikatförnyelser, antalet certifikat som upptäcks utanför det hanterade lagret, genomsnittlig tid för förnyelse, antal utgångna eller nästan utgångna certifikat och andelen certifikat som utfärdats via automatiserade arbetsflöden jämfört med manuella begäranden. Att spåra dessa konsekvent visar om automatisering faktiskt minskar risken för avbrott snarare än att flytta samma manuella arbete till ett annat verktyg.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

Den här artikeln förklarar policyn och effekterna bakom 47-dagars certifikatberedskap: den beskriver tidslinjen för CA/Browser Forum, varför den finns och vilka den påverkar. Beredskap är den operativa responsen som bygger upp den upptäckts-, automatiserings- och övervakningskapacitet som beskrivs i migreringskartan ovan, så att deadlines för 2026, 2027 och 2029 infaller som schemalagt underhåll snarare än som en nödsituation.

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

Multimoln- och hybridmiljöer behöver en centraliserad vy över certifikat som utfärdats av varje molnleverantör, lokal CA och SaaS-plattform, eftersom fragmenterad synlighet är just det som gör att certifikat löper ut obemärkt. En plattform för hantering av certifikatlivscykeln som stöder ACME, SCEP och EST i dessa miljöer, i kombination med kryptografisk identifiering som omfattar både moln- och lokal infrastruktur, håller förnyelsetakten konsekvent oavsett var ett certifikat utfärdades.