Allt du behöver veta om PKI-som-en-tjänst (PKIaaS)

Den 21 juli 2024 orsakade ett utgånget certifikat i Bank of Englands egen infrastruktur att dess CHAPS och system för detaljhandelsavveckling kopplades bort i 91 minuter, på grund av bankens eget konto. Det är inte ett mindre IT-problem. Det är en påminnelse om att utgångna eller misskötta certifikat kan stoppa ett betalningssystem helt. PKI-as-a-service finns för att förhindra just det scenariot genom att flytta hela certifikatlivscykeln, från att konfigurera en certifikatutfärdare (CA) till att utfärda, förnya och återkalla slutenhetscertifikat, till en hanterad molnplattform.

Istället för att köpa hårdvara, installera programvara och anställa dedikerad PKI-personal får du samma tillförlitliga infrastruktur levererad som en tjänst, med automatiserade procedurer och lägre omkostnader för att hantera certifikatets livscykel åt dig.

Sammanfattning

PKI-as-a-Service (PKIaaS) hanterar en organisations rot- och utfärdande certifikatutfärdare i molnet och automatiserar utfärdande, förnyelse och återkallelse av certifikat. Här är vad som är viktigast för ett PKI- eller säkerhetsteam som utvärderar det:

• PKIaaS är värd för dina rot- och utfärdande certifikatutfärdare i molnet och hanterar hela certifikatlivscykeln åt dig.
• Den använder samma PKI-byggstenar som en lokal distribution: offentliga/privata nyckelpar, digitala certifikat och en förtroendekedja som är förankrad i en CA.
• CA/Browser Forum Ballot SC-081v3 förkortade den maximala livslängden för publika TLS-certifikat till 200 dagar från och med den 15 mars 2026, och upp till 47 dagar i mars 2029, vilket gör manuell certifikathantering alltmer opraktisk.
• Automatiserade registreringsprotokoll (ACME, SCEP, EST, WSTEP) är det som låter PKIaaS utfärda och förnya certifikat utan att en människa behöver klicka på "förnya" varje gång.
• PKIaaS byter förskottskostnader för hårdvara och personal mot en prenumerationsmodell, samtidigt som du fortfarande låter dig kontrollera certifikatpolicyn och, i Encryption Consultings modell, dina egna privata nycklar.

Nu när du vet vad PKIaaS är en överblick, låt oss titta på hur det relaterar till själva Public Key Infrastructure, eftersom PKIaaS inte ersätter PKI-koncept, det ändrar bara vem som driver dem.

Hur PKI-som-en-tjänst relaterar till offentlig nyckelinfrastruktur (PKI)

PKI utfärdar digitala certifikat (som SSL/TLS-certifikat) för att autentisera datakommunikation med hjälp av asymmetrisk kryptering, vilket genererar X.509-certifikat från publika och privata nyckelpar. Oavsett om du kör detta internt eller köper det som PKIaaS, utgör samma fyra komponenter förtroendekedjan.

Offentliga och privata nycklar

Publika och privata nycklar utför asymmetrisk kryptering. När en klient behöver ta emot känslig information delar den sin publika nyckel med avsändaren för att kryptera informationen. Endast innehavaren av den matchande privata nyckeln kan dekryptera och läsa den.

Digitala certifikat

CA:ns privata nyckel signerar det digitala certifikatet . Denna signatur bekräftar både certifikatinnehavarens identitet och deras ägande av den tillhörande publika nyckeln.

Certifikatutfärdare: Rot-CA och utfärdande CA

Certifikatutfärdaren signerar och utfärdar det digitala certifikatet med sin egen privata nyckel. Det finns två nivåer:

• Rot-CA: den högsta myndigheten som lägger grunden för förtroendet i PKI-hierarkin. Den utfärdar och signerar certifikat för mellanliggande CA:er och förvaras vanligtvis offline i en mycket säker miljö för att skydda långsiktigt förtroende.
• Utfärdande CA: bearbetar och signerar slutgiltiga certifikatförfrågningar (till exempel SSL/TLS-certifikat), oavsett om de kommer in via en Microsoft CA-proxy eller en annan registreringsväg. Den fungerar online och hanterar daglig utfärdande, förnyelse och återkallelse.

