Anyone selling a product that runs software in the European Union took on a new duty on September 11, 2026. Article 14 of the Cyber Resilience Act now applies: as soon as a manufacturer learns that a vulnerability in its product is actively exploited, it has 24 hours to alert the authorities. Payments is one of the industries most exposed to the rule, and one of the quietest about it.
Article 14 is the first part of the regulation to take effect. The rest of the Cyber Resilience Act applies from December 11, 2027.
Reports come in three stages through one EU platform
The European Commission describes a three-step process. An early warning is due within 24 hours of the manufacturer becoming aware. A detailed notification follows within 72 hours. The final report is due no later than 14 days after a corrective measure is available for a vulnerability, or within a month of the 72-hour notification for a severe incident.
Manufacturers file in one place. ENISA, the EU cybersecurity agency, launched its Single Reporting Platform the same day. A single filing goes to the national computer security incident response team (CSIRT) where the manufacturer has its main establishment and is made available to ENISA at the same time. That CSIRT then shares it with the CSIRTs of the other countries where the product is sold.
Terminals, PIN pads, and SoftPOS apps all count as products
The regulation defines a “product with digital elements” broadly, covering both hardware and software placed on the EU market. In payments, that takes in devices and code the industry does not usually think of as “products”: the point-of-sale terminal, the PIN pad, the hardware security module (HSM), the mobile acceptance app on a phone, and the embedded libraries that run them all.
- terminal makers, which sell a physical device with an operating system and software updates;
- developers of mobile acceptance (SoftPOS) apps, whose product is pure software;
- suppliers of security modules and cryptographic components;
- integrators that put products on the market under their own brand, which makes them manufacturers under the regulation.
The principle is not the hard part. The deadline is. Twenty-four hours is shorter than the time a security team needs after spotting an active exploit: reproduce it, confirm it, and measure how much of the installed base is exposed. That installed base is old. A terminal stays in service for seven to 10 years, and the duty follows every product placed on the market, not just the current model.
The CRA adds a third reporting clock to DORA and scheme rules
Payments companies already report under several regimes. DORA, the EU’s Digital Operational Resilience Act, requires financial entities to report major ICT-related incidents, with its own thresholds and deadlines. Card scheme rules govern how a data compromise is reported. The Cyber Resilience Act replaces none of them. It comes on top, and it targets a different party.
| Regime | Who reports | What triggers it |
|---|---|---|
| Cyber Resilience Act | the product manufacturer | an actively exploited vulnerability, or a severe incident affecting the security of the product |
| DORA | the financial entity | a major ICT-related incident |
| Card scheme rules | the scheme participant | a suspected compromise of cardholder data |
A terminal maker that sells to a bank may therefore report to ENISA while its customer reports the same event to its financial supervisor. Neither filing satisfies the other, and nothing ensures the two tell the same story at the same time.
Meeting the deadline takes preparation
The duty is only to report, but it assumes an organization many companies do not have. To know within 24 hours that a flaw is being exploited, a manufacturer has to detect it. That means receiving reports from outside, which means publishing a way to send them. The regulation requires that point of contact anyway.
In practice, that means a public channel for vulnerability reports, with someone assigned to read it; an on-call team that can decide over a weekend whether a flaw is “actively exploited”; an up-to-date inventory of the products still supported; and an early-warning template ready to send, because 24 hours leaves no time to write one.
One question will only be settled by the first real case: what an alert filed within 24 hours is worth when the manufacturer does not yet know whether the exploit affects 10 devices or 100,000. The regulation accepts that uncertainty, which makes sense. Authorities will have to learn to read alerts that say very little.