CRA for payment & POS terminals

Where terminal cryptography meets horizontal product liability

A payment terminal may be the most densely regulated piece of consumer-facing hardware in existence: it holds cryptographic key material, processes PIN entry in clear for fractions of a second, talks to acquirers and POS systems over cellular, Ethernet or Bluetooth, and almost always carries a secure element on its board. Precisely these properties — connectivity plus a security-critical function — turn a POS terminal, a PIN pad or a SoftPOS app into a product with digital elements (PDE) under the Cyber Resilience Act (Regulation (EU) 2024/2847). The CRA therefore applies on top of the established payment security regimes, not instead of them.

The real pain in this sector is not that security is unfamiliar — quite the opposite, few segments live as deeply inside certification logic as payment. The pain is the second, horizontal regulatory layer laid across an already finely balanced PCI world. Whoever certifies a terminal knows PCI PTS as a device-hardening regime down to tamper response. The CRA, however, asks for things PCI does not address in this form: a machine-readable software bill of materials, a publicly reachable coordinated vulnerability disclosure policy, a 24/72-hour reporting cascade to ENISA, and update capability sustained across the entire product lifetime. That is not "more of the same" — it is a different axis.

Add the collision risk in change management: in payment firmware, almost every component update touches certification status. A CRA-driven security update must not break the PCI PTS approval — and conversely, a PCI change must not lead to a known vulnerability being sat out in breach of the CRA. The art lies in interlocking both regimes rather than serving them twice in parallel. (This text classifies schematically and is not legal advice.)

Typical PDE products and their likely Annex class

The CRA tiers products into three bands: "default" (the majority, self-assessment under Module A), Annex III "important" products (class I and II), and Annex IV "critical" products. For payment the classification is rarely trivial, because a single enclosure combines several security-relevant building blocks. The technical descriptions of the important and critical categories are specified by Implementing Regulation (EU) 2025/2392. The table below is schematic orientation, not a binding case ruling — the product's governing function decides.

The practical consequence: a terminal maker is rarely "default only". Once a secure element is viewed as a standalone component, Annex IV — and thus a mandatory notified body — is in play, and the class II threshold via the tamper-resistant microcontroller sits closer than many expect.

Sector standards and the boundary to neighbouring regimes

Payment lives normatively on its sector standards: PCI PTS (POI) for device hardening, PCI DSS for operating the cardholder data environment, plus the EMVCo specifications and the card schemes. These remain separate. The CRA replaces none of them; it adds a horizontal layer of security-by-design, SBOM, vulnerability handling and reporting on top. Where harmonised standards for the CRA emerge, the expectation is that existing PCI/EMV evidence largely maps onto them — duplicate proofs are to be harmonised, not produced twice.

• PCI PTS / PCI DSS: adjacent, non-CRA regimes. They cover device tamper and operations but not the CRA-specific SBOM and ENISA reporting logic.
• RED delegated Regulation 2022/30: relevant for radio-capable terminals (cellular/Bluetooth/Wi-Fi); the boundary/overlap between RED-DA and CRA must be drawn cleanly.
• NIS2: concerns operators (e.g. acquirers, payment service providers), not the terminal maker as such. CRA addresses the product, NIS2 the organisation — separate legal acts, do not conflate.
• DORA: financial-sector resilience for financial entities; a pure hardware maker is not automatically in scope but may be touched as an ICT third-party provider.
• AI Act: only relevant if AI components (e.g. fraud detection) are built in; otherwise not applicable.

SBOM and supply-chain reality in the payment stack

The typical software stack of a modern terminal is deeper than the hardened exterior suggests: an embedded Linux or RTOS, a crypto provider (often OpenSSL/mbedTLS derivatives), TLS stacks for the acquirer link, an EMV kernel, drivers for the NFC controller and secure element, plus update and attestation agents. This is exactly where the supply-chain risk sits: end-of-life crypto libraries, unmaintained OSS components, and transitive dependencies that were never explicitly documented from a PCI viewpoint.