Registrerings myndighet

Registreringsmyndigheten sitter mellan användare och CA. Den verifierar identiteten på alla som begär ett certifikat och vidarebefordrar sedan validerade förfrågningar till CA för utfärdande.

PKI-som-en-tjänst kontra självhanterad (traditionell) PKI: Vilken är rätt för dig?

Komponenterna ovan är desamma oavsett om du distribuerar PKI lokalt (självhanterat) eller köper det som PKIaaS. Det som förändras är vem som driver dem, och den skillnaden driver kostnad, hastighet och skalbarhet.

Faktor	PKI-som-en-tjänst	Självhanterad (traditionell) PKI
konfiguration	Snabb, hanterad installation med minimal infrastruktur som krävs från din organisation.	Betydande tid, expertis och resurser som behövs för hårdvara, programvara och nätverkskonfiguration.
Verksamhetsledningen	Utfärdande, förnyelse och återkallelse av certifikat hanteras av tjänsteleverantören, vilket minskar driftskostnaderna.	Hanteras internt, kräver dedikerad personal för löpande certifikatuppgifter och underhåll.
Skalbarhet	Molninfrastrukturen justeras automatiskt allt eftersom certifikatvolymen växer eller fluktuerar.	Skalning kräver ytterligare hårdvara, programvarulicenser och konfigurationsändringar.
Pris	Prenumerationsmodellen eliminerar kostnader för hårdvara, programvara och löpande underhåll, vilket minskar initiala investeringar.	Kräver stora initiala investeringar i hårdvara, programvaruinstallation och löpande hantering.
Förnyelsekadens med 47 dagars giltighetstid	Automatiserade utfärdandeprotokoll (ACME, SCEP, EST) absorberar förnyelsefrekvensen utan ytterligare personalstyrka.	Manuella förnyelseprocesser slutar fungera långt innan certifikat når 100 dagars, än mindre 47 dagars, livslängd.

PKI-as-a-Service passar bättre för organisationer som prioriterar användarvänlighet, kostnadsbesparingar och snabbare distribution, särskilt i takt med att certifikatens livslängd fortsätter att krympa. Organisationer med strikta krav på datalagring eller högspecialiserade CA-konfigurationer kan fortfarande ha giltiga skäl att hålla PKI självhanterat, men listan blir kortare i takt med att automatiseringsprotokollen mognar.

Köparbeslutstabell: Vilken PKI-distributionsmodell passar din organisation?

Använd den här tabellen för att matcha din organisations begränsningar med en distributionsmodell innan du utvärderar leverantörer.

Kriterium	PKI på plats	SaaS PKI	PKIaaS
Dedikerad PKI-personal tillgänglig	Krävs	Minskad, men fortfarande nödvändig för politiken	Krävs inte
Tillväxt i certifikatvolymen	Skalning kräver ny hårdvara	Skalar inom din molnklient	Skalas automatiskt, leverantörsstyrt
Dags till första certifikatet	Veckor till månader	Dagar till veckor	Dagar
Budgetmodell	Hög initial kapitalinvestering	Molnförbrukning plus intern personaltid	Prenumeration, minimal initial kostnad
Privat nyckelkontroll	Fullständig, i dina egna HSM:er	Fullständigt, i din egen molnhyresgäst	Fullständig, i leverantörshostade HSM:er (enligt Encryption Consultings modell)
Bäst passform för	Strikt datalagring eller högspecialiserade CA-konfigurationer	Organisationer som redan är standardiserade på en molnplattform	Organisationer som prioriterar hastighet, automatisering och minskade omkostnader

Så fungerar PKI-som-en-tjänst: Arbetsflödet för certifikatförfrågningar

Från det ögonblick då en enhet skickar in en begäran om certifikatsignering till det ögonblick då den tar emot ett signerat certifikat, går begäran genom fem steg på en PKIaaS-plattform:

