The EU CRA Reporting Deadline Is Friday. Here’s What US Manufacturers Actually Need to Do.

If you build software or hardware with digital elements and you sell it into Europe, the EU Cyber Resilience Act (CRA) stops being a someday problem this Friday, September 11. That’s when the regulation’s reporting obligations start. It’s not a registration deadline and not a paperwork deadline. It’s the moment the duty to notify regulators kicks in, with a 24-hour clock that starts when you, personally, “become aware” of an actively exploited vulnerability or a severe incident in your product.

Most deadline coverage has been breathless, and some of it is wrong in ways that will cost companies real money. This article is for US-based manufacturers specifically. If you’re an importer or distributor, you have your own obligations under the CRA, but they’re not covered here. And if your assumption is that nothing starts until 2027, keep reading, because the reporting obligation arrives 15 months early and reaches back to products you shipped years ago.

Does this apply to me?

The three-part scope test

Per the Commission’s implementation FAQ, all three of these must be true:

• Your product meets the definition of a “product with digital elements” (software or hardware, plus any remote data processing it depends on)
• It’s made available on the EU market
• Its intended purpose or reasonably foreseeable use includes a data connection to a device or network, direct or indirect

How broad is “connected”?

That third leg is where wishful thinking goes to die. The FAQ’s own example: an offline text editor is indirectly connected to a network because it runs on an operating system that talks to one. If your software runs on a machine that touches a network, the scope question probably ends with “yes.”

The named out-of-scope examples are things like a dishwasher, a calculator, a coffee machine, and an electric toothbrush with embedded firmware and no connectivity whatsoever. If your product has Wi-Fi, Bluetooth, USB, NFC, or a software interface someone could plausibly reach, you’re in scope.

What counts as a product

Standalone software counts too, since mobile apps from app stores, firmware sold separately, printer drivers, and FPGA (field-programmable gate array) design tools all appear in the official examples. SaaS and websites are generally out, unless they qualify as “remote data processing,” meaning processing at a distance that your product can’t function without. The Commission has promised separate guidance on that concept, which hasn’t landed, so if your SaaS is deeply entangled with a hardware product, treat that line as unfixed.

Tools you build purely for internal use are exempt, but the moment you sell them separately, they’re products like any other.

The back catalog trap

Products placed on the market before December 11, 2027 are generally exempt from the CRA’s main requirements, unless they get substantially modified. But Article 69(3) drags Article 14 reporting back to every in-scope product ever, including that smart speaker you shipped in 2024. Your back catalog is covered. Right now.

(One note for later: if your product lands in Annex III or IV, think firewalls, hypervisors, password managers, tamper-resistant chips, you’ll eventually face third-party conformity assessment or EU certification. That obligation is years out, not Friday.)

What to do by Friday

This is a shorter list than what most of the internet suggests (particularly companies selling EU CRA “products” or “solutions”). There’s no filing due Friday and no registration deadline; what you need is readiness, and it’s mostly administrative work:

• Create EU Login accounts and turn on multi-factor authentication (MFA) now. Doing this during an incident burns hours off a clock that’s already running.
• Decide who your primary filer is and who backs them up. One person registers as your company’s primary filer on the platform (the “Assigned Representative” user role in ENISA’s terms, which is a platform role, not the same thing as the legal representative for non-EU manufacturers discussed below). Secondary users come in by invitation, and those invitations expire after seven days, so don’t let an unread inbox decide your backup arrangement.
• Figure out which national CSIRT (Computer Security Incident Response Team) you’d report to, using ENISA’s (the EU Agency for Cybersecurity) published list of CSIRTs designated as coordinators. If you have no EU establishment, Article 14(7) gives you a chain: the Member State where your authorized representative under the CRA sits, then your biggest importer, then your biggest distributor, then wherever most of your users are. Once you report somewhere, subsequent reports go to the same place.
• Write down your decision criteria for “awareness.” When exactly does your company decide it has reliable evidence of exploitation? That judgment, made under pressure and reconstructed later from tickets and chat logs, is where timeliness disputes will be decided, and will influence fines from the EU.
• Book a tabletop. Walk the reporting process end to end before something real forces the issue, so the first time anyone touches the 24-hour clock isn’t mid-incident with an unfamiliar form on an unfamiliar platform.

On registration

Two things have been conflated in the deadline coverage I’ve read, and they’re different. Setting up an EU Login account with MFA is account plumbing, and you should absolutely do that in advance. Registering on the Single Reporting Platform (SRP) itself is separate, and ENISA’s own user registration guidance tells manufacturers not to do it pre-emptively; register when you actually need to file. The CSIRT’s validation of your identity runs in parallel and doesn’t block submission, so if something qualifying happens on day one, you register and file in the same motion. That’s the designed flow, not a workaround.

Also, if you already knew about active exploitation of your product before September 11, 2026, you’re not required to report it retroactively. But awareness of a vulnerability doesn’t exempt you, awareness of its exploitation does. That five-year-old bug you’ve known about since 2021 becomes fully reportable the moment you learn someone’s exploiting it. Given how AI’s exploiting older vulnerabilities, that’s probably a “when”, not an “if” for when you’ll be reporting it.

