PCI DSS v4.0.1-krav på CBOM: En snabbguide

Snabbt svar: PCI DSS v4.0.1 Krav 12.3.3 kräver att varje organisation som lagrar, bearbetar eller överför kortinnehavardata ska upprätthålla en dokumenterad, granskad inventering av varje kryptografisk chiffersvit och protokoll som används, en kryptografisk materiallista (CBOM). Kravet blev en obligatorisk utvärderad kontroll den 31 mars 2025, tillsammans med den relaterade nyckel- och certifikatinventeringen i krav 4.2.1.1. Den rekommenderade åtgärden: bygga en versionerad CBOM som täcker algoritmer, nycklar, certifikat och bibliotek, tilldela en ägare och granska den minst var 12:e månad.

Viktiga takeaways

• PCI DSS v4.0.1 Krav 12.3.3 och krav 4.2.1.1 slutade att vara "framtidsdaterade" och blev fullt ut bedömda krav den 31 mars 2025. QSA:er testar nu för dem i varje bedömning.
• En kryptografisk materiallista (CBOM) är den praktiska mekanismen för att uppfylla 12.3.3: en strukturerad, versionsbaserad inventering av varje krypteringssvit, protokoll, algoritm, nyckel och certifikat i kortinnehavarens datamiljö.
• Kravet har tre delar: underhålla inventeringen, aktivt övervaka branschens utfasningstrender och dokumentera en åtgärdsplan för när en chiffer eller ett protokoll blir osäkert.
• Krav 4.2.1.1 (betrodda nycklar och certifikat) och krav 12.3.3 (chiffreringssviter och protokoll) kompletterar varandra och bör byggas från samma identifieringsprocess, inte behandlas som separata projekt.
• En revisionsklar CBOM behöver en tilldelad ägare, en skriftligt dokumenterad 12-månaders granskningskadens och bevis som är direkt kopplade till QSA-bedömningsprocedurer för båda kraven.

Publicerad: juli 2025 | Uppdaterad: augusti 2026 | Granskad av Encryption Consultings efterlevnadsrådgivningsteam

Det här inlägget är en del av Encryption Consultings serie om kryptografisk efterlevnad. Det kompletterar våra guider om hur CBOM skiljer sig från SBOM , NIST SP 800-53 kontrollmappning och FIPS 140-3 övergångshandbok , där var och en riktar sig mot ett specifikt efterlevnadsramverks kryptografiska inventeringsförväntningar.

Vad är PCI DSS-krav 12.3.3, och vad är en CBOM?

Payment Card Industry Data Security Standard (PCI DSS) är den säkerhetsstandard som upprätthålls av PCI Security Standards Council (PCI SSC) för alla organisationer som lagrar, bearbetar eller överför betalkortsdata. PCI DSS v4.0.1 , publicerad i juni 2024, är en förtydligande revidering av v4.0 och är fortfarande den aktuella versionen av standarden i skrivande stund. Rådet har inte publicerat någon tidslinje för v4.1 eller v5.0.

Krav 12.3.3 anger att en organisation måste dokumentera "en aktuell inventering av alla kryptografiska chiffersviter och protokoll som används, inklusive syfte och var de används", måste "aktivt övervaka branschtrender" gällande kryptografins fortsatta livskraft och måste dokumentera en åtgärdsplan för förväntade förändringar i kryptografiska sårbarheter. En kryptografisk materiallista (CBOM) är den artefakt som uppfyller alla tre delarna: en strukturerad, maskinläsbar inventering av chiffersviter, protokoll, algoritmer, nyckellängder, certifikat och de kryptografiska bibliotek och moduler (OpenSSL, BoringSSL, HSM firmware) som implementerar dem, var och en mappad till det system eller den tjänst där den körs.

Krav 4.2.1.1 är det närbesläktade syskonkravet: det kräver en inventering av betrodda nycklar och certifikat som används för att skydda primärkontodata (PAN) under överföring. De flesta organisationer bygger båda inventeringarna från samma identifieringsprocess, eftersom ett certifikatinventering och ett krypteringssvitinventering överlappar varandra kraftigt i praktiken.

Hur kopplas kraven 12.3.3 och 4.2.1.1 till kontroller, ägare och bevis?

Att klara en QSA-bedömning innebär att varje delkrav kan spåras till en namngiven kontroll, en namngiven ägare och ett bevis som bedömaren kan granska. Tabellen nedan visar den mappning som Encryption Consulting använder vid scoping av ett CBOM-uppdrag mot PCI DSS v4.0.1.

