CRA für Payment & POS-Terminals

Wenn Kryptografie im Terminal auf horizontale Cybersicherheitsanforderungen trifft

Ein Bezahlterminal ist dicht reguliert: Es hält kryptografisches Schlüsselmaterial, verarbeitet PIN-Eingaben im Klartext für Sekundenbruchteile, spricht über Mobilfunk, Ethernet oder Bluetooth mit Acquirern und Kassensystemen und schützt das Schlüsselmaterial mit einem Secure Element auf der Platine. Die Konnektivität macht ein POS-Terminal, ein PIN-Pad oder eine SoftPOS-App aus Sicht des Cyber Resilience Act (Verordnung (EU) 2024/2847) zu einem Produkt mit digitalen Elementen (PDE). Der CRA gilt damit zusätzlich zu den etablierten Payment-Sicherheitsregimen.

Security ist in dieser Branche kein Fremdwort; Payment ist seit Langem von Zertifizierungslogik geprägt. Neu ist die zweite, horizontale Regulierungsebene, die sich quer über eine bereits fein austarierte PCI-Welt legt. Wer ein Terminal zertifiziert, kennt PCI PTS als Geräte-Härtungsregime bis in die Tamper-Response hinein. Der CRA fragt aber nach Dingen, die PCI so nicht adressiert: einer maschinenlesbaren Software-Stückliste, einer Coordinated-Vulnerability-Disclosure-Policy, einer Melde-Kaskade über die einheitliche Meldeplattform und einer über den gesamten Unterstützungszeitraum durchgehaltenen Update-Fähigkeit. Das ist eine eigene Achse neben PCI.

Hinzu kommt die Kollisionsgefahr im Change-Management: In der Payment-Firmware berührt fast jede Komponentenaktualisierung den Zertifizierungsstatus. Ein CRA-getriebenes Sicherheitsupdate darf die PCI-PTS-Approval nicht brechen - und umgekehrt darf ein PCI-Change nicht dazu führen, dass eine bekannte Schwachstelle CRA-widrig ausgesessen wird. Ziel ist, beide Regime so aufeinander abzustimmen, dass Nachweise nicht doppelt entstehen. (Dieser Text ordnet schematisch ein und ist keine Rechtsberatung.)

Typische PDE-Produkte und ihre wahrscheinliche Anhang-Klasse

Der CRA staffelt Produkte in drei Bänder: „Standard" (Selbstbewertung nach Modul A), Anhang-III-„wichtige" Produkte (Klasse I und II) und Anhang-IV-„kritische" Produkte. Für die Einstufung zählt die Kernfunktion des Produkts, das in Verkehr gebracht wird (Art. 7 Abs. 1, Art. 8 Abs. 1); ein eingebautes Bauteil mit eigener Klasse stuft das Gerät nicht hoch. Die technischen Beschreibungen der wichtigen und kritischen Kategorien konkretisiert die Durchführungsverordnung (EU) 2025/2392. Die folgende Tabelle ist eine schematische Orientierung, keine verbindliche Einzelfallzuordnung.

Die praktische Konsequenz: Ein Terminalhersteller sollte von Anhang IV ausgehen und die Prüfung mit der Beschreibung der Durchführungsverordnung abgleichen. Ein zugekauftes Secure Element stuft das Terminal nicht hoch und nicht herunter; seine eigene Konformität verantwortet der Hersteller des Elements.

Branchennormen und die Abgrenzung zu den Nachbarregimen

Payment lebt normativ von den Sektor-Standards: PCI PTS (POI) für die Geräte-Härtung, PCI DSS für den Betrieb der Kartendatenumgebung, dazu die EMVCo-Spezifikationen und die Schemes der Kartennetze. Diese bleiben eigenständig. Der CRA ersetzt keines davon; er legt eine horizontale Ebene aus Security-by-Design, SBOM, Vulnerability-Handling und Meldepflicht darüber. Vorhandene Nachweise lassen sich dort weiterverwenden, wo sie Anforderungen aus Anhang I inhaltlich abdecken.