When the clock is running

The staged process comes straight from Article 14. The first two stages are identical for both tracks; only the final report differs:

Stage	Actively exploited vulnerability	Severe incident
Early warning and full notification	Same for both tracks: 24 hours, then 72 hours, from awareness	Same for both tracks
Final report	Within 14 days after a corrective or mitigating measure becomes available	Within one month after the 72-hour notification

What triggers a report

“Actively exploited” is reliable evidence that a malicious actor exploited the flaw in a system without the owner’s permission. Findings from your bug bounty or an assessment lab, absent evidence of in-the-wild exploitation, don’t trigger it.

“Severe incident” is defined broadly enough to make lawyers comfortable and security teams nervous: an incident is severe if it’s capable of hurting the product’s ability to protect sensitive data or functions, or capable of leading to malicious code execution. Capability, not proof.

You also owe your users notice, and if you drag your feet, the CSIRT will happily inform them for you.

Know the platform’s limits

Expect even more rough edges at launch, because ENISA’s own guidance admits them. There’s no API (application programming interface), so filing is a human with a web form, and ENISA hadn’t published the platform’s web address ahead of launch day. If the platform goes down, ENISA’s guidance says wait for it to come back, and it even discloses that the 72-hour counter can display a report as overdue before the full 72 hours have run from awareness. Its pages also disagree on how many notifications you can file before identity validation becomes mandatory, 10 on one page, 20 on another. None of that pauses your legal deadline.

Risk assessment: the 15-month runway

The larger obligations don’t apply to newly placed products until December 11, 2027, which means what you do between now and then determines whether next winter is a project or a crisis.

The centerpiece is Article 13’s cybersecurity risk assessment, and the FAQ’s treatment of it answers most of the questions manufacturers ask first:

• It’s a lifecycle obligation, informing planning, design, development, production, delivery, and maintenance, and it applies to every product regardless of category.
• There’s no mandated methodology, which is genuinely good news: teams already running structured risk processes can adapt what they have. What regulators expect is documentation showing how risks were identified, evaluated, and mitigated.
• If you decide an essential requirement doesn’t apply to your product, you need a written justification in the technical documentation. Silent omission isn’t a strategy; it’s a finding waiting to happen.

The specifics that will probably trip people up

Support periods. Five years is the floor, not a target, and products realistically used longer than five years (routers, operating systems, industrial gear) justify longer support. Subscription-only software can cap at subscription length.

Third-party and open-source components. You’re on the hook for vulnerabilities in integrated components, and if you patch someone else’s component, you’re expected to share that fix upstream.

The actual security bar. It isn’t “zero vulnerabilities,” it’s “no known exploitable vulnerabilities” at placement, judged against practical conditions. The FAQ’s example of a printer debug interface requiring physical disassembly and soldering to exploit is the canonical case of something you document rather than patch.

For teams starting from scratch, Germany’s BSI (Federal Office for Information Security) has published TR 03183-1 as non-binding scaffolding, and it’s a more useful starting point than waiting for harmonized standards that aren’t ready.

What noncompliance costs, and when

The numbers

Breaching Article 14 sits in the CRA’s top penalty tier under Article 64: fines up to EUR 15 million or 2.5 percent of total worldwide annual turnover, whichever is higher. Those are ceilings, with Member States setting actual penalty rules and weighing factors like gravity and company size.

The timing gap

Read Article 71, which accelerates only Article 14 and Chapter IV into early effect. Article 64, the penalties article, isn’t on that list, so on the face of the text the fine regime doesn’t switch on until December 11, 2027. The reporting duty runs 15 months ahead of the fine regime that backs it. No official guidance addresses what enforcement looks like in between, so treat that gap as my interpretation of the text, not a bet.

The small-business carve-out

The EU’s standing definition comes from Recommendation 2003/361/EC, and the same ceiling applies to both turnover and balance sheet total for every category:

Category	Staff headcount	Turnover or balance sheet total
Micro	Fewer than 10	EUR 2 million or less
Small	Fewer than 50	EUR 10 million or less
Medium	Fewer than 250	EUR 50 million (turnover), or EUR 43 million (balance sheet)

Headcount is the main factor, and the financial test is either-or. Group ties count too: a US startup that’s tiny on its own books can be dragged out of the carve-out by an EU affiliate or a 25-percent investor.

And the carve-out itself is narrow. Micro and small enterprises escape fines only for missing the 24-hour early warning. The 72-hour notification and final report carry full exposure for everyone, and medium-sized firms get no relief at all.

The evidence problem

CISA (the US Cybersecurity and Infrastructure Security Agency) maintains its Known Exploited Vulnerabilities catalog, which carried 1,695 entries as of September 4, with 19 added in the preceding week. A KEV entry isn’t proof your company knew anything, but it’s a public, dated record of exploitation sitting next to your private timeline of when you “became aware.”

Your incident tickets just became regulatory documents. Act accordingly.