- Key Takeaways
- Vad är PCI DSS?
- PCI DSS 4.0.1: Var företagen står för närvarande
- Sammanfattning
- Vad som ändrades i PCI DSS 4.0
- Var du behöver fokusera
- Varför detta är viktigt för hantering av företagscertifikats livscykel
- Hur man operationaliserar detta i PKI-, säkerhets-, plattforms- och efterlevnadsteam
- Vad göra här näst
- Hur krypteringskonsulting kan hjälpa
- Slutsats
- Vanliga frågor om partihandel med mat och dryck
Snabbt svar: Nästan hälften av företagen rapporterade certifikatrelaterade driftstopp under det senaste året, och PCI DSS 4.0.1 behandlar nu den typen av fel som ett granskningsresultat, inte bara ett avbrott. Om din PCI-miljö fortfarande körs med manuell certifikatspårning, kalkylbladsbaserade omfattningsgranskningar eller en årlig inställning till validering, ligger du redan efter där standarden förväntar sig att du ska vara.
Key Takeaways
- PCI DSS 4.0.1 har trätt i kraft fullt ut. Alla 51 framtida krav blev obligatoriska den 31 mars 2025, och PCI DSS 3.2.1 togs tillbaka den 31 mars 2024, så den "framtida deadline" för denna standard har redan passerat.
- Starkare autentisering, utökad omfattningsvalidering och obligatorisk automatiserad logggranskning är inte längre valfria bästa praxis; de är granskade kontroller.
- Ett nytt delkrav (12.3.3, refererat under standardens kryptografiska inventeringsförväntningar) kräver att organisationer dokumenterar, spårar och inventerar alla TLS/SSL-certifikat över publika domäner.
- Manuell certifikatspårning är nu en skyldighet för efterlevnad, inte bara en operativ olägenhet: 45 % av företagen rapporterade certifikatrelaterade driftstopp under det senaste året, och 37.5 % spårade avbrott direkt till utgångna certifikat.
- CA/B-forumets gradvisa minskning till 47 dagars maximal giltighetstid för TLS-certifikat senast 2029 förvärrar detta problem, eftersom manuella förnyelsecykler som kämpar vid 200–398 dagar blir ogenomförbara vid 47 dagar.
- PKI-, säkerhets-, plattforms- och efterlevnadsteamen äger var och en en egen del av detta; lösningarna är certifikatidentifiering, automatiserad livscykelhantering och kontinuerlig omfattningsvalidering, inte en engångsgranskningssprint.
Vad är PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) är den globala säkerhetsstandarden för alla organisationer som lagrar, bearbetar eller överför kortinnehavardata, vilket kräver kontroller av nätverkssäkerhet, åtkomsthantering, sårbarhetshantering och kontinuerlig övervakning. Den gäller alla handlare och tjänsteleverantörer som berör betalkortsdata, oavsett storlek, och den upprätthålls av PCI Security Standards Council (PCI SSC) , ett oberoende organ som grundats av de stora kortvarumärkena för att minska betalningsbedrägerier och standardisera skyddet av kortinnehavardata.
Två kategorier av organisationer måste validera efterlevnad: handlare och tjänsteleverantörer. Kraven skalas med transaktionsvolymen; högre kortbehandlingsvolymer medför strängare valideringskrav eftersom de medför större risk. Förvärvande banker och kortvarumärken sätter dessa volymtrösklar, och de varierar något beroende på varumärke. För en djupare genomgång av omfattning och valideringsnivåer, se EU:s PCI DSS-översikt.
PCI DSS 4.0.1: Var företagen står för närvarande
PCI DSS 4.0 publicerades i mars 2022, den första större revisionen av standarden på över ett decennium. PCI DSS 3.2.1 togs officiellt bort den 31 mars 2024, varefter varje bedömning måste genomföras mot 4.0. En begränsad förtydligande version, PCI DSS v4.0.1, följde i juni 2024 utan nya krav, endast korrigeringar och ytterligare vägledning.
Det datum som faktiskt spelar roll nu är den 31 mars 2025. Av de 64 nya eller uppdaterade krav som introducerades i version 4.0, betecknades 51 som "framtidsdaterade", vilket innebär att de behandlades som bästa praxis snarare än obligatoriska fram till det datumet. Från och med den 31 mars 2025 är alla 51 verkställbara i varje PCI DSS-bedömning. Om din organisation validerade mot 4.0 år 2024 men sköt upp de framtidsdaterade kontrollerna, kommer din nästa bedömningscykel att misslyckas om inte dessa kontroller redan är implementerade, testade och dokumenterade.

