CRA for payment & POS terminals

Where terminal cryptography meets horizontal cybersecurity requirements

A payment terminal is densely regulated: 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 protects that key material with a secure element on its board. Its connectivity turns 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 in addition to the established payment security regimes.

Security is no stranger to this sector; payment has long been shaped by certification logic. What is new 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 coordinated vulnerability disclosure policy, a reporting cascade via the single reporting platform, and update capability sustained across the entire support period. That is an axis of its own alongside PCI.

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 aim is to align both regimes so that evidence is not produced twice. (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" (self-assessment under Module A), Annex III "important" products (class I and II), and Annex IV "critical" products. What counts for the classification is the core function of the product placed on the market (Article 7(1), Article 8(1)); a built-in component with a class of its own does not raise the device's classification. 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.

In practice a terminal maker should assume Annex IV and check against the description in the Implementing Regulation. A bought-in secure element neither raises nor lowers the terminal's classification; its own conformity is the responsibility of the element's manufacturer.

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. Existing evidence can be reused where it substantively covers Annex I requirements.

• PCI PTS / PCI DSS: adjacent, non-CRA regimes. They cover device tamper and operations but not the CRA-specific SBOM and reporting logic.
• RED delegated Regulation 2022/30: relevant for radio-capable terminals that can communicate over the internet (cellular/Wi-Fi); where they enable money transfers, Art. 3.3 f applies in addition; until the regulation is repealed with effect from 11 Dec 2027, the boundary/overlap between RED-DA and CRA must be drawn cleanly.
• NIS2: concerns essential and important entities, not the terminal as a product. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. CRA addresses the product, NIS2 the organisation - separate legal acts, do not conflate.
• DORA: financial-sector resilience for financial entities; for credit institutions and other financial entities, DORA takes precedence. A pure hardware maker is not automatically in scope but may be touched as an ICT third-party provider.
• AI Act: applies in addition as soon as an AI system is built in (e.g. fraud detection); the scope of duties depends on the risk level.

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 (e.g. 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 software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. There is no general obligation to publish it; the SBOM serves as evidence toward authorities and conformity assessment. For payment this concretely means: SBOM maintenance should be aligned 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 becomes an operational early-warning system for EOL risks.

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

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

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
• 14 days - final report for an actively exploited vulnerability, counted after a corrective or mitigating measure becomes available.
• 1 month - final report for a severe incident, after the 72-hour notification.

Reporting goes via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. The internal reporting process should be kept ready regardless. For payment it is important 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. Since 11 September 2026 the reporting obligation (Art. 14) has applied; it came first and requires a working PSIRT/CVD process connected to the single reporting platform, 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 means facing a reporting duty since September 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: as a physical payment terminal with a security box, the terminal is likely a critical product under Annex IV; the bought-in secure element does not change that, and the cellular module pulls in the RED-DA boundary. As long as no delegated act requires a European scheme, the maker therefore plans early for a notified body (Module B+C or H) or a European scheme of at least “substantial”.

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 playbook for the early warning (without undue delay, within 24 hours at the latest) and the notification (within 72 hours at the latest), including access to the single reporting platform - aligned with the existing card-scheme reporting chains. The reporting process must stand since 11 September 2026; by 11 December 2027 the full technical documentation, risk assessment, conformity assessment and CE/EU declaration of conformity follow. When a crypto library goes EOL, the SBOM acts as early warning - the update runs aligned across both regimes.

What Blackfort Technology does for you

Blackfort Technology supports payment and POS manufacturers and importers along exactly this axis - with the aim of not maintaining CRA evidence and existing payment evidence twice:

• Exposure and scope analysis: a technical assessment of which of your terminals, PIN pads and SoftPOS variants are PDE, which Annex class is plausible and where RED-DA additionally applies - as structured classification, not legal advice.
• SBOM setup: machine-readable SBOM, for example in CycloneDX or SPDX, from your build pipeline, aligned with your existing 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 (early warning, notification, final report after 14 days or 1 month) including connection to the single reporting platform.
• Risk assessment and threat modeling: documentable risk analysis under Art. 13 and Annex I for the specific terminal architecture.
• Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)), as the basis for the conformity assessment.

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.