CRA für Payment & POS-Terminals

Wenn Kryptografie im Terminal auf horizontale Produkthaftung trifft

Ein Bezahlterminal ist das vielleicht am dichtesten regulierte Stück Consumer-nahe Hardware, das es gibt: 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 trägt in aller Regel ein Secure Element auf der Platine. Genau diese Eigenschaften — Konnektivität und eine sicherheitskritische Funktion — machen 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 greift damit zusätzlich zu den etablierten Payment-Sicherheitsregimen, nicht statt ihrer.

Der reale Schmerz dieser Branche ist nicht, dass Security ein Fremdwort wäre — im Gegenteil, kaum eine Sparte lebt so tief in Zertifizierungslogik wie Payment. Der Schmerz 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 öffentlich zugänglichen Coordinated-Vulnerability-Disclosure-Policy, einer 24/72-Stunden-Meldekaskade an ENISA und einer über die gesamte Produktlebensdauer durchgehaltenen Update-Fähigkeit. Das ist kein „mehr vom Gleichen", sondern eine andere Achse.

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. Die Kunst besteht darin, beide Regime zu verzahnen statt sie parallel und doppelt zu bedienen. (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" (die Mehrheit, Selbstbewertung nach Modul A), Anhang-III-„wichtige" Produkte (Klasse I und II) und Anhang-IV-„kritische" Produkte. Für die Payment-Branche ist die Einordnung selten trivial, weil dasselbe Gehäuse mehrere sicherheitsrelevante Bausteine vereint. 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 maßgebliche Funktion des konkreten Produkts entscheidet.

Die praktische Konsequenz: Ein Terminalhersteller wird selten „nur Standard" sein. Sobald ein Secure Element als eigenständige Komponente betrachtet wird, ist Anhang IV und damit zwingend eine notifizierte Stelle im Spiel — und die Klasse-II-Schwelle über den manipulationssicheren Mikrocontroller liegt näher, als viele erwarten.

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. Wo künftig harmonisierte Normen zum CRA vorliegen, ist die Erwartung, dass sich vorhandene PCI-/EMV-Nachweise weitgehend darauf mappen lassen — Doppelnachweise sind zu harmonisieren, nicht doppelt zu erbringen.

• PCI PTS / PCI DSS: angrenzende, nicht-CRA-Regime. Sie decken Geräte-Tamper und Betrieb ab, aber nicht die CRA-spezifische SBOM- und ENISA-Meldelogik.
• RED-Delegierte-Verordnung 2022/30: für funkfähige Terminals (Mobilfunk/Bluetooth/WLAN) relevant; hier ist die Abgrenzung bzw. Überlappung zwischen RED-DA und CRA sauber zu führen.
• NIS2: betrifft Betreiber (z. B. Acquirer, Zahlungsdienstleister), nicht den Terminalhersteller als solchen. CRA adressiert das Produkt, NIS2 die Organisation — getrennte Rechtsakte, nicht vermischen.
• DORA: Finanzsektor-Resilienz für Finanzunternehmen; ein reiner Hardware-Hersteller fällt nicht automatisch darunter, kann aber als IKT-Drittdienstleister berührt sein.
• AI Act: nur relevant, wenn KI-Komponenten (z. B. Betrugserkennung) verbaut werden; sonst nicht einschlägig.

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 (häufig 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 maschinenlesbare SBOM als Teil der technischen Dokumentation — in CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 (so die Ausrichtung der BSI TR-03183-2 v2.1.0), mindestens auf Ebene der Top-Level-Abhängigkeiten. 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 muss mit dem PCI-PTS-Change-Management verzahnt werden, 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 vom Compliance-Artefakt zum operativen Frühwarnsystem für EOL-Risiken.

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

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

• 24 Stunden — Frühwarnung (early warning) ab Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schweren Sicherheitsvorfalls.
• 72 Stunden — vollständige Meldung, inklusive Korrektur- bzw. Minderungsmaßnahmen.
• 14 Tage — Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet nach Verfügbarkeit einer Korrekturmaßnahme.
• 1 Monat — Abschlussbericht bei einem schweren Sicherheitsvorfall, nach der 72-Stunden-Meldung.

Gemeldet wird über die ENISA Single Reporting Platform (SRP), die als Einmalmeldung an das zuständige CSIRT der Hauptniederlassung und ENISA weiterleitet. Die Plattform wird zum 11.09.2026 bereitgestellt; Mitte 2026 ist sie erfahrungsgemäß noch nicht voll operativ, weshalb ein Übergangsprozess vorzuhalten ist. Für Payment ist entscheidend, 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. Am 11.09.2026 greift die Meldepflicht (Art. 14) — sie kommt zuerst und verlangt eine funktionierende PSIRT-/CVD- und SRP-Anbindung, 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, riskiert 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 PDE mit Kryptofunktion mindestens Anhang III Klasse I; das verbaute Secure Element als Komponente berührt die kritische Anhang-IV-Kategorie, und das Mobilfunkmodul zieht die RED-DA-Abgrenzung nach sich. Der Hersteller stuft daher früh eine notifizierte Stelle ein, statt auf reine Selbstbewertung zu setzen.

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 24/72-Stunden-Playbook und SRP-Zugang ein — abgestimmt mit den bestehenden Kartennetz-Meldeketten. Bis 11.09.2026 steht der Meldeprozess; bis 11.12.2027 die vollständige technische Doku, Risikobewertung und CE/EU-Konformitätserklärung. Als eine EOL-gewordene Kryptobibliothek auffällt, greift die SBOM als Frühwarnung — das Update läuft koordiniert durch beide Regime, ohne die Zertifizierung zu brechen.

Was Blackfort Technology für Sie tut

Blackfort Technology UG (haftungsbeschränkt) begleitet Payment- und POS-Hersteller sowie Importeure entlang genau dieser Achse — mit dem Fokus, CRA und PCI/EMV zu verzahnen statt zu verdoppeln:

• Betroffenheits- und Scope-Analyse: Welche Ihrer Terminals, PIN-Pads und SoftPOS-Varianten sind PDE, welche Anhang-Klasse ist plausibel, wo greift zusätzlich RED-DA — als strukturierte Einordnung, nicht als Rechtsberatung.
• SBOM-Setup: maschinenlesbare SBOM (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) aus Ihrer Build-Pipeline, verzahnt mit dem PCI-Change-Management und mit EOL-Monitoring des Krypto-Stacks.
• PSIRT / CVD: Aufbau einer CVD-Policy und eines Meldeprozesses entlang der korrekten Art.-14-Kaskade (24 h / 72 h / 14 Tage bzw. 1 Monat) inklusive SRP-Anbindung und Abstimmung mit PCI-/Scheme-Meldeketten.
• Risikobewertung und Threat-Modeling: dokumentationsfähige Risikoanalyse nach Art. 13 und Anhang I für die konkrete Terminal-Architektur.
• Technische Dokumentation: Aufbau der prüffähigen Doku (10 Jahre aufzubewahren) als Grundlage für Selbstbewertung oder notifizierte Stelle.

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.