Krav	kontroll	Ägare	Bevisartefakt
12.3.3(a) krypteringssvit och protokollinventering	Versionsbaserat CBOM-register som täcker varje chiffersvit, protokoll och algoritm i CDE:n	Kryptografi / säkerhetsteknik	Exporterad CBOM med ifyllda fält för system, syfte och plats
12.3.3(b) övervaka branschens lönsamhet	Prenumeration på NIST-, IETF- och CVE-utfasningsmeddelanden med en definierad granskningskadens	Säkerhetsteknik / GRC	Övervakningslogg och årlig granskningsunderskrift, daterad inom 12 månader
12.3.3(c) dokumenterad åtgärdsplan	Kryptografisk sårbarhetsresponsbok med tidslinjer och intressenter	Säkerhetsteknik / incidenthantering	Responsplandokument och bevis på minst en bordsövning
4.2.1.1 inventering av betrodda nycklar och certifikat	Certifikat- och nyckelinventering kopplad till PAN-in-transit-system	PKI / certifikatlivscykelteam	Export av certifikatinventering och logg för tilldelning av nyckelförvaltare
3.6 / 3.7 nyckelhantering för lagrade kontodata	Dokumenterade nyckelhanteringsrutiner som täcker generering, rotation och förstörelse	Nyckelgrupp	Utdrag från nyckelhanteringspolicy och HSM-granskningslogg
12.10.5 incidentrespons för kritiska varningar	Incidenthanteringsplan explicit begränsad till kryptografiska och IDS/ändringsdetekteringsaviseringar	Säkerhetsåtgärder	IR-plan med kryptospecifik eskaleringsväg

Vilka är implementeringsstegen för att bygga en PCI DSS-klar CBOM?

1. Upptäck varje kryptografisk tillgång i kortinnehavarens datamiljö: krypteringssviter och protokoll via nätverks- och slutpunktsskanning (nmap, sslscan eller verktyg för kontinuerlig identifiering), plus certifikat, nycklar, bibliotek och HSM/TPM-moduler.
2. Klassificera och kontextualisera varje fynd: syfte (till exempel ”TLS-avslutning för den kortinnehavarvända API-gatewayen”) och plats (system-, tjänst- eller tredjepartsintegration).
3. Bygg CBOM-registret i ett versionskontrollerat format så att varje ändring, avveckling och åtgärd spåras över tid snarare än skrivs över.
4. Tilldela ägarskap för varje kryptografisk domän (chiffreringssviter, certifikat, nycklar, HSM:er) till ett namngivet team, inte en allmän säkerhetspostlåda.
5. Fastställ 12-månaders granskningskadensen skriftligen, i linje med organisationens PCI DSS-bedömningskalender, så att själva granskningsdatumet blir en artefakt.
6. Prenumerera på källor för utfasningNIST-, IETF- och CVE-rekommendationer, så en chiffer som går från "godkänd" till "avskräckt" upptäcks innan en bedömare frågar om den.
7. Dokumentera responsplanenTidslinjer för att avveckla ett krypteringsverktyg, reservkonfiguration, ansvariga intressenter och valideringssteg före driftsättning.
8. Paketera bevisen QSA kommer att be om: CBOM-export, övervakningslogg, svarsplan och den certifikat-/nycklinventering som krävs enligt 4.2.1.1.

Vad är den nuvarande statusen för PCI DSS v4.0.1, och vilken deadline gäller nu?

PCI DSS v4.0.1 är den nuvarande publicerade versionen av standarden. Version 3.2.1 togs helt bort i slutet av mars 2024, och de "framtidsdaterade" kraven som introducerades i v4.0, inklusive krav 12.3.3 och krav 4.2.1.1, blev obligatoriska och utvärderade krav den 31 mars 2025. Det datumet har redan passerat: från och med denna uppdatering behandlas båda kraven precis som alla andra PCI DSS-kontroller under en rapport om efterlevnad eller ett självutvärderingsformulär. Det finns ingen respitperiod kvar, och PCI SSC har inte tillkännagivit någon offentlig tidslinje för en v4.1- eller v5.0-lansering, så organisationer bör planera kring v4.0.1 som baslinje för överskådlig framtid.

Vilka är begränsningarna med en CBOM-baserad metod?

• En CBOM är bara så komplett som identifieringsprocessen bakom den; ohanterade skuggcertifikat, hårdkodade API-nycklar och interna öst-västliga TLS-anslutningar är de vanligaste blinda fläckarna.
• Krav 12.3.3 föreskriver inte ett specifikt verktyg eller filformat, så QSA:er kommer att acceptera olika CBOM-implementeringar så länge de tre delkraven bevisligen är uppfyllda.
• En inventering som inte är versionskontrollerad kan inte bevisa att en 12-månadersgranskning faktiskt har ägt rum; ett kalkylblad som skrivs över varje år uppfyller varken andan eller, i praktiken, de flesta QSA-testprocedurer.
• CBOM:s omfattning under PCI DSS är begränsad till kortinnehavardatamiljön; organisationer som strävar efter bredare kryptografisk styrning (NIST SP 800-53, FIPS 140-3 eller kryptoagilitetsprogram) kommer att behöva en inventering med bredare omfattning än vad 12.3.3 strikt kräver.

