CRA Compliance Checklist: Payment Terminals & ATMs
Annex III Class I — payment terminals and ATMs are important products processing financial transactions; intersection with PCI DSS, PSD2, and EBA RTS on strong customer authentication
Payment terminals and ATMs are products with digital elements that sit at the intersection of the CRA, PCI DSS, PSD2, and EBA regulatory frameworks. They are Annex III Class I due to their financial infrastructure role. ATMs and unattended payment terminals in public spaces face significant physical and cybersecurity risks. While PCI DSS compliance does not provide a CRA exclusion, the two frameworks address overlapping security domains and compliance evidence from PCI assessments can support CRA technical documentation.
1. Scope & Classification
Confirm payment terminals, ATMs, and cash recycling machines are products with digital elements in CRA scope
All payment hardware with network connectivity and updateable software — PIN entry devices, contactless readers, ATMs, cash dispensers, kiosk payment modules — are in scope.
Assess Annex III Class I classification for payment terminals as important products in financial infrastructure
Payment terminals and ATMs process financial transactions and hold sensitive payment credentials. Class I classification reflects their importance to financial infrastructure.
Map PCI DSS v4.0 and PCI PTS requirements to CRA Annex I — document where PCI compliance satisfies CRA and identify residual gaps
PCI DSS Requirement 6 (secure systems development), Requirement 10 (audit logging), and Requirement 12 (security policy) align with CRA requirements. Map these explicitly and identify CRA requirements not covered by PCI.
Assess PSD2 SCA and EBA RTS on authentication for payment terminal design — dynamic linking, transaction authentication, and anti-phishing requirements
PSD2 SCA requires dynamic linking of payment authentication to the transaction amount and payee. EBA RTS requirements for authentication hardware must be reflected in terminal design and CRA compliance.
2. Product Security (Annex I Part I)
Implement PCI PTS-compliant hardware tamper protection — physical tamper triggers immediate key zeroing and device disablement
PCI PTS hardware security requirements (HSR) and software security requirements (SSR) define the hardware tamper protection baseline. CRA Annex I Part I(7) adds protection against physical manipulation. Implement PCI PTS requirements as the minimum.
Implement end-to-end encryption from point of card interaction — never expose unencrypted PAN or PIN data in memory
Cardholder data must be encrypted at the moment of card interaction and remain encrypted throughout the payment processing chain. PCI P2PE validation provides a recognised standard. Align with CRA encryption requirements.
Implement secure boot and application whitelisting — only PCI-certified, signed applications must execute on payment terminals
Payment terminal secure boot and application whitelisting prevent installation of skimming malware. Align with PCI PTS SSR requirements and implement hardware-backed signature verification.
Implement ATM-specific defences: card skimmer detection, anti-shimming, cash trapping prevention, and jackpotting malware resistance
ATMs face unique physical and logical attacks. Implement skimmer detection via jitter or impedance measurement, anti-shimming mechanisms, note-reader cameras, and firmware protection against jackpotting malware.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy aligned with PCI responsible disclosure guidance and CRA Article 13
ATM and payment terminal vulnerabilities attract significant criminal and security research interest. A well-run CVD process enables responsible disclosure and rapid remediation.
Maintain PCI DSS patch management timelines as the minimum CRA patch delivery standard — align both requirements in a single process
PCI DSS Requirement 6 mandates patch timelines. CRA requires vulnerabilities addressed without undue delay. Align both in a single patch management SOP that satisfies the stricter of the two requirements.
Define security support lifecycle in coordination with PCI PTS sunset dates — communicate end-of-support to customers well in advance
PCI PTS approvals expire after typically 10 years. Align CRA security support end dates with PCI PTS sunset dates. Provide terminal replacement planning guidance to operators 18 months before end of support.
4. Article 14 Incident Reporting
Define Article 14 triggers — focus on jackpotting attacks, mass card data exfiltration, and network-based ATM malware campaigns
Jackpotting malware campaigns and mass ATM card data theft are clear Article 14 triggers. Pre-define criteria and pre-draft notification templates.
Coordinate Article 14 reporting with PCI incident response, payment brand notifications, and national financial regulatory authority requirements
Payment terminal breaches require parallel notifications: CRA Article 14 (ENISA), GDPR Article 33 (DPA), payment brand notifications, and potentially financial regulator notifications. Map all requirements to a single response playbook.
5. CE Marking & Technical Documentation
Leverage PCI PTS assessment reports and PA-DSS documentation as primary evidence base for CRA technical file — map coverage explicitly
PCI PTS assessment documentation covers much of the same ground as CRA technical file requirements. Produce an explicit mapping document showing which PCI assessment evidence covers which CRA Annex I requirement.
Issue EU Declaration of Conformity referencing the CRA — PCI PTS certification does not substitute for the CRA DoC
A CRA DoC is required for EU market placement regardless of PCI certification. Issue it once your technical documentation is complete and CRA conformity assessment is done.
Track your Payment Terminals & ATMs 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
Our ATMs use Windows 10 IoT — Microsoft ends support in October 2025. Does this create a CRA compliance problem?+
Yes. CRA requires that you deliver security updates for the duration of your stated support period. If your ATMs run an OS for which the underlying OS vendor no longer provides security patches, you cannot fulfil your CRA patch delivery obligations for OS-level vulnerabilities. You must either upgrade to a supported OS version, obtain extended security updates from Microsoft, or deploy effective compensating controls. Plan your Windows IoT migration before September 2026.
PCI PTS approval applies to our terminal — does this mean we comply with CRA?+
No. PCI PTS approval demonstrates compliance with payment card industry security requirements. It does not constitute CRA compliance. You still need to: complete CRA conformity assessment, issue a Declaration of Conformity, publish a CVD policy, maintain an SBOM, and address all CRA Annex I requirements. PCI PTS evidence can be used as part of your CRA technical file, but it does not substitute for CRA-specific requirements.
We manufacture ATM components (cash dispenser modules, card readers) but not full ATMs — who is responsible for CRA compliance?+
Component manufacturers are responsible for CRA compliance of their components as standalone products. The ATM integrator who assembles the complete ATM takes on manufacturer responsibilities for the integrated product. Both parties have distinct obligations. Provide ATM integrators with CRA technical documentation, SBOMs, and vulnerability support for your components. ATM integrators should contractually require CRA compliance from all component suppliers.
Need a CVD policy for Payment Terminals & ATMs?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.