1. Initiering av certifikatbegäran. En klient begär ett certifikat med hjälp av ett protokoll som ACME, SCEP eller I samklangBegäran går till Certificate Enrollment Gateway (CEG), som bygger en säker anslutning till Certificate Authority Gateway (CAGW) med hjälp av sitt eget klientcertifikat.
2. Behandling av begäran. CAGW, som finns på ett containeriserat system, tar emot begäran och vidarebefordrar den till lämplig hanterad CA via en säker proxy.
3. Anslutning till utfärdande CA. Proxyn överbryggar CAGW och den angivna utfärdande CA, med anslutningen säkrad av gemensamma klient- och servercertifikat.
4. Certifikatutfärdande. Den utfärdande CA utfärdar slutgiltigt entitetscertifikat, ofta genom Active Directory-certifikattjänster (AD CS).
5. Certifikatleverans. Det signerade certifikatet returneras via ombudsmannen till CAGW, som skickar det till CEG för leverans till den begärande klienten.

Varje steg i den här kedjan säkras genom ömsesidig certifikatautentisering, så hela resan, från begäran till leverans, sker utan att en person manuellt godkänner varje certifikat.

Viktiga funktioner i PKI-som-en-tjänst

PKI-as-a-Service erbjuder en omfattande uppsättning funktioner för att hantera digitala certifikat och nyckelpar. Kärnfunktionerna delas in i fyra grupper:

• PKI-infrastrukturhanteringCentraliserad konfiguration av hanterad PKI, inklusive valfri rot-CA-separation, där hela CA-livscykeln följer branschbeprövade metoder, såsom FIPS 140-3 nivå 3 HSM:er, för att säkra CA-privata nycklar med hög tillgänglighet. NIST pensionerar FIPS 140-2-valideringscertifikat till historisk status den 21 september 2026, så nya HSM-distributioner bör specificera FIPS 140-3.
• Certifikatutfärdarens säkerhetRot-CA-nycklar genereras säkert och transparent, med automatiska registreringsprotokoll som SCEP, EST och ACME plus REST API:er som automatiserar utfärdande och förnyelse.
• Policy och efterlevnadshanteringCertifikatprofiler, giltighetsperioder och begränsningar för nyckelanvändning definieras för att uppfylla din organisations säkerhetskrav samtidigt som standarder som NIST, FIPS och GDPR följs.
• Integration och automatiseringRESTful API:er kopplar PKI-tjänster till andra applikationer och system, med skript och verktyg som automatiserar utfärdande och hantering från början till slut.

Användningsfall för PKI-som-en-tjänst och protokoll som stöds

PKIaaS tjänar sitt värde genom automatisering, och automatisering körs med standardiserade registreringsprotokoll. Här är vad var och en gör och var den passar in.

Automatiserad certifikathanteringsmiljö (ACME)

• Automatiserar kommunikationen mellan certifikatutfärdare och klienter som begär servercertifikat för en domän, definierat i RFC 8555.
• Validerar domänägande via HTTP-01-utmaningar (placering av en fil på webbservern) eller DNS-01-utmaningar (skapande av en DNS-post).
• Kommunicerar via HTTPS, vilket håller certifikathanteringsprocessen säker och manipulationssäker.
• Är det protokoll som Chrome Root Program har krävt att CA-ansökare stöder sedan februari 2024, och det som CA/Browser Forums förkortade certifikatlivslängder belönar mest direkt, eftersom det är byggt för fullständig automatisering utan manuellt förnyelsesteg.

Simple Certificate Enrollment Protocol (SCEP)

• Automatiserar certifikatregistrering för enheter som routrar och switchar, vilket minskar manuellt arbete i enhetstunga miljöer.
• Använder PKCS#10 (Standarder för kryptografi med offentliga nycklar) för certifikatförfrågningar, standardiserad i RFC 8894 (2020) efter årtionden som en de facto-standard.
• Verifierar identiteten på den begärande enheten eller användaren via ett delat lösenord för utmaning innan ett certifikat utfärdas.
• Fortfarande i stor utsträckning implementerad inom hantering av mobila enheter (MDM) och äldre nätverkshårdvara, även om EST är dess moderna, säkrare efterträdare.