Checklista för redovisning av krav 12.3.3

1. CBOM-export som täcker varje chiffersvit, protokoll, algoritm och nyckellängd i CDE, med syfte och plats ifyllda för varje post.
2. Certifikat och nyckelinventering som uppfyller krav 4.2.1.1, med korsreferens till CBOM.
3. Dokumenterad 12-månaders granskningskadens med den senaste granskningens underskrift daterad och namngiven.
4. Övervakningslogg som visar prenumeration på NIST-, IETF- eller CVE-utfasningsmeddelanden.
5. Responsplan för kryptografisk sårbarhet med definierade tidslinjer, reservlösningar och intressenter.
6. Bevis på minst en bordsövning eller simulerad avskrivningsrespons.
7. Namngiven ägare tilldelad varje kryptografisk domän (chiffreringssviter, certifikat, nycklar, HSM:er).
8. Versionshistorik för CBOM-registret som visar förändringar över tid, inte en enda statisk ögonblicksbild.

Vad skulle krypteringskonsulter rekommendera?

Behandla krav 12.3.3 och 4.2.1.1 som ett enda identifieringsprojekt, inte två. Organisationer som bygger en certifikatinventering isolerad från en chiffersvitsinventering slutar rutinmässigt med att skanna om samma miljö två gånger, en gång för varje krav, när ett enda CBOM-identifieringspass med rätt datamodell täcker båda. Vår rekommendation är att investera i kontinuerlig identifiering snarare än en tidsbestämd genomsökning: kortinnehavardatamiljöer ändras mellan bedömningscykler, och en CBOM som byggs en gång och aldrig uppdateras är en efterlevnadsskyldighet förklädd som en efterlevnadsartefakt. Koppla CBOM med vår CBOM Secure- plattform för kontinuerlig identifiering och våra Compliance Advisory Services för gapanalys mot de exakta QSA-testprocedurerna för v4.0.1.

Vanliga frågor om partihandel med mat och dryck

Vad är PCI DSS-krav 12.3.3?

Det kräver att organisationer som omfattas av PCI DSS upprätthåller en dokumenterad, uppdaterad inventering av alla kryptografiska chiffersviter och protokoll som används, övervakar branschtrender för att säkerställa deras fortsatta livskraft och dokumenterar en åtgärdsplan för förväntade kryptografiska sårbarheter. Det blev ett obligatoriskt och utvärderat krav den 31 mars 2025.

Är en CBOM obligatorisk enligt PCI DSS?

PCI DSS nämner inte ”CBOM” som en obligatorisk artefakt, men en CBOM är det praktiska sättet som de flesta organisationer uppfyller delkraven för inventering, övervakning och responsplan i krav 12.3.3 i en form som en QSA kan testa mot.

Hur skiljer sig CBOM från SBOM enligt PCI DSS?

En Software Bill of Materials (SBOM) inventerar alla programvarukomponenter i en applikation. En CBOM begränsar detta till specifikt kryptografiska tillgångar: krypteringssviter, protokoll, algoritmer, nycklar och certifikat. PCI DSS-krav 12.3.3 avser CBOM-omfattningen, inte den bredare SBOM. Se vår guide om CBOM och SBOM för en fullständig jämförelse.

Vad händer om en organisation inte upprätthåller ett kryptografiskt inventarium?

Sedan den 31 mars 2025 har underlåtenhet att visa efterlevnad av krav 12.3.3 resulterat i ett fynd i rapporten om efterlevnad eller självbedömningsformuläret, precis som alla andra PCI DSS-kontrollluckor, vilket kan försena certifieringen och, beroende på den förvärvande bankens policy, påverka bearbetningsrättigheterna.

Hur ofta måste det kryptografiska inventariet granskas?

Minst en gång var 12:e månad, och själva granskningsdatumet måste dokumenteras som bevis, inte bara förekomsten av en inventering.

Redo att täppa till luckan? Kontakta Encryption Consulting på [email protected] för att få ett CBOM-upptäcktsåtagande i linje med PCI DSS v4.0.1.

Referensprojekt

• PCI DSS v4.0.1, PCI Security Standards Council
• PCI SSC: Nyss publicerad, PCI DSS v4.0.1
• PCI Security Standards Council