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.
Was schreibt der PCI DSS zum Schutz gespeicherter Karteninhaberdaten vor?
Gespeicherte Karteninhaberdaten müssen mithilfe starker Kryptografie, Tokenisierung oder Kürzung unlesbar gemacht werden. Der PCI DSSverlangt eine Verschlüsselung auf Datei-, Spalten- oder Feldebene mit unabhängiger Schlüsselverwaltung, die zusätzlich zur vollständigen Festplattenverschlüsselung erfolgt – nicht nur die vollständige Festplattenverschlüsselung allein. Diese Trennung verhindert, dass ein kompromittierter Host die darauf gespeicherten Daten automatisch offenlegt.
Wann sind die für die Zukunft geltenden Anforderungen der PCI DSS Version 4.0.1 verbindlich geworden?
Sie sind am 31. März 2025 verbindlich geworden. Die 51 Anforderungen, die in Version 4.0 als Best Practice galten, werden nun bei jeder Bewertung bewertet, sodass die Übergangsfrist abgelaufen ist.
Was umfasst die PCI-DSS-Anforderung 12.3.3?
Anforderung 12.3.3 schreibt ein dokumentiertes Verzeichnis der verwendeten kryptografischen Verschlüsselungssuiten und Protokolle vor. Dieses Verzeichnis muss in festgelegten Abständen von mindestens einmal alle 12 Monate überprüft werden, um veraltete oder sicherheitsgefährdende Algorithmen zu identifizieren, bevor sie zu einer Sicherheitslücke werden.
Schreibt PCI DSS eine Multi-Faktor-Authentifizierung für Karteninhaberdaten vor?
Ja. PCI DSS v4.0.1 schreibt eine Multi-Faktor-Authentifizierung für jeden Zugriff auf die Karteninhaberdatenumgebung vor, einschließlich des Fernzugriffs und des Zugriffs durch Drittanbieter. Zertifikatsbasierte, phishingresistente Methoden bieten die höchste Sicherheit.
Welche Verschlüsselung ist für Kartendaten während der Übertragung erforderlich?
Kartendaten, die über offene, öffentliche Netzwerke übertragen werden, müssen mit starker Kryptografie verschlüsselt werden, d. h. gemäß dem „ TLS “ (PCI DSS) Version 1.2 oder höher. Primäre Kontonummern dürfen niemals ungeschützt über Kommunikationsdienste für Endnutzer wie E-Mail oder Chat versendet werden.
Welche Kontrollmaßnahmen für die Schlüsselverwaltung sieht der PCI DSS vor?
Der PCI DSS verlangt dokumentierte Verfahren für die Schlüsselgenerierung, -verteilung, -speicherung, -rotation und -ausmusterung. Bei manuellen Schlüsselvorgängen müssen das Vier-Augen-Prinzip und das Prinzip der geteilten Kenntnis angewendet werden, damit keine einzelne Person einen Schlüssel kompromittieren kann.
Ist PCI DSS ein Gesetz?
Nein. PCI DSS ist eher ein vertraglicher Standard als ein Gesetz, doch die Nichteinhaltung hat konkrete wirtschaftliche Folgen, darunter Geldstrafen seitens der akquirierenden Banken, höhere Gebühren pro Transaktion und den möglichen Verlust der Möglichkeit, Kartenzahlungen anzunehmen.
Wie sollten sich PCI-DSS-Teams auf die postquantum-Kryptografie vorbereiten?
Beginnen Sie mit der Bestandsaufnahme der Kryptografie, die bereits in den Anforderungen 4.2.1.1 und 12.3.3 vorgeschrieben ist, und prüfen Sie diese Algorithmen anschließend anhand der vom NIST veröffentlichten Zeitpläne für die Auslaufphase. Da langlebige Transaktionsdaten bereits heute erfasst und später entschlüsselt werden können, schützt eine frühzeitige Planung der Migration Daten, deren Vertraulichkeit die Lebensdauer der heutigen Algorithmen übersteigt.