Registrering via säker transport (EST)

• Definierad i RFC 7030 som den moderna ersättningen för SCEP, som körs över HTTPS med ömsesidig TLS-autentisering.
• Både klient och server autentiserar varandra, vilket stänger ett förtroendegap som SCEP:s modell för delade lösenord lämnar öppet.
• Passar företags-PKI- och IoT-distributioner som redan kör TLS-infrastruktur och behöver starkare ömsesidig autentisering än vad SCEP tillhandahåller.

WSTEP (Windows-registrering)

• Låter en Windows-registreringsklient ansluta till en domänkontrollant via webbtjänsten för certifikatregistreringspolicy och begära certifikat från flera certifikatutfärdare.
• Begränsar certifikatåtkomst till auktoriserade enheter, vilket förbättrar den övergripande nätverkssäkerheten.
• skyddar certifikatregistrering data under överföring med säkra kanaler och kryptering.

Microsoft Intune-integration

• Certifikatregistreringsgatewayen kan ta emot SCEP-förfrågningar med en CSR från Windows-klienter och vidarebefordra dem till Intune för validering, vilket effektiviserar enhetshanteringen över mobila enheter, stationära datorer och virtuella slutpunkter.
• Kryptografiska policyer och algoritmer förblir i linje med regelverk och efterlevnadskrav.
• Automatisk återkallelse i Intune påskyndar ogiltigförklaring av certifikat, vilket stöder en starkare katastrofåterställningsplan.

Slutpunktsautentisering (UEM/MDM)

• Verifierar att certifikat utfärdas med starka säkerhetsinställningar, vilket ger insyn i certifikatets användning och giltighet.
• Kräver att MDM-klienter (Mobile Device Management) autentiserar sig mot certifikatregistreringsgatewayen med giltiga inloggningsuppgifter, med minst ett användarnamn/lösenordspar definierat per klient.
• Tillämpar detaljerad åtkomstkontroll och rollbaserade behörigheter, ett efterlevnadskrav enligt NIST och FIPS 140-3, så att endast behörig personal hanterar känsliga certifikatfunktioner.
• Utfärdar endast certifikat efter att ha utvärderat både integritetskontroller och säkerhetsuppdateringsnivåer på den begärande enheten.

S / MIME

• Tillhandahåller end-to-end-kryptering av e-postmeddelanden.
• Separerar signerings- och krypteringsfunktioner, vilket gör att S/MIME-certifikat kan leverera oavvislighet tillsammans med sekretess.
• Använder hantering av nyckelhistorik och automatisk säkerhetskopiering för att hålla kryptografiska nycklar tillgängliga utan avbrott.
• Fungerar på Windows, macOS, iOS och Android.

Hanterad PKI

• Säkrar rot-CA-infrastrukturen enligt ISO/IEC 27001-standarder och skyddar kryptografiska tillgångar.
• Ger dig full kontroll över dina privata nycklar, med fullständig översikt över certifikat och kryptografiska operationer.
• Lagrar privata nycklar i FIPS 140-3 nivå 3-certifierade Hårdvarusäkerhetsmoduler (HSM) för att förhindra obehörig åtkomst eller manipulering.
• Verifierar certifikatets giltighet och status via CRL (Certificate Revocation List) och OCSP (onlinecertifikatstatusprotokoll) tjänster.

SLA och checklista för säkerhetskontroll för utvärdering av en PKIaaS-leverantör

Innan du skriver under ett PKIaaS-kontrakt, bekräfta att leverantören uppfyller dessa SLA och säkerhetskontroller:

