CRA Compliance Checklist: Point of Sale & Payment Terminals
Annex III Class I — POS terminals and payment hardware processing financial transaction data are important products; interaction with PCI DSS and PSD2 regulatory frameworks
Point of sale systems and payment terminals are products with digital elements that process financial transaction data and interact with payment card networks. They face specific CRA obligations and must also address the intersection with PCI DSS (Payment Card Industry Data Security Standard) and PSD2 Strong Customer Authentication requirements. While PCI DSS does not provide a CRA exclusion, compliance with it addresses many overlapping security requirements.
1. Scope & Classification
Confirm all POS terminals, card readers, and payment software are products with digital elements in CRA scope
POS hardware (PIN entry devices, contactless readers, integrated POS terminals) and software (POS application, payment processing software) are all in scope.
Assess Annex III Class I classification for payment terminals given their role in financial infrastructure
Payment terminals processing financial transactions and storing payment card data are important products. Annex III Class I is likely appropriate for most POS hardware.
Map PCI DSS v4.0 requirements against CRA Annex I — PCI DSS compliance satisfies many but not all CRA requirements
PCI DSS v4.0 has significant overlap with CRA Annex I (encryption, access control, vulnerability management, patch management). Use PCI DSS compliance evidence where it covers CRA requirements, but identify gaps.
Assess PSD2 Strong Customer Authentication (SCA) requirements for payment terminals used in EU payment services
PSD2 SCA requirements mandate multi-factor authentication for electronic payments. Your terminal must support PSD2-compliant SCA mechanisms. Document the regulatory intersection in your compliance plan.
2. Product Security (Annex I Part I)
Implement hardware-based tamper detection and response — payment terminals must resist physical attack and skimming device attachment
PCI PTS (PIN Transaction Security) requires hardware tamper protection. Implement physical tamper evidence, enclosure intrusion detection, and tamper response (key zeroing). Align with PCI PTS requirements.
Implement end-to-end encryption (E2EE) or point-to-point encryption (P2PE) for all cardholder data from point of capture
Cardholder data must be encrypted at the point of capture and remain encrypted throughout the payment processing chain. PCI DSS and CRA both require this. Use PCI-validated P2PE where possible.
Implement secure boot and code signing for all payment terminal firmware and application software
Payment terminal firmware must be signed and verified during secure boot. Only authorised, signed software must execute on the terminal. PCI PTS and CRA both require this.
Implement strict software allowlisting — only certified payment applications should execute on the terminal
Payment terminals should only run certified payment applications. Application whitelisting prevents installation and execution of malicious skimming software.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy aligned with PCI Responsible Disclosure guidelines and CRA Article 13
PCI security researchers and general researchers regularly find payment terminal vulnerabilities. A CVD policy aligned with both PCI guidelines and CRA Article 13 is required.
Align CRA vulnerability remediation timelines with PCI DSS patch management requirements
PCI DSS Requirement 6 mandates patch management timelines. CRA requires vulnerabilities be addressed without undue delay. Align both requirements in a single patch management process.
Define security support lifecycle for POS hardware — coordinate with PCI PTS sunset dates for deprecated terminal models
PCI PTS approval has a defined validity period (typically 10 years). Align CRA security support end dates with PCI PTS sunset dates. Communicate clearly to retailers when terminals reach end of support.
4. Article 14 Incident Reporting
Define Article 14 triggers for POS incidents — focus on card data exfiltration, terminal firmware compromise, and mass skimming attacks
Active exploitation of POS vulnerabilities for card data theft is a clear Article 14 trigger. Define criteria and pre-prepare notification templates.
Coordinate Article 14 reporting with PCI incident response obligations and payment brand notification requirements
Payment card data breaches require parallel notifications: CRA Article 14 (ENISA), GDPR Article 33 (DPA), and payment brand notifications (Visa, Mastercard incident reporting). Pre-plan all notification tracks.
5. CE Marking & Technical Documentation
Leverage PCI PTS, PA-DSS, and P2PE assessment documentation as evidence base for CRA technical file
PCI security assessment reports provide substantial evidence for CRA technical file requirements. Map your PCI assessment outcomes to CRA Annex I requirements to identify any gaps.
Issue EU Declaration of Conformity referencing the CRA for all in-scope payment terminal and POS products
DoC must reference the CRA. PCI assessments do not substitute for the CRA DoC — both are required.
Track your Point of Sale & Payment Terminals compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
Does PCI DSS compliance satisfy CRA requirements for payment terminals?+
PCI DSS compliance covers many CRA Annex I requirements — encryption, access control, vulnerability management, patch management, and logging all appear in both frameworks. However, PCI DSS does not satisfy all CRA requirements and does not provide a regulatory exclusion from CRA. You need both PCI DSS compliance (for card brand requirements) and CRA compliance (for EU market access). Map the two frameworks to identify where PCI DSS evidence satisfies CRA and where additional work is needed.
We manufacture POS software but not hardware — does CRA apply to software-only POS products?+
Yes. CRA covers software products with digital elements, including standalone software. A POS application that runs on general-purpose hardware (PC, tablet, smartphone) is a software product in scope for CRA. You must publish a CVD policy, maintain an SBOM, provide security updates, and issue a Declaration of Conformity. The PCI Software Security Framework (SSF) requirements for software-based payment solutions also apply.
Our payment terminal was already PCI PTS certified — do we need a separate CRA conformity assessment?+
Yes. PCI PTS certification is a payment brand requirement. CRA conformity assessment is an EU regulatory requirement for market access. They serve different purposes and are assessed by different bodies. PCI PTS assessment evidence can be used to support your CRA technical file, but you must still complete CRA conformity assessment procedures and issue a Declaration of Conformity.
Need a CVD policy for Point of Sale & Payment Terminals?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.