The EU Cyber Resilience Act: An Executive Guide

Most of the conversations I've had about the Cyber Resilience Act in the last six months have started the same way. Someone on the executive team has heard the acronym, knows it's European, assumes it's a GDPR sequel, and is hoping the legal team has it handled. Two of those three assumptions are wrong, and the third one is usually optimistic.

So this is the version I'd give a CEO or a board director over a coffee. Not a compliance briefing. Not a clause-by-clause read. Just the picture of what this law actually does, where it hurts, and the handful of decisions that have to come from the top before anyone further down can do their job.

It's a product law, and that's the part people miss

GDPR is about how you handle personal data. NIS2 is about how critical operators run their networks. The CRA is about the security of the products themselves. Hardware, software, anything with a digital element that ends up on the European market. If a customer can plug it in, install it, or connect to it, assume you're in scope until someone can prove otherwise.

The scope is wide on purpose. Consumer devices, industrial controllers, enterprise software, network gear, mobile apps, components you sell to other manufacturers who then put them inside their own boxes. There are some carve-outs — medical devices, automotive, aviation, a few other sectors that already have their own vertical rules — but for most leadership teams I've spoken to, the carve-outs don't get them off the hook.

The obligations sit with whoever puts the product on the EU market. Usually that's the manufacturer, but importers and distributors carry weight too. "We're a US company" is not a defence I'd build a strategy around. If your product ends up in the hands of an EU customer, the CRA ends up in your inbox.

Three dates worth putting on the wall

Forget the rest of the calendar for a minute. There are three.

**September 11, 2026.** Reporting obligations switch on. From that day, an actively exploited vulnerability or a severe incident in one of your products has to be reported to ENISA and the relevant national CSIRT inside 24 hours, with a follow-up at 72 hours and a final report at 14 days. This is the one that catches people out, because it's not a policy you write. It's an intake, a triage process, a disclosure capability, and a decision-maker who can be reached at 2 a.m. on a Saturday. None of that gets built in a quarter.

**December 11, 2027.** The full law applies. Every product placed on the EU market from that date forward has to meet the essential cybersecurity requirements, ship with security support for its expected lifetime, carry conformity documentation, and wear the CE mark on the basis of CRA compliance. Products already on the market before that date are mostly grandfathered — until somebody substantially modifies them, at which point the grandfather clause goes away.

**The bit in between.** Across 2026 and 2027, the harmonized standards, the common specifications, and the lists of "important" and "critical" product categories keep getting finalized. Those categories decide whether you can self-assess or whether a notified body has to be involved. Treat the regulation as the floor. The standards work is where the real operational detail will land, and a lot of it isn't written yet.

What it actually asks of a manufacturer

Strip the legal language away and the CRA is asking four things.

One, design and build the product to be secure. No known exploitable vulnerabilities at the moment of shipping. Secure defaults. A documented attack surface. The controls you'd expect a serious product team to be running already — least privilege, encryption where it makes sense, integrity protection, some resilience against denial of service.

Two, handle vulnerabilities for the supported life of the product. That means a coordinated disclosure policy, a way for the outside world to reach you with a finding, free security updates pushed without unreasonable delay, and a Software Bill of Materials you can produce on request. Support periods are expected to track the product's reasonable lifetime, with a floor that lands around five years for many categories.

Three, prove conformity and write it down. For most products, that's self-assessment with technical documentation and an EU declaration of conformity. For the important and critical categories, a notified body has to sign off. The CE mark goes on the basis of all of that.

Four, keep reporting for the life of the product, against the clock described above.

None of this is exotic. A mature product security organization is already doing most of it. The honest problem is that very few companies selling into Europe have a mature product security organization across every line of business. Some lines are excellent. Some lines were acquired three years ago and still ship the way they always did.

The supply chain is where this gets uncomfortable

The CRA is the first major regulation to put real weight on the software and hardware supply chain, and that is where the operational pain is going to land.

If you're a downstream manufacturer pulling in components — an open-source library, a commercial SDK, a board from a contract manufacturer, a piece of white-label firmware — you're still on the hook for the security of the finished product. You can write the contracts. You can demand SBOMs and disclosure commitments. You cannot hand the regulatory obligation off. ENISA reports to your national authority. The national authority looks at the CE mark you put on the box.