• Publicerat drifttids-SLA (99.9 % eller högre) för utfärdande-, förnyelse- och återkallelseslutpunkter, med dokumenterade svarstider för incidenter.
• Root och utfärdande av CA-privata nycklar genererade och lagrade i FIPS 140-3 nivå 3-validerade HSM:er, inte allmänna servrar.
• Åtaganden för tillgänglighet för CRL- och OCSP-svarare, publicerade separat från SLA för kärnutgivning.
• Dokumenterade procedurer för nyckelceremonier och granskningsrättigheter för generering av rot-CA-nycklar.
• En angiven handläggningstid för certifikatåterkallelse efter en rapporterad nyckelkompromettering.
• Rollbaserad åtkomstkontroll och flerpersonsauktorisering för känsliga CA-operationer.
• Tydlig information om var certifikatmetadata och granskningsloggar lagras, för att bekräfta dataregistrering.
• Dokumenterad katastrofåterställning och redundansövergångsarkitektur på det utfärdande CA-lagret.
• Aktuella efterlevnadscertifieringar (ISO/IEC 27001, SOC 2, PCI-DSS, HIPAA, GDPR) med aktuella revisionsdatum.
• Avtalsvillkor som bekräftar äganderätt och portabilitet av privata nycklar om du byter leverantör senare.

HSM och efterlevnadskrav för PKI-som-en-tjänst

En PKIaaS-plattform är bara så pålitlig som hårdvaran som skyddar dess CA-privata nycklar och det regelverk som styr dess drift.

• FIPS 140-3 Nivå 3 HSMPrivata nycklar för rot- och utfärdande CA-nycklar bör genereras och lagras i FIPS 140-3 nivå 3-validerade hårdvarusäkerhetsmoduler. NIST pensionerar FIPS 140-2-valideringscertifikat till historisk status den 21 september 2026, så bekräfta att alla HSM som din leverantör använder är FIPS 140-3-validerade och inte förlitar sig på ett utgånget FIPS 140-2-certifikat.
• ISO / IEC 27001Leverantörens system för informationssäkerhetshantering bör ha en aktuell ISO/IEC 27001-certifiering som täcker de system som är värd för er CA-infrastruktur.
• HIPAA, PCI-DSS och GDPROm dina certifikat skyddar PHI, kortinnehavardata eller EU-personuppgifter, bekräfta att leverantörens PKIaaS-miljö uttryckligen ingår i deras HIPAA-, PCI-DSS- eller GDPR-efterlevnadsprogram, inte bara moderbolagets allmänna efterlevnadspolicy.
• NyckelförvaringsmodellFörtydliga i förväg om din organisation eller leverantören har den slutgiltiga kontrollen över rot-CA:ns privata nyckel. Encryption Consultings PKIaaS-modell håller den kontrollen hos kunden, vilket inte alla leverantörer erbjuder.

Varför certifikatautomatisering är viktigt nu: 47-dagarsfristen

Här är den del som de flesta PKI-förklarare ignorerar: argumenten för PKIaaS blev mycket starkare 2026, och det handlar inte bara om bekvämlighet längre.

I april 2025 godkände CA/Browser Forum Ballot SC-081v3, som fastställer en stegvis minskning av den maximala giltighetsperioden för offentliga TLS-certifikat: 200 dagar från och med den 15 mars 2026 (redan i kraft), 100 dagar från och med den 15 mars 2027 och 47 dagar från och med den 15 mars 2029. Det är en minskning från den gamla 398-dagarsstandarden till förnyelser var 47:e dag, ungefär åtta gånger om året, inom tre år.

Den operativa matematiken fungerar inte med manuell förnyelse med den frekvensen, och branschdata stöder det. CyberArks rapport om säkerhetsstatus för maskinidentiteter från 2025, baserad på en undersökning av mer än 1 200 säkerhetsledare, fann att 72 % av organisationerna upplevde minst ett certifikatrelaterat avbrott under det senaste året, och 50 % rapporterade en säkerhetsincident eller ett intrång kopplat till komprometterade maskinidentiteter. Automatisering har också blivit ett villkor för inträde för offentliga certifikatutfärdare: Chrome Root Program har krävt att certifikatutfärdaransökande stöder minst en automatiserad utfärdande- och förnyelselösning för varje certifikatpolicy de utfärdar sedan februari 2024, och från och med den 15 juni 2026 kräver det dessutom att offentligt betrodda TLS-certifikat endast bär serverautentiserings-EKU, vilket skickar alla organisationer som fortfarande använder offentliga certifikat för klientautentisering eller mTLS till en privat certifikatutfärdare.