PCI DSS 4.0 introducerade också ett filosofiskt skifte, inte bara ett skifte i efterlevnad. Standarden lutar sig nu mer mot resultatbaserad säkerhet än föreskrivande kontroller. Dess anpassade tillvägagångssätt låter organisationer uppnå ett säkerhetsmål på ett sätt som passar deras arkitektur, snarare än att tvinga varje miljö till en identisk kontrollchecklista, vilket är viktigt för organisationer som kör molnbaserad, hybrid eller containerbaserad betalningsinfrastruktur som aldrig passade in i den äldre föreskrivande modellen.
Sammanfattning
PCI DSS 4.0.1 gör certifikathygien till en revisionspost, inte bara en operativ risk. DigiCerts Trust Pulse-undersökning från juli 2025 visade att 45 % av organisationerna upplevde certifikatrelaterade driftstopp under det senaste året, och 37.5 % av dessa incidenter spårades tillbaka till ett utgånget certifikat, exakt det felläge som PCI DSS 4.0.1:s delkrav för certifikatinventering är utformat för att fånga. Att täppa till det gapet börjar med kontinuerlig certifikatupptäckt i kombination med certifikatautomatisering , så att ingenting i kortinnehavarens datamiljö inte spåras mellan revisionerna.
Matematiken bakom varför manuell spårning slutar fungera blir värre innan den blir bättre. Enligt CA/B Forums etappvisa schema sjunker den maximala giltighetstiden för offentliga TLS-certifikat till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. En PCI-miljö med 500 certifikat inom scope som förnyas en gång om året idag skulle behöva ungefär 4 000 förnyelseåtgärder årligen när 47-dagars TLS-certifikat når taket, en åttafaldig ökning av förnyelsearbetsbelastningen som ett kalkylblad inte kan absorbera. Samma upptäcktsarbete matar direkt in i PQC-beredskapen : att veta exakt vilka certifikat och algoritmer som finns idag är en förutsättning för att utöva verklig kryptoagilitet , och en CBOM är det som förvandlar den inventeringen till en plan du kan agera utifrån snarare än en statisk lista.
Snabb checklista
- Bekräfta att vart och ett av de 51 framtida kraven är implementerade, testade och dokumenterade, inte bara de som täcktes i din senaste bedömning.
- Kör ett automatiserat certifikatidentifieringspass över varje offentlig och intern slutpunkt i CDE:n istället för ett kalkylbladsinventering vid varje tidpunkt.
- Dokument som kontrollerar använder den definierade metoden kontra en anpassad metod, med motivering klar innan en bedömare frågar.
- Bekräfta att logggranskning, MFA och WAF-täckning uppfyller de autentiserings- och övervakningskontroller som blev obligatoriska den 31 mars 2025.
- Mappa arbetsbelastningen för certifikatförnyelse mot slutpunkten för 47 dagars giltighet för att dimensionera fallet för automatisering nu snarare än år 2029.
Vad som ändrades i PCI DSS 4.0
Sex förändringar i PCI DSS 4.0 har den mest direkta operativa effekten på PKI, certifikatlivscykel och identitetsteam.
Starkare autentiseringsåtgärder
I takt med att betalningsinfrastrukturen flyttas vidare till molnplattformar, driver PCI DSS 4.0 handlare mot starkare autentiseringskontroller , vilket i högre grad överensstämmer med NIST:s riktlinjer för digital identitet och livscykelhantering av autentiseringsuppgifter. Multifaktorautentisering krävs nu för all åtkomst till kortinnehavarens datamiljö (CDE), och identitets- och åtkomsthantering (IAM) behandlas som ett primärt försvar mot autentiseringsbaserade attacker på kortinnehavardata.
Omfattningsvalidering och datainsamling
Tjänsteleverantörer måste identifiera varje plats där kortinnehavardata lagras, bekräfta omfattningen var sjätte månad och köra kvartalsvisa dataupptäcktsoperationer. Det är här kryptografisk och certifikatupptäckt slutar vara en bra sak att ha: du kan inte validera omfattning på data eller certifikat som du inte kan se.
Det anpassade tillvägagångssättet
En av standardens största strukturella förändringar: istället för en enda föreskrivande kontroll definierar varje krav nu det säkerhetsresultat som måste uppnås. Organisationer kan uppnå det resultatet genom den definierade metoden (den traditionella föreskrivande kontrollen) eller en anpassad metod som valideras mot deras egen riskanalys. Flexibilitet betyder inte mindre noggrannhet; en anpassad metod måste fortfarande dokumenteras och försvaras av en bedömare.
Tre ytterligare förändringar kompletterar listan över vad som förändrades i 4.0:
- Delkrav för certifikatinventering: handlare måste nu dokumentera, spåra och inventera varje TLS- och SSL-certifikat används i offentliga domäner för att bekräfta fortsatt giltighet, vilket stänger en långvarig blind fläck i PCI-miljöer.
- Automatiserad logggranskning: Manuell logggranskning accepteras inte längre som tillräckligt. Det är för långsamt och för felbenäget på företagsnivå, så PCI DSS 4.0 kräver automatiserade granskningsverktyg.
- Webbapplikationsbrandväggar: Alla webbapplikationer som är exponerade för internet måste placeras bakom en WAF, vilket täcker ett gap som manuella perimetergranskningar rutinmässigt missade.
Var du behöver fokusera
Fem åtgärder avgör om er PCI DSS 4.0.1-position håller under bedömningen, och var och en kopplas till ett specifikt team.
| Användningsfall | Rekommendation | Operativ ägare | Förväntat resultat |
|---|---|---|---|
| Bekräftar att luckorna i 3.2.1 faktiskt är stängda | Kör en dokumenterad gapbedömning mot alla framtida krav, inte bara de som redan testats | Efterlevnads-/GRC-teamet | Revisionsklara bevis istället för antagen efterlevnad |
| Lokalisering av alla kortinnehavaruppgifter och stödjande certifikat | Kör frekvent, automatiserad data- och certifikatidentifiering istället för en punktinventering | PKI / Säkerhetsteam | Noggrann, aktuell omfattning; inga skuggcertifikat eller okända datalager |
| Att välja definierad kontra anpassad metod per kontroll | Dokumentera säkerhetsmålet och motivera den valda metoden innan bedömaren frågar | Efterlevnads-/säkerhetsarkitektur | Flexibilitet utan att försvaga kontrollens faktiska resultat |
| Bygga intern expertis kring standarden | Ta in extern PCI DSS-rådgivning och genomför återkommande personalutbildning snarare än en enda genomgång | Efterlevnads-/plattformsteam | Färre felaktigt tillämpade kontroller och snabbare bedömarcykler |
| Undvika onödiga säkerhetskostnader | Granska befintliga säkerhetsverktyg för oanvända eller felkonfigurerade funktioner innan du köper något nytt. | Säkerhets-/plattformsteam | Lägre kostnad för att uppnå 4.0.1-kompatibilitet med det du redan äger |
Varför detta är viktigt för hantering av företagscertifikats livscykel
PCI DSS 4.0.1:s krav på certifikatinventering och omfattningsvalidering kommer inte isolerat. De inträffar samtidigt som CA/B Forum komprimerar certifikatens livslängd i hela branschen, och de två trenderna förvärrar varandra.
DigiCerts Trust Pulse-undersökning (2 juli 2025) visade att 45 % av företagen upplevde driftstopp på grund av certifikatrelaterade incidenter under det senaste året, och 37.5 % spårade denna driftstopp specifikt till utgångna certifikat, ett av de mest förebyggbara fellägena i en betalningsmiljö. När en PCI-bedömare frågar hur ni spårar certifikatutgången över hela CDE:n är "vi kontrollerar ett kalkylblad kvartalsvis" inte längre ett försvarbart svar, och det var aldrig heller ett tillförlitligt operativt svar.
Samtidigt innebär CA/B-forumets omröstning (godkänd av Sectigo den 14 april 2025) en gradvis minskning av den maximala giltighetstiden för offentliga TLS-certifikat: 200 dagar senast den 15 mars 2026, 100 dagar senast den 15 mars 2027 och 47 dagar senast den 15 mars 2029, en minskning från det nuvarande taket på 398 dagar. En manuell förnyelseprocess som redan orsakar avbrott med en kadens på 200 till 398 dagar kommer inte att överleva en 47-dagarscykel. För en fullständig beskrivning av vad den kortare giltighetsperioden kräver operativt, se EC:s guide till 47-dagars TLS-certifikatberedskap.
Här är den ärliga läsningen: PCI DSS 4.0.1:s krav på certifikatinventering och giltighetsschemat på 47 dagar är egentligen samma problem som dyker upp från två olika håll. Det ena är ett krav på efterlevnad, det andra är ett krav från webbläsare/CA-industrin, men båda kräver samma underliggande kapacitet: kontinuerlig, automatiserad insyn i varje certifikat i din miljö, inte en periodisk granskningsövning. Team som bygger den kapaciteten en gång uppfyller båda kraven samtidigt. Team som behandlar dem som separata projekt gör slutligen upptäcktsarbetet två gånger.
Det är också här PCI DSS 4.0.1 kopplas till den bredare diskussionen om kryptografisk agilitet. En kryptografisk materiallista (CBOM) utökar samma upptäcktsdisciplin som PCI DSS nu kräver för certifikat till varje kryptografisk tillgång i din tillgång, algoritmer, nyckelstorlekar, protokollkontext och kvantsårbarhetsstatus, så att det inventarium du bygger för PCI-efterlevnad också blir grunden för beredskap efter kvantkryptografi (PQC) . För en närmare titt på hur du omvandlar det inventariet till en operativ kapacitet snarare än ett engångskalkylblad, se hur en CBOM omvandlar kryptografisk inventering till intelligens.
Företag som hanterar 1 000 till 10 000 certifikat rapporterar redan låg tilltro till att spåra utgångsdatum manuellt, och certifikatvolymerna ökar ytterligare i takt med att infrastrukturen skalas upp. Varje manuell förnyelse som läggs till den volymen är ytterligare en möjlighet till ett avbrott, ett granskningsresultat eller båda.
Hur man operationaliserar detta i PKI-, säkerhets-, plattforms- och efterlevnadsteam
PCI DSS 4.0.1-efterlevnad för certifikat och kortinnehavardata är inte ett jobb för en enskild grupp. Att tydligt dela upp ägandet är det som hindrar det från att falla mellan stolarna mellan en årlig revision och den dagliga verksamheten.
PKI-team
Äg själva certifikatinventeringen: identifiering över publika och interna slutpunkter, automatiserad förnyelse och tillämpning av giltighetsgränser före 47-dagarsfristen. Detta är den operativa kärnan som både PCI DSS 12.3.3 och CA/B Forum-schemat är beroende av.
Säkerhetsteam
Egen IAM- och MFA-tillämpning över hela CDE:n, WAF-distribution på internetanslutna applikationer och övergången från manuell till automatiserad logggranskning. Dessa mappar direkt till autentiserings- och övervakningskraven som blev obligatoriska den 31 mars 2025.
Plattformsteam
Ansvara för integrationen på infrastrukturnivå: se till att certifikatautomation, identifieringsverktyg och logggranskningssystem faktiskt ansluter till de miljöer som kör CDE:n, snarare än att existera som frånkopplade punktlösningar.
Compliance-team
Ta ansvar för dokumentationen: bedömningar av gap mot framtida krav, motiveringen för eventuella anpassade kontroller och den kvartalsvisa datainsamlingstakten som omfattningsvalidering nu kräver. Regelefterlevnad omvandlar det som PKI-, säkerhets- och plattformsteam bygger till bevis som en bedömare kommer att acceptera.
Vad göra här näst
Börja med den lucka som orsakar mest skada först: kör ett certifikatidentifieringspass över varje publik och intern slutpunkt i CDE:n före din nästa bedömningscykel, inte efter att ett avbrott tvingar fram frågan. Kombinera det med en dokumenterad luckbedömning mot alla 51 framtida krav, bekräfta vilka kontroller du uppfyller genom den definierade metoden kontra en anpassad metod, och sätt en återkommande kvartalskadens kring dataidentifiering och omfattningsvalidering snarare än att behandla det som en årlig händelse.
Spåra en liten uppsättning mätvärden efter implementeringen för att veta om förändringarna faktiskt fungerade: certifikatrelaterade driftstopp per kvartal, genomsnittlig tid för att förnya utgångna certifikat, andel certifikat under automatiserad (kontra manuell) hantering och tid som krävs för att producera en komplett rapport om kortinnehavardata och certifikatomfattning på begäran. Om dessa siffror inte förbättras har den underliggande processen faktiskt inte förändrats, oavsett vad compliance-checklistan säger.
Hur krypteringskonsulting kan hjälpa
CertSecure Manager , Encryption Consultings plattform för hantering av certifikatlivscykeln, ger PKI- och säkerhetsteam den kontinuerliga certifikatupptäckt och automatiserade förnyelse som PCI DSS 4.0.1:s inventeringskrav och CA/B Forums krympande giltighetsfönster kräver. Den lokaliserar varje TLS-certifikat och stödjande privat nyckel i kortinnehavarens datamiljö, tillämpar giltighetsgränser automatiskt och skickar utgångsmeddelanden genom integrationer som ServiceNow och Microsoft Teams så att en förnyelse aldrig är beroende av att någon kommer ihåg ett kalkylblad.
För organisationer som utvidgar samma identifieringsdisciplin bortom TLS, bygger Encryption Consultings CBOM Secure och PQC Center of Excellence den kryptografiska inventering och migreringsfärdplan som både PCI-efterlevnad och post-quantum-beredskap behöver. Besök encryptionconsulting.com för att lära dig mer, eller kontakta oss för en demo eller ett koncepttest.
Slutsats
PCI DSS 4.0.1 är inte längre en framtida deadline. Alla framtida krav har varit obligatoriska sedan den 31 mars 2025, och standardens förväntningar på certifikatinventering ligger nu direkt i linje med CA/B Forums marsch mot 47 dagars maximal TLS-giltighet. Att behandla båda som en årlig efterlevnadsövning är det som producerar de avbrott, revisionsresultat och sexsiffriga förluster som företag redan rapporterar.
Lösningen är densamma för båda problemen: kontinuerlig, automatiserad insyn i varje certifikat och kryptografisk tillgång i din miljö, gemensamt ägd av PKI-, säkerhets-, plattforms- och efterlevnadsteam snarare än att lämnas till det team som kommer ihåg att kontrollera före en granskning.
Vanliga frågor om partihandel med mat och dryck
Vad är den viktigaste slutsatsen från PCI DSS 4.0-kraven – Var behöver du fokusera?
PCI DSS 4.0.1 är fullt verkställbar: alla 51 framtida krav blev obligatoriska den 31 mars 2025. De största operativa luckorna är vanligtvis manuell certifikatspårning, sällan validering av omfång och logggranskning som inte har automatiserats. Att täcka dessa luckor kräver kontinuerlig identifiering och automatisering, inte en årlig efterlevnadskampanj.
Varför är detta viktigt för hanteringen av företagscertifikats livscykel?
PCI DSS 4.0.1 kräver att organisationer dokumenterar, spårar och inventerar alla TLS/SSL-certifikat som finns på publika domäner. Samtidigt fann DigiCerts Trust Pulse-undersökning att 45 % av företagen hade certifikatrelaterade driftstopp under det senaste året, varav 37.5 % var kopplade till utgångna certifikat. Hantering av certifikatlivscykeln är nu både ett efterlevnadskrav och en fråga om driftsäkerhet.
Vilka team ansvarar för att agera utifrån denna vägledning?
PKI-teamen äger certifikatidentifiering och automatisk förnyelse. Säkerhetsteamen äger IAM, MFA, WAF-distribution och automatisk logggranskning. Plattformsteamen äger integrationen av dessa verktyg i de miljöer som kör kortinnehavardatamiljön. Compliance-teamen äger dokumentationen och bevisspåret som en bedömare kommer att granska.
Vilka risker ökar om detta ämne hanteras manuellt?
Manuell certifikatspårning och validering av omfång ökar risken för avbrott på utgångna certifikat, oupptäckta datalager för kortinnehavare, misslyckade bedömningar och sexsiffriga ekonomiska förluster kopplade till certifikatincidenter. Manuell logggranskning accepteras inte längre som tillräckligt enligt PCI DSS 4.0.1.
Hur minskar automatisering risken för certifikatavbrott?
Automatiserad hantering av certifikatlivscykeln tar bort de manuella förnyelsesteg som sannolikt missas eller försenas, spårar utgångsdatum kontinuerligt istället för kvartalsvis och skalar upp till de kortare förnyelsecykler som CA/B Forums 47-dagarsschema kommer att kräva senast 2029.
Vilka mätvärden bör teamen följa efter implementeringen?
Spåra certifikatrelaterade driftstopp per kvartal, genomsnittlig tid för att förnya utgångna certifikat, andelen certifikat under automatiserad kontra manuell hantering och den tid som krävs för att producera en komplett rapport om certifikat- och kortinnehavardata på begäran.
Hur kopplas detta till 47-dagars TLS-certifikatberedskap?
CA/B-forumets etappvisa schema minskar den maximala giltighetstiden för TLS-certifikat från 398 dagar idag till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. En manuell förnyelseprocess som redan kämpar med dagens giltighetsperioder kan inte stödja en 47-dagarscykel, vilket gör certifikatautomatisering till en förutsättning för både PCI DSS 4.0.1 och 47-dagarsberedskap samtidigt.
Hur ska detta hanteras i multimoln- eller hybrid-PKI-miljöer?
Multimoln- och hybridmiljöer behöver certifikatidentifiering som täcker alla molnleverantörer, lokala certifikatutfärdare och publika slutpunkter i ett och samma lager, inte separata verktyg per miljö. PCI DSS 4.0.1:s anpassade tillvägagångssätt ger multimolnorganisationer flexibilitet i hur de uppfyller en kontroll, men det underliggande synlighetskravet, att veta var varje certifikat- och kortinnehavardata finns, ändras inte.
- Key Takeaways
- Vad är PCI DSS?
- PCI DSS 4.0.1: Var företagen står för närvarande
- Sammanfattning
- Vad som ändrades i PCI DSS 4.0
- Var du behöver fokusera
- Varför detta är viktigt för hantering av företagscertifikats livscykel
- Hur man operationaliserar detta i PKI-, säkerhets-, plattforms- och efterlevnadsteam
- Vad göra här näst
- Hur krypteringskonsulting kan hjälpa
- Slutsats
- Vanliga frågor om partihandel med mat och dryck