Expect this to reshape supplier relationships in three pretty predictable ways. Smaller component vendors who can't meet the documentation and disclosure bar will get pushed out of European bills of materials. Open-source dependencies will get more scrutiny, more corporate sponsorship in places, and quietly more avoidance in others. Large suppliers will use CRA readiness as a wedge to lock customers in, the same way the cloud providers used compliance certifications a decade ago.

If you're on the supplier side of that equation, the real question isn't whether you can pass an audit. It's whether your customers are going to keep buying from you once their compliance team starts asking the questions the CRA forces them to ask. If you're not sure of the answer, that's a strategy problem, not a paperwork problem.

The penalties, and the thing that's actually worse than the penalties

The headline numbers are real. Up to €15 million or 2.5% of global annual turnover, whichever is higher, for falling short of the essential requirements. €10 million or 2% for other obligation failures. €5 million or 1% for giving authorities incorrect or misleading information. These are GDPR-class numbers and they apply to the global parent, not just the European subsidiary.

The fines aren't the part I'd lose sleep over. Market access is. National authorities can order a non-compliant product withdrawn or recalled. A single enforcement action against a flagship product does more damage to a business than the fine attached to it. The press release writes itself, and you don't get to write it.

Four questions a board should be asking

I wouldn't ask the executive team to walk the board through the regulation. I'd ask four questions and watch how confident the answers are.

*Which of our products are in scope, and who personally owns each one?* If there isn't a single accountable executive for CRA conformity per product line, the program hasn't started, no matter what the slide says.

*Are we going to be ready for the September 2026 reporting obligation?* This is the nearest cliff. It needs a working vulnerability intake, a 24-hour decision process, and a coordinated disclosure capability that has actually been rehearsed.

*What's our supplier exposure?* For each in-scope product, which components or dependencies are we leaning on that may not themselves be CRA-ready, and what's the plan to replace or pressure them?

*What is this going to cost?* CRA conformity isn't free. The pilot numbers I've seen from manufacturers running early programs land somewhere in the 5–15% range on top of product cost for organizations starting from a low base, and lower for organizations that already have a serious SDLC and product security function. That number belongs in the operating plan, not in a footnote.

It doesn't exist in isolation

The CRA isn't the only regulation moving. NIS2 is already in force for the operators it covers. The AI Act phases in across 2025–2027. DORA covers financial services resilience. The Data Act and the revised Product Liability Directive touch a lot of the same products from different angles. For most multinationals, the real question isn't how to comply with the CRA on its own. It's how to build one product-and-operational-security program that satisfies the whole stack without doing the same work four times.

Treating each regulation as a separate project is how compliance budgets get out of control, and how organizations end up with overlapping, contradictory internal policies that nobody follows. The teams that handle this well will use the CRA as the forcing function to consolidate the rest.

What I'd do in the next 90 days

Three things, in this order.

Do an honest in-scope inventory. Not a generic "what do we sell in Europe." A product-by-product mapping against the CRA categories, including the embedded components and the resold third-party products that quietly carry your name. You can't plan what you haven't catalogued, and the catalogue is almost always uglier than the executive summary suggests.

Stand the reporting capability up before you need it. September 2026 is the deadline. The capability has to be live months earlier so you can rehearse it. This is the obligation that will produce the first public enforcement actions, because it's the easiest one for authorities to verify.

Have the supplier conversation. Pick the top ten components in your most strategic in-scope products and find out whether each supplier has a credible CRA roadmap. The ones who don't are a risk that won't resolve itself, and the longer you leave it, the fewer alternatives you'll have.

Sources

*Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements · ENISA guidance on CRA implementation · European Commission Q&A on the Cyber Resilience Act (2025)*

The Cyber Resilience Act will not be the last product-security regulation, but it is the one that sets the template. The organizations that treat it as a forcing function to mature their product security program will be in a better position for everything that comes after. The ones that treat it as a paperwork exercise will discover, somewhere in 2027, that paperwork does not pass a conformity assessment.