EU Cyber Resilience Act Guide for Point-of-Sale & Payment Terminal Vendors

Payment terminals, card readers, integrated point-of-sale systems, mobile point-of-sale (mPOS) devices, self-service kiosks with payment functionality, and POS software with network connectivity are all products with digital elements within CRA scope. Payment devices that process cardholder data, connect to payment networks, or manage financial transaction records fall into Important Class I under Annex III.

Vendors should note that POS system complexity varies significantly: a standalone countertop payment terminal with a direct payment network connection is a simpler product than an integrated POS system combining payment processing, inventory management, loyalty programme integration, and customer analytics. Both are within CRA scope, but the more complex system has a larger attack surface and a more complex conformity assessment. Vendors must scope each product line independently.

Payment terminal vendors are already subject to stringent security requirements under PCI PTS (Point-to-Point Terminals Standards) and PCI DSS. CRA Annex I adds to — but largely aligns with — these existing requirements:

• Encryption of cardholder data: Point-to-point encryption (P2PE) is best practice under PCI DSS and directly satisfies CRA Annex I data confidentiality requirements.
• Authenticated firmware updates: PCI PTS requires firmware signing; this directly aligns with CRA's authenticated update requirements. Vendors must verify that update mechanisms meet CRA standards even if PCI PTS approval is current.
• Tamper detection and response: Physical tamper detection is a PCI PTS requirement; logical tamper detection (integrity monitoring of the running software environment) is additionally required under CRA.
• Minimal attack surface: POS terminals must not run unnecessary services. Management interfaces must be protected with strong authentication.
• SBOM maintenance: POS systems frequently integrate complex software stacks including payment kernels, OS components, and application software. A complete SBOM for each firmware/software version must be maintained.

Payment terminal vulnerabilities are among the most commercially sensitive in the technology sector — a publicly disclosed payment terminal vulnerability can trigger immediate fraudulent exploitation and cause significant reputational damage to the vendor and their retail customers. Article 13's CVD policy requirement does not require immediate public disclosure; it requires a formal coordinated disclosure process.

• Provide a secure submission channel accessible to security researchers and payment industry bodies (e.g., PCI SSC security research programme)
• Define embargo periods that allow patch development and payment scheme notification before public disclosure — typically 90 days or longer for complex payment terminal vulnerabilities
• Coordinate with payment card scheme security teams (Visa, Mastercard) who have independent notification requirements under their scheme rules
• Publish CSAF advisories for resolved vulnerabilities in a format that enables automated processing by retail customers' vulnerability management tools

Active exploitation of a payment terminal vulnerability — for example, a skimming attack exploiting firmware vulnerability or a network-level attack on POS terminals — triggers Article 14's 24-hour ENISA notification requirement. Payment terminal exploitation is a financially motivated attack that typically occurs at scale, making rapid notification and response critical.

1. ENISA (CRA Article 14 — 24 hours)
2. Payment card schemes (Visa, Mastercard incident notification requirements under scheme rules — typically within hours for active fraud-enabling compromises)
3. PCI SSC for PCI-approved products — compromised PCI certifications must be reported
4. Retail customers — particularly large retailers who may be experiencing active fraud as a result of terminal compromise

Vendors should pre-establish communication protocols with payment scheme security contacts and major retail customers to enable the parallel notification required within the Article 14 timeframe.

Class I payment terminal products require third-party CRA conformity assessment. Vendors should leverage existing PCI PTS approvals and PCI PA-DSS/MPoC certifications as supporting evidence for CRA assessment — the security controls evaluated under PCI schemes overlap substantially with CRA Annex I requirements.

• PCI PTS approval demonstrates physical and logical security of the payment terminal hardware — directly relevant to Annex I device security requirements
• PCI PA-DSS certification (or successor standards) demonstrates application security for payment software
• PCI P2PE validation supports CRA Annex I data confidentiality requirements

However, PCI certifications do not substitute for CRA conformity assessment — they provide supporting evidence. The CRA assessment must additionally verify the CVD policy, SBOM, and lifecycle vulnerability management process, which are outside PCI's scope. Notified bodies conducting CRA assessments for payment terminal vendors will likely have significant familiarity with PCI frameworks, facilitating efficient assessment processes.