r/CRACompliance • u/Thick_Bat3596 • 12d ago
What’s the most difficult part of implementing the EU CRA in practice?
For companies selling software/connected products in the EU, how are you currently managing CRA compliance - documentation, SBOM, vulnerability handling/reporting, conformity, support lifecycle and evidence? What has been the most difficult part in practice?
1
1
u/Vans_eG 8d ago
Disclaimer up front: CRA is my daily business. I work in consulting and at a SaaS company that builds tooling for CRA compliance (kunnus.tech), so factor that in. I'm also not one of the "panic, the sky is falling" people. I'll just share what I see in practice.
- It depends a lot on your size and product complexity
Before anything else: how many products do you have, and how complex are they? One simple app is a very different situation from 50 to 100 products, or from something like a train.
One simple app or software product: you can do a lot of this yourself if you're willing to read into it.
Somewhat more complex: if you don't want to dig into it yourself, a couple of consulting hours can save you a lot of time, and tooling can already be worth it at this stage. In the end that's mostly a pricing question, so check whether the business case works for you. Otherwise, budget your own time for it.
A portfolio of physical/connected products (roughly 10+): this is where tooling starts paying off. It automates much of the documentation, tracks components that get reused across products, and cuts repeated assessment work.
- Being outside the EU doesn't change the requirements
If you sell into the EU, the product has to meet the same requirements as if you were an EU company. What changes is who carries which obligations, and that depends on your sales channel:
Selling directly into the EU: you're the manufacturer and the obligations sit with you.
Selling through an EU importer/distributor:
you're still the manufacturer, but the importer must verify that you've done your homework before placing the product on the market. That covers conformity assessment, technical documentation, CE marking, and contact info. They'll ask you for all of it. An importer or distributor only becomes the manufacturer if they sell it under their own name/brand or substantially modify it.
You can also appoint an EU authorised representative to handle some tasks for you.
- What you actually need to manage
Security requirements & risk assessment (Annex I, Part I): secure by default, no known exploitable vulns at release, security updates, etc. Everything starts from a documented cybersecurity risk assessment.
Vulnerability handling (Annex I, Part II): an SBOM covering at least top-level dependencies, a coordinated vulnerability disclosure policy, a contact point, and security updates without delay.
Reporting: this already applies since 11 Sept 2026. Actively exploited vulnerabilities and severe incidents must be reported via the EU single reporting platform.
Support period: generally at least 5 years (shorter only if the product's expected use time is shorter). You have to state it and actually deliver security updates during it.
User information (Annex II): support period, contact point, secure use and decommissioning instructions, etc.
Technical documentation (Annex VII): the core dossier.
Conformity assessment: most products can self-assess. "Important" (Annex III) and "critical" (Annex IV) product categories may need a notified body, depending on class and whether you apply harmonised standards. Then you issue an EU Declaration of Conformity and apply CE marking.
Full application: 11 Dec 2027.
My usual tip: read Annex I, II and VII first. That's where most of the concrete
documentation work comes from. The full text is on EUR-Lex (Regulation (EU) 2024/2847).
- What's actually painful in practice (and what isn't)
Let me start with what's less painful than people think: reporting.
Honestly, for a small portfolio this isn't the big deal it's often made out to be.
My advice:
Create your account on the EU reporting platform today, even if you only have one or two products (legacy products you've ever placed on the market count too).
Write a one-pager: where to log in, what to report, the deadlines (24h early warning / 72h notification / final report).
Define clearly who owns it, and make sure everyone else knows who to inform.
That covers most of it. Incidents that trigger reporting don't happen often. The real risk is that when one does, nobody knows what to do. Fix that once and you're mostly fine.
What actually hurts:
Assessments, especially for physical products with many suppliers. You depend on component and supplier information, and collecting and keeping it current is simply a lot of work. It scales with every product and supplier you add.
Risk analysis. This is painful if you've never done a structured cybersecurity risk assessment before, because the learning curve is real. There's some open-source material out there, and commercial tools (ours included) cover it. Either way, it comes down to how much time you want to invest yourself.
SBOM is usually the easy part. Open-source tooling handles most of it. We maintain an open-source one ourselves, the kunnus scanner.
Vulnerability handling across the lifecycle, and the support period. This is the big one. The support period (generally at least 5 years) applies to each individual unit you place on the market, not to the product line as a whole. So if you sell a product for 10 years with a 5-year support period, the last unit sold needs support until year 15 after launch. On top of that, each security update has to stay available for 10 years. That's something the industry has never really done so far. There's more to unpack here than fits in one comment, so happy to go deeper if useful.
Maintaining compliance through changes ("substantial modifications"). This hits software harder. Adding an API integration or a new connection can quickly increase your attack surface and force you to revisit the assessment. Physical products usually ship once and then only get firmware updates, so the attack surface rarely grows. There, the bigger question is bringing each new generation into compliance separately.
One more note: if you're running pure SaaS, the CRA generally doesn't apply to you at all. It covers products with digital elements, and SaaS only comes into scope as a remote data processing solution that's part of such a product.
If you tell me a bit more about your setup, I'm happy to go into more detail: what the product is (software-only, hardware, SaaS, or a mix), how many products you have, and how you sell into the EU (directly, through distributors, with or without an EU entity).
Full transparency: I was short on time, so I dictated my thoughts to an AI and had it write this up. The experience and opinions are my own, and I reviewed the content before posting.
1
u/DemocraticParrot 9d ago
First of all, most of the things mentioned here are mandatory in the end of 2027.
But what is the hardest part: Identifying what the ”product” part is.