Wie PCI DSS v4.0 und v4.0.1 die Regeln für die Verschlüsselung von Karteninhaberdaten und die Schlüsselverwaltung neu definieren

Der Countdown ist vorbei, und damit endet auch die Übergangsfrist. PCI DSS v4.0.1 wurde im Juni 2024 als Wartungsversion von v4.0 (März 2022) veröffentlicht. Diese enthielt 64 neue oder aktualisierte Anforderungen, von denen 51 erst zu einem späteren Zeitpunkt in Kraft treten sollten. Diese 51 Anforderungen traten am 31. März 2025 verbindlich in Kraft.

Durch diese Frist wurde die Kryptografie im Rahmen des PCI DSS von einem Punkt auf der Roadmap zu einer verbindlichen Betriebsanforderung. Für Händler, Dienstleister und die qualifizierten Sicherheitsprüfer (QSAs), die diese bewerten, stehen Verschlüsselung und Schlüsselverwaltung nun im Mittelpunkt jeder Diskussion über Karteninhaberdaten. Wenn Ihre Kontrollmaßnahmen noch auf der alten Basislinie basieren, ist diese Lücke bereits ein Auditbefund, der nur darauf wartet, aufgedeckt zu werden.

Dieser Leitfaden bietet einen Überblick über die kryptografischen Kontrollmaßnahmen, die gemäß Version 4.0.1 für Karteninhaberdaten gelten, worauf Prüfer achten und wie ein Programm aufgebaut werden kann, das sowohl diese als auch die nächste Anforderung erfüllt.

Warum die Kryptografie im Mittelpunkt des PCI DSS gerückt ist

PCI DSS ist ein vertraglicher Standard und kein Gesetz. Sie stimmen ihm über Ihre akquirierende Bank und die Kreditkartenunternehmen zu, sodass die Durchsetzung eher auf vertraglicher als auf gesetzlicher Basis erfolgt. Bei Nichteinhaltung drohen Geldstrafen seitens der Acquirer, höhere Gebühren pro Transaktion und im schlimmsten Fall der Verlust Ihrer Berechtigung, überhaupt noch Kartenzahlungen anzunehmen.

Die Kryptografie trägt einen Großteil dieser Verantwortung, da sie dafür sorgt, dass die Daten der Karteninhaber geschützt bleiben, unabhängig davon, wo sie gespeichert sind oder wohin sie übertragen werden. Mit dem Update auf Version 4.0 wurden die Anforderungen verschärft, und in Version 4.0.1 wurden die Formulierungen zu Verschlüsselung, Schlüsselverwaltung, Authentifizierung und kryptografischer Transparenz präzisiert – weshalb so viele der nun verbindlichen Anforderungen diese Bereiche betreffen.

Die Festlegung des Anwendungsbereichs ist oft der erste Punkt, an dem Unternehmen ins Straucheln geraten. Wenn Sie falsch einschätzen, welche Systeme Kontodaten speichern, verarbeiten oder übertragen, überträgt sich dieser Fehler auf alle nachgelagerten kryptografischen Kontrollmaßnahmen. Die richtige Festlegung des Anwendungsbereichs ist die Grundlage, auf der alles andere aufbaut.

Die Anforderungen an die Kryptografie gemäß PCI DSS

Sechs miteinander verknüpfte Kontrollbereiche legen fest, wie Karteninhaberdaten gemäß Version 4.0 und 4.0.1 geschützt werden müssen. Jeder Bereich ist für sich eigenständig, und zusammen bilden sie das Rückgrat eines vertretbaren Programms. Im Folgenden wird erläutert, was die einzelnen Bereiche erfordern und warum sie wichtig sind.

Schutz gespeicherter Kontodaten (Anforderungen 3.5 bis 3.6)

Gespeicherte Karteninhaberdaten müssen mithilfe starker Kryptografie, Tokenisierung oder Kürzung unlesbar gemacht werden. Die Speicherung einer primären Kontonummer (PAN) im Klartext ist nicht zulässig.

Eine reine Festplattenverschlüsselung reicht in vielen Umgebungen allein nicht aus. Ein sichereres Vorgehen besteht darin, zusätzlich zur Festplattenverschlüsselung eine Verschlüsselung auf Datei-, Spalten- oder Feldebene zu implementieren, wobei die Schlüsselverwaltung unabhängig von den Zugriffskontrollen des Betriebssystems erfolgt. Diese Trennung stellt sicher, dass ein kompromittierter Host die darauf gespeicherten Daten nicht automatisch offenlegt.