• PCI PTS / PCI DSS: angrenzende, nicht-CRA-Regime. Sie decken Geräte-Tamper und Betrieb ab, aber nicht die CRA-spezifische SBOM- und Meldelogik.
• RED-Delegierte-Verordnung 2022/30: für funkfähige Terminals relevant, die über das Internet kommunizieren können (Mobilfunk/WLAN); ermöglichen sie Geldtransfers, gilt zusätzlich Art. 3.3 f; bis zur Aufhebung der VO zum 11.12.2027 ist die Abgrenzung bzw. Überlappung zwischen RED-DA und CRA sauber zu führen.
• NIS2: betrifft wesentliche und wichtige Einrichtungen, nicht den Terminal als Produkt. Hersteller elektronischer Erzeugnisse oder elektrischer Ausrüstungen können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. CRA adressiert das Produkt, NIS2 die Organisation - getrennte Rechtsakte, nicht vermischen.
• DORA: Finanzsektor-Resilienz für Finanzunternehmen; für Kreditinstitute und andere Finanzunternehmen gilt vorrangig DORA. Ein reiner Hardware-Hersteller fällt nicht automatisch darunter, kann aber als IKT-Drittdienstleister berührt sein.
• AI Act: gilt zusätzlich, sobald ein KI-System verbaut ist (z. B. Betrugserkennung); der Umfang der Pflichten hängt von der Risikostufe ab.

SBOM- und Lieferketten-Realität im Payment-Stack

Der typische Software-Stack eines modernen Terminals ist tiefer, als das gehärtete Äußere vermuten lässt: ein Embedded-Linux oder RTOS, ein Krypto-Provider (etwa OpenSSL/mbedTLS-Derivate), TLS-Stacks für die Acquirer-Verbindung, EMV-Kernel, Treiber für NFC-Controller und Secure Element, dazu Update- und Attestation-Agenten. Genau hier sitzen die Lieferketten-Risiken: End-of-Life-Kryptobibliotheken, nicht mehr gepflegte OSS-Komponenten und transitive Abhängigkeiten, die im PCI-Blickwinkel nie explizit dokumentiert wurden.

Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Eine allgemeine Veröffentlichungspflicht besteht nicht; die SBOM ist Nachweismittel gegenüber Behörden und Konformitätsbewertung. Für Payment heißt das konkret: Die SBOM-Pflege sollte mit dem PCI-PTS-Change-Management abgestimmt sein, damit jede Aktualisierung einer Kryptobibliothek sowohl den CRA-Update-Nachweis als auch den Zertifizierungsstatus konsistent hält. Eine SBOM, die den Krypto-Stack (Cipher-Suites, TLS-Version, EOL-Status) sauber ausweist, wird so zum operativen Frühwarnsystem für EOL-Risiken.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt

Seit dem 11.09.2026 gilt die Melde- und Berichtspflicht nach Artikel 14, die erste harte Herstellerpflicht des CRA. Ein Terminalhersteller braucht dafür eine verlässliche PSIRT-/CVD-Struktur. Die Kaskade ist präzise gestaffelt und darf nicht verkürzt werden:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
• 1 Monat - Abschlussbericht bei einem schwerwiegenden Sicherheitsvorfall, nach der 72-Stunden-Meldung.

Gemeldet wird über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. Der interne Meldeprozess sollte unabhängig davon vorgehalten werden. Für Payment ist wichtig, dass dieser CRA-Meldeweg mit den bestehenden PCI-Incident-Pflichten und den Meldeketten gegenüber den Kartennetzen kompatibel geführt wird - ein Vorfall an einem Terminal löst potenziell beides aus.

Fristen: was zuerst zählt