The CRA requires a machine-readable SBOM as part of the technical documentation — in CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 (per the direction of BSI TR-03183-2 v2.1.0), at least at the level of top-level dependencies. There is no general obligation to publish it; the SBOM serves as evidence toward authorities and conformity assessment. For payment this concretely means: the SBOM must interlock with PCI PTS change management, so that every update of a crypto library keeps both the CRA update evidence and the certification status consistent. An SBOM that cleanly discloses the crypto stack (cipher suites, TLS version, EOL status) thus turns from a compliance artefact into an operational early-warning system for EOL risks.

Reporting capability and PSIRT: the Art. 14 cascade, correct

From 11 September 2026 the reporting obligation under Article 14 applies — the CRA's first hard manufacturer duty. A terminal maker needs a robust PSIRT/CVD structure for it. The cascade is precisely staggered and must not be shortened:

• 24 hours — early warning from becoming aware of an actively exploited vulnerability or a severe security incident.
• 72 hours — full notification, including corrective or mitigating measures.
• 14 days — final report for an actively exploited vulnerability, counted after a corrective measure becomes available.
• 1 month — final report for a severe security incident, after the 72-hour notification.

Reporting goes through the ENISA Single Reporting Platform (SRP), which forwards as a single submission to the competent CSIRT of the main establishment and to ENISA. The platform is to be provided by 11 September 2026; in mid-2026 it is typically not yet fully operational, so a transitional process should be kept ready. For payment it is decisive that this CRA reporting path is run compatibly with existing PCI incident duties and the reporting chains toward the card schemes — an incident on a terminal potentially triggers both.

Deadlines: what counts first

Two dates structure the preparation. On 11 September 2026 the reporting obligation (Art. 14) takes effect — it comes first and requires a working PSIRT/CVD and SRP connection, independent of the maturity of the remaining product requirements. On 11 December 2027 the full applicability of all product requirements follows, including CE marking, EU declaration of conformity, complete technical documentation and, where relevant, involvement of a notified body. In practice: first the responsiveness must stand (reporting process), then the full product conformity. Reversing the order risks a reporting duty in 2026 without the apparatus to fulfil it.

A worked scenario

A mid-sized maker of unattended card terminals — automated payment, charging points, parking machines — ships devices with a secure element and cellular backhaul into the EU. Exposure: the terminal, as a PDE with a crypto function, is at least Annex III class I; the embedded secure element as a component touches the critical Annex IV category, and the cellular module pulls in the RED-DA boundary. The maker therefore classes in a notified body early rather than relying on pure self-assessment.

Its roadmap: from the CI build it produces a CycloneDX 1.6 SBOM disclosing the OpenSSL derivative, TLS stack and EMV kernel with version and EOL status, and couples every crypto update to its PCI PTS change management. It publishes a CVD policy with a security@ contact and sets up a PSIRT with a 24/72-hour playbook and SRP access — aligned with the existing card-scheme reporting chains. By 11 September 2026 the reporting process stands; by 11 December 2027 the full technical documentation, risk assessment and CE/EU declaration of conformity. When a crypto library goes EOL, the SBOM acts as early warning — the update runs coordinated through both regimes without breaking certification.

What Blackfort Technology does for you

Blackfort Technology UG (haftungsbeschränkt) supports payment and POS manufacturers and importers along exactly this axis — with a focus on interlocking CRA with PCI/EMV rather than duplicating them:

• Exposure and scope analysis: which of your terminals, PIN pads and SoftPOS variants are PDE, which Annex class is plausible, where RED-DA additionally applies — as structured classification, not legal advice.
• SBOM setup: machine-readable SBOM (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) from your build pipeline, interlocked with PCI change management and with EOL monitoring of the crypto stack.
• PSIRT / CVD: building a CVD policy and reporting process along the correct Art. 14 cascade (24 h / 72 h / 14 days or 1 month) including SRP connection and alignment with PCI/scheme reporting chains.
• Risk assessment and threat modeling: documentable risk analysis under Art. 13 and Annex I for the specific terminal architecture.
• Technical documentation: building the audit-ready documentation (to be retained for 10 years) as a basis for self-assessment or a notified body.

A good first step is the exposure check. Smaller makers find a pragmatic entry in the SME section, the fundamentals in the CRA overview. For a concrete conversation: get in touch.