Verwaltung kryptografischer Schlüssel über ihren gesamten Lebenszyklus hinweg (Anforderungen 3.6 bis 3.7)

Die Verschlüsselung ist nur so sicher wie die dahinterstehenden Schlüssel; daher schreibt PCI DSS dokumentierte Verfahren vor, die den gesamten Lebenszyklus der Schlüssel abdecken: Generierung, Verteilung, Speicherung, Rotation und Außerbetriebnahme. Für jede Phase ist ein definierter, wiederholbarer Prozess erforderlich.

Für manuelle Schlüsselvorgänge schreibt die Norm eine doppelte Kontrolle und geteilte Kenntnis vor. Keine einzelne Person sollte in der Lage sein, einen Schlüssel eigenständig zu rekonstruieren oder zu missbrauchen. Dies ist einer der Bereiche, die die Prüfer besonders genau unter die Lupe nehmen; daher muss die Dokumentation mit den tatsächlichen Abläufen in der Praxis übereinstimmen.

Verschlüsselung von Karteninhaberdaten während der Übertragung (Anforderungen 4.1 bis 4.2)

Kartendaten, die über offene, öffentliche Netzwerke übertragen werden, müssen durch starke Kryptografie geschützt werden, was bedeutet, dass Algorithmen und Schlüsselstärke bestimmte Mindestanforderungen erfüllen müssen (wobei 112 Bit die Mindestschlüssellänge beträgt). So gilt beispielsweise „ TLS “ 1.2 als praktischer Mindeststandard, den Prüfer erwarten. Ältere Protokolle und schwache Konfigurationen sind genau das, was mit diesem Update beseitigt werden soll.

Eine damit verbundene Regel wird leicht übersehen: Die PAN darf niemals ungeschützt über Kommunikationskanäle für Endnutzer wie E-Mail oder Chat versendet werden. Durch die Führung eines Verzeichnisses der vertrauenswürdigen Schlüssel und Zertifikate, die zum Schutz der PAN während der Übertragung verwendet werden, lässt sich diese Kontrollmaßnahme nachweisen, anstatt sie nur anzunehmen.

Authentifizierung beim Zugriff auf die Karteninhaberdatenumgebung (Anforderungen 8.4 bis 8.5)

Für jeden Zugriff auf die Karteninhaberdatenumgebung (CDE) ist nun eine Multi-Faktor-Authentifizierung erforderlich, wobei der sicherste Ansatz eine zertifikatsbasierte, phishing-resistente MFA ist. Dies gilt sowohl für den Fernzugriff als auch für den Zugriff durch Drittanbieter und nicht nur für interne Mitarbeiter.

Das erweiterte MFA-Mandat gemäß Anforderung 8 ist eine der häufigsten Lücken im Hinblick auf das Jahr 2026. Viele Organisationen haben zwar administrative Anmeldungen abgedeckt, dabei jedoch Dienstkonten, Anbinderungen von Drittanbietern oder bestimmte CDE-Systeme außer Acht gelassen. Diese Lücken zu schließen, ist nun unabdingbar.

Erstellung eines Verzeichnisses der kryptografischen Verschlüsselungssuiten (Anforderungen 4.2.1.1 und 12.3.3)

Man kann nicht sichern, was man nicht sieht. Daher verlangt Version 4.0.1 eine Bestandsaufnahme der verwendeten Verschlüsselungssuiten und Protokolle, die in festgelegten Abständen von mindestens einmal alle 12 Monate überprüft werden muss. Durch diese Überprüfung werden veraltete oder anfällige Algorithmen erkannt, bevor dies einem Angreifer oder einem Prüfer gelingt.

Dies ist eine weitere der am häufigsten genannten Lücken für das Jahr 2026. Ein kryptografisches Inventar lässt sich zwar leicht beschreiben, ist aber manuell nur sehr schwer zu pflegen, insbesondere in hybriden und Multi-Cloud-Umgebungen.

Sicherung von Zahlungsseiten und Skripten (Anforderungen 6.4.3 und 11.6.1)

Skripte, die auf Zahlungsseiten ausgeführt werden, müssen autorisiert, erfasst und auf Manipulationen überwacht werden. Damit wird das Konzept der Code-Integrität auf den Browser ausgeweitet, wo Skimming-Angriffe zunehmend auf den Bezahlvorgang abzielen.

Die praktische Lösung besteht aus signierten und autorisierten Skripten in Verbindung mit einer Manipulationserkennung. Dabei werden die Abläufe, die in unmittelbarer Nähe zu den Karteninhaberdaten stattfinden, einer strengen Code-Signierung unterzogen.

Was Prüfer und Gutachter tatsächlich fragen

Die Prüfungsvorbereitungsfragen hinter den Versionen 4.0 und 4.0.1 lassen sich in eine Checkliste umwandeln, anhand derer Sie bereits heute eine Selbstbewertung vornehmen können. Gehen Sie jeden dieser Punkte durch, bevor ein Prüfer dies tut:

• Wurden alle 51 Anforderungen mit zukünftigem Datum abgeschlossen und nachgewiesen, und nicht nur geplant?
• Ist die Schlüsselverwaltung durchgängig dokumentiert, wobei die Vier-Augen-Prinzip und die Aufteilung des Wissens gewährleistet sind?
• Deckt MFA alle Zugangswege zum CDE ab, einschließlich Fernzugriff und Anbieterzugriff?
• Gibt es ein aktuelles kryptografisches Verzeichnis von Verschlüsselungssuiten, Protokollen, Schlüsseln und Zertifikaten?
• Können Sie die Bescheinigungskette der Dienstleister für jeden betroffenen Anbieter vorlegen?
• Wurden Segmentierung und Umfang validiert, sodass die CDE-Abgrenzung Bestand hat?
• Liegt für jede unternehmensspezifisch definierte Häufigkeit und jede maßgeschneiderte Kontrollmaßnahme eine dokumentierte, aktuelle Zielrisikoanalyse vor?

Wenn bei einer Antwort Unsicherheit besteht, sollte man sich zunächst darauf konzentrieren. Prüfer beurteilen anhand von Belegen; daher haben Unterlagen, die tatsächliche, funktionierende Kontrollmaßnahmen widerspiegeln, weitaus mehr Gewicht als bloße Absichtserklärungen.

Kartendaten zukunftssicher machen: Der Post-Quanten-Horizont

Das kryptografische Inventar, das Sie für PCI DSS erstellen, erfüllt einen doppelten Zweck. Die gleiche Transparenz, die gemäß den Anforderungen 4.2.1.1 und 12.3.3 erforderlich ist, bildet die Grundlage für die Identifizierung quantenanfälliger Algorithmen in Ihrer gesamten Umgebung.

Der Zeitplan rückt schneller näher, als es den Anschein hat. Im Jahr 2024 hat das NIST die ersten postquantenkryptografischen Standards (FIPS 203, 204, 205, August 2024) fertiggestellt und einen Zeitplan für die Umstellung veröffentlicht, wonach weit verbreitete Algorithmen für öffentliche Schlüssel wie RSA und die Kryptografie auf elliptischen Kurven bis 2030 auslaufen sollen, wobei ein vollständiges Verbot für 2035 angestrebt wird. Zahlungsdaten mit langer Aufbewahrungsdauer sind Angriffen vom Typ „Harvest-Now, Decrypt-Later“ ausgesetzt, bei denen ein Angreifer heute verschlüsselten Datenverkehr abfängt, um ihn zu entschlüsseln, sobald ein Quantencomputer verfügbar ist.

Damit sind langlebige Transaktionsdaten bereits heute ein Thema und nicht erst in der Zukunft. Ein gut gepflegtes kryptografisches Inventar wird zur kryptografischen Stückliste (CBOM), die den Rahmen für eine geordnete Umstellung auf Post-Quanten-Kryptografie bildet.

Wie „ Keyfactor “ die Kryptografie und das Schlüsselmanagement gemäß PCI DSS unterstützt

Keyfactor entspricht direkt jedem PCI-DSS-Kontrollbereich, sodass Sie von der Anforderung zur Funktion übergehen können, ohne einzelne Tools miteinander verknüpfen zu müssen.

• Keyfactor AgileSec: Ermittelt und katalogisiert Verschlüsselungssuiten, Protokolle, Schlüssel und Algorithmen, um die Anforderungen gemäß Anforderung 12.3.3 zu erfüllen und kryptografische Risiken zu bewerten.
• EJBCA: stellt die Zertifikate aus, die der Verschlüsselung gespeicherter Daten und der Übertragungsverschlüsselung sowie der zertifikatsbasierten MFA für das CDE zugrunde liegen.
• SignServer: signiert und schützt die Skripte auf Zahlungsseiten und unterstützt dabei Integritätsprüfungen für Abläufe, die mit Karteninhaberdaten in Zusammenhang stehen.
• Keyfactor Command: Bietet ein dokumentiertes, automatisiertes Management des Lebenszyklus von Schlüsseln und Zertifikaten – von der Erstellung bis zur Außerbetriebnahme – mit dem von Prüfern erwarteten Prüfpfad.