Vår synpunkt: om ert team fortfarande förnyar certifikat manuellt, eller spårar dem i ett kalkylblad, är 100-dagarsfasen i mars 2027 den punkt där den processen avbryts, inte 47-dagarsfasen 2029. Betrakta 2026-2027 som fönstret för att gå vidare till ACME-, SCEP- eller EST-driven automatisering, oavsett om det är via en intern plattform eller en PKIaaS-leverantör, innan förnyelsefrekvensen överstiger ert teams förmåga att hålla jämna steg manuellt.

Varför krypteringskonsulting för PKI-as-a-Service?

Implementera PKI-som-en-tjänst i din miljö

Encryption Consulting erbjuder en flexibel, högkvalitativ PKIaaS-lösning med skalbart stöd som hanterar hela livscykeln för digitala certifikat för din organisation. Två områden sticker ut:

• Anpassningsbara och skalbara lösningarett ramverk skräddarsytt för din organisations säkerhetskrav, med brett stöd för CA och möjligheten att skala certifikat- och användarvolym utan att hämma prestandan.
• Konsekvent stödstarka säkerhetsfunktioner i linje med HIPAA, PCI-DSS och GDPR, plus dagligt operativt stöd för att hålla certifikatpolicyerna under kontroll.

Implementeringsmodeller: lokalt, SaaS PKI och PKIaaS

Krypteringskonsulting stöder tre distributionsmetoder, så att du kan matcha modellen till din miljö:

• PKI på platsHanterad PKI distribuerad inom din egen infrastruktur, med rot- och utfärdande CA:er lokalt.
• SaaS PKIHantering av certifikatlivscykel konfigurerad i din organisations egen molnplattform.
• PKIaaSAutomatiserad hantering av certifikatlivscykeln och anpassad hanterad PKI som helt och hållet ligger i Encryption Consultings molnmiljö, anpassad till din domän och dina säkerhetskrav.

Slutsats

PKIaaS är den molnbaserade utvecklingen av samma PKI-förtroendemodell som organisationer har förlitat sig på i årtionden, bara utan hårdvara, personal och manuella förnyelser. Varje organisation som hanterar känsliga data, oavsett om det är personligt identifierbar information (PII) eller skyddad hälsoinformation (PHI), behöver den autentisering och kryptering som en PKI tillhandahåller. PKIaaS levererar det som en hanterad molntjänst istället för ett internt infrastrukturprojekt.

Med CA/Browser Forums reduktion av certifikatens livslängd redan på gång, är tidsfrågan inte om certifikathanteringen ska automatiseras, utan hur snart. En PKIaaS-plattform byggd på ACME, SCEP och EST ger dig den automatiseringen utan att öka antalet anställda, samtidigt som du fortfarande låter dig kontrollera certifikatpolicyn och, beroende på leverantör, dina egna privata nycklar.

Vanliga frågor om PKI-som-en-tjänst

Vad är den viktigaste lärdomen från den här guiden till PKI-as-a-Service?

PKIaaS flyttar rot- och utfärdande CA-operationer, HSM-hantering och hela certifikatlivscykeln till en hanterad molnplattform, vilket gör det möjligt för ett företag att byta kapitalkostnaden och personalbördan för självhanterad PKI mot en prenumeration som skalar automatiskt och håller jämna steg med krympande certifikatgiltighetsperioder.

Varför är PKI-as-a-Service viktigt specifikt för PKI-team på stora företag?

Företags-PKI-team autentiserar varje server, enhet och tjänst i nätverket, och i takt med att giltighetstiden för offentliga TLS-certifikat minskar från 398 dagar till 47 dagar år 2029, blir manuell utfärdande och förnyelse operativt ohållbar på företagsnivå. PKIaaS ger dessa team automatiserade registreringsprotokoll (ACME, SCEP, EST) så att certifikatvolymen kan växa utan att ytterligare personalstyrka ökar.

Vilka risker ökar om PKI hanteras manuellt istället för via PKIaaS?