Zwei Daten strukturieren die Vorbereitung. Seit dem 11.09.2026 greift die Meldepflicht (Art. 14); sie kam zuerst und verlangt einen funktionierenden PSIRT-/CVD-Prozess mit Anbindung an die einheitliche Meldeplattform, unabhängig vom Reifegrad der übrigen Produktanforderungen. Am 11.12.2027 folgt die volle Anwendbarkeit aller Produktanforderungen inklusive CE-Kennzeichnung, EU-Konformitätserklärung, vollständiger technischer Dokumentation und ggf. Einbindung einer notifizierten Stelle. Praktisch heißt das: Zuerst muss die Reaktionsfähigkeit stehen (Meldeprozess), dann die vollständige Konformität des Produkts. Wer die Reihenfolge vertauscht, hat seit September 2026 eine Meldepflicht ohne den Apparat, sie zu erfüllen.

Ein durchgespieltes Szenario

Ein mittelständischer Hersteller unattended Kartenterminals - Automaten-Payment, Ladesäulen, Parkscheinautomaten - liefert Geräte mit Secure Element und Mobilfunk-Backhaul in die EU. Betroffenheit: Das Terminal ist als physisches Zahlungsterminal mit Sicherheitsbox voraussichtlich ein kritisches Produkt nach Anhang IV; das zugekaufte Secure Element ändert daran nichts, und das Mobilfunkmodul zieht die RED-DA-Abgrenzung nach sich. Solange kein delegierter Rechtsakt ein europäisches Schema vorschreibt, plant der Hersteller daher früh eine notifizierte Stelle ein (Modul B+C oder H) oder ein europäisches Schema mindestens „mittel“.

Sein Fahrplan: Er baut aus dem CI-Build eine CycloneDX-1.6-SBOM, die OpenSSL-Derivat, TLS-Stack und EMV-Kernel mit Versions- und EOL-Status ausweist, und koppelt jeden Krypto-Update an sein PCI-PTS-Change-Management. Er veröffentlicht eine CVD-Policy mit security@-Kontakt und richtet ein PSIRT mit Playbook für Frühwarnung (unverzüglich, spätestens nach 24 Stunden) und Meldung (spätestens nach 72 Stunden) samt Zugang zur einheitlichen Meldeplattform ein - abgestimmt mit den bestehenden Kartennetz-Meldeketten. Der Meldeprozess muss seit dem 11.09.2026 stehen; bis 11.12.2027 folgen die vollständige technische Doku, Risikobewertung, Konformitätsbewertung und CE/EU-Konformitätserklärung. Als eine EOL-gewordene Kryptobibliothek auffällt, greift die SBOM als Frühwarnung - das Update läuft abgestimmt durch beide Regime.

Was Blackfort Technology für Sie tut

Blackfort Technology begleitet Payment- und POS-Hersteller sowie Importeure entlang genau dieser Achse - mit dem Ziel, CRA-Nachweise und bestehende Payment-Nachweise nicht doppelt zu führen:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, welche Ihrer Terminals, PIN-Pads und SoftPOS-Varianten PDE sind, welche Anhang-Klasse plausibel ist und wo zusätzlich RED-DA greift - als strukturierte Einordnung, nicht als Rechtsberatung.
• SBOM-Setup: maschinenlesbare SBOM, etwa in CycloneDX oder SPDX, aus Ihrer Build-Pipeline, abgestimmt mit Ihrem bestehenden Change-Management und mit EOL-Monitoring des Krypto-Stacks.
• PSIRT / CVD: Aufbau einer CVD-Policy und eines Meldeprozesses entlang der korrekten Art.-14-Kaskade (Frühwarnung, Meldung, Abschlussbericht nach 14 Tagen bzw. 1 Monat) inklusive Anbindung an die einheitliche Meldeplattform.
• Risikobewertung und Threat-Modeling: dokumentationsfähige Risikoanalyse nach Art. 13 und Anhang I für die konkrete Terminal-Architektur.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13), als Grundlage für die Konformitätsbewertung.

Ein guter erster Schritt ist der Betroffenheits-Check. Kleinere Hersteller finden im KMU-Bereich einen pragmatischen Einstieg, die Grundlagen im CRA-Überblick. Für ein konkretes Gespräch: Kontakt aufnehmen.