Hinter diesen Produkten fungiert die „ Keyfactor “ Trust Control Plane als zentrale Datenquelle für alle kryptografischen Assets und Maschinenidentitäten. Sie läuft in einem kontinuierlichen Kreislauf, der Schlüssel und Zertifikate in den Bereichen Kernbankwesen, Zahlungsverkehr und Open-Banking-Infrastruktur überwacht, analysiert, bereitstellt, koordiniert und verwaltet, sodass die von jedem Rahmenwerk geforderten Nachweise aus einer Hand stammen.

Fazit: ein Programm, kein Projekt

Die PCI-DSS-Kryptografie ist mittlerweile eine operative Funktion und kein einmaliger Sprint zur Behebung von Mängeln mehr. Die 51 zukunftsorientierten Anforderungen sind verbindlich, und die ihnen zugrunde liegenden Kontrollmaßnahmen – Verschlüsselung, Schlüsselverwaltung, MFA und kryptografisches Inventar – behalten ihren Wert nur, wenn sie kontinuierlich umgesetzt werden.

Die gute Nachricht ist, dass dieselbe Grundlage auch die nächste Anforderung erfüllt. Ein aktuelles Kryptografie-Inventar, das die Anforderungen von Version 4.0.1 erfüllt, ist zugleich der Ausgangspunkt für Ihre Umstellung auf postquantensichere Lösungen. Einmal eingerichtet und kontinuierlich überwacht, wird jede neue Vorschrift zu einem einfachen Update statt zu einer Notfallsituation.

Möchten Sie erfahren, wie es um Ihre Karteninhaberdaten-Umgebung steht? Fordern Sie eine Demo an und entdecken Sie, wie „ Keyfactor “ Ihnen dabei hilft, die für die PCI-DSS-Compliance erforderliche Kryptografie zu erfassen, zu automatisieren und zu verwalten.

Haben Sie Fragen zur Kryptografie im Rahmen des PCI DSS? Wir haben die Antworten.

What does PCI DSS require for protecting stored cardholder data?
Stored cardholder data must be rendered unreadable using strong cryptography, tokenization, or truncation. PCI DSS expects file, column, or field level encryption with independent key management layered on top of full disk encryption, not full disk encryption alone. That separation keeps a compromised host from automatically exposing the data it holds.

When did the future-dated PCI DSS v4.0.1 requirements become mandatory?
They became mandatory on March 31, 2025. The 51 requirements that were treated as best practice under v4.0 are now scored in every assessment, so the transition window has closed.

What does PCI DSS Requirement 12.3.3 cover?
Requirement 12.3.3 calls for a documented inventory of the cryptographic cipher suites and protocols in use. That inventory must be reviewed on a defined cadence of at least once every 12 months to identify deprecated or weakening algorithms before they become a vulnerability.

Does PCI DSS require multi-factor authentication for cardholder data?
Yes. PCI DSS v4.0.1 mandates multi-factor authentication for all access to the cardholder data environment, including remote and third-party vendor access. Certificate-based, phishing-resistant methods provide the strongest assurance.

What encryption is required for cardholder data in transit?
Cardholder data sent across open, public networks must use strong cryptography, meaning TLS 1.2 or higher. Primary account numbers must never be sent unprotected through end-user messaging technologies such as email or chat.

What key management controls does PCI DSS expect?
PCI DSS requires documented procedures covering key generation, distribution, storage, rotation, and retirement. Manual key operations must use dual control and split knowledge so no single person can compromise a key.

Is PCI DSS a law?
No. PCI DSS is a contractual standard rather than a statute, but non-compliance carries real commercial consequences, including fines from acquiring banks, higher per-transaction fees, and potential loss of the ability to accept card payments.

How should PCI DSS teams prepare for post-quantum cryptography?
Start with the cryptographic inventory that Requirements 4.2.1.1 and 12.3.3 already demand, then assess those algorithms against NIST’s published deprecation timelines. Because long-lived transaction data can be harvested now and decrypted later, planning the migration early protects data whose sensitivity outlasts today’s algorithms.