Manuell PKI-hantering ökar risken för avbrott på utgångna certifikat, som Bank of Englands 91 minuter långa CHAPS-avbrott, missade förnyelser gömda i kalkylblad, inkonsekvent nyckelskydd utanför FIPS-validerade HSM:er och försenad återkallelse efter en kompromiss. CyberArks undersökning från 2025 fann att risker som dessa redan påverkar majoriteten av företag.

Vilka team bör äga PKI-as-a-Service-implementeringen och den löpande driften?

Säkerhetsarkitektur och identitets-/PKI-team bör äga CA-hierarkidesign och policybeslut, medan IT-drifts- eller plattformsteknikteam vanligtvis äger den dagliga registreringsintegrationen mellan Intune, DevOps-pipelines och nätverksenheter. Compliance-team behöver insyn i granskningsloggning och nyckelförvaringsvillkor, eftersom HSM och myndighetskrav i slutändan ligger hos dem.

Hur kopplas PKIaaS till certifikatlivscykelhantering (CLM)?

PKIaaS är infrastrukturlagret, rot- och utfärdande certifikatutfärdare själva, medan hantering av certifikatlivscykeln är det operativa lagret som spårar utfärdande, förnyelse, återkallelse och utgång för varje certifikat som certifikatutfärdaren utfärdar. Att para ihop en PKIaaS-distribution med en CLM-plattform som CertSecure Manager ger fullständig insyn från certifikatutfärdaren ner till enskilda certifikat, vilket manuell spårning inte kan matcha i stor skala.

Hur bör organisationer mäta framgången med en PKIaaS-implementering?

Spåra antal certifikatrelaterade avbrott (mål: noll), genomsnittlig tid från inlämning av CSR till utfärdande av certifikat, andelen certifikat som utfärdats via automatiserade protokoll jämfört med manuell begäran, HSM- och CA-revisionsresultat per cykel och efterlevnad av CA/Browser Forums krympande giltighetsfönster utan manuell intervention. En minskning av oplanerade förnyelseincidenter är den tydligaste framgångstecknen.

Vad bör granskas eller övervakas regelbundet i en PKIaaS-miljö?

Granska CA:s privata nycklar och HSM-åtkomstloggar, loggar för utfärdande och återkallelse av certifikat, drifttid för CRL/OCSP-svarare, autentiseringshändelser för registreringsprotokoll (ACME-utmaningsvalidering, delade SCEP-hemligheter, EST-ömsesidig TLS) och anpassning av efterlevnad mot ISO/IEC 27001, HIPAA, PCI-DSS eller GDPR, beroende på vilket som gäller för din organisation.

Hur påverkar PKIaaS moln-, hybrid- eller multi-CA PKI-miljöer?

PKIaaS är utformat för att fungera i moln-, hybrid- och multi-CA-miljöer. Certificate Authority Gateway dirigerar förfrågningar till lämplig hanterad CA via en säker proxy, så en organisation som kör flera CA:er, till exempel separata CA:er för interna enheter och offentligt riktade TLS, får ett enda automatiserat registreringslager istället för att hantera varje CA:s förnyelseprocess separat.

Vilka vanliga misstag bör team undvika när de inför PKI-as-a-Service?

De vanligaste misstagen är att behandla PKIaaS som en flytt-och-förskjutning av befintliga manuella processer istället för att omstrukturera kring automatisering, att inte bekräfta exakt var leverantören genererar och lagrar privata nycklar innan ett kontrakt undertecknas, att hoppa över FIPS 140-3-valideringskraven för HSM:er och att inte testa redundansöverföring till en redundant utfärdande certifikatutfärdare innan den behövs under ett avbrott.

Vad bör uppdateras kvartalsvis i ett PKI-as-a-Service-program?

Granska CA-certifikatprofiler och giltighetsperioder mot det aktuella CA/Browser Forum-schemat, validera HSM FIPS-certifieringsstatus på nytt, särskilt med tanke på att FIPS 140-2-certifikat flyttar till historisk status den 21 september 2026, uppdatera inventeringen av registreringsprotokoll som används per enhetstyp och bekräfta SLA- och säkerhetskontrollåtaganden med din PKIaaS-leverantör.