The 5 Biggest CRA Compliance Mistakes Product Security Teams Are Making

The five CRA compliance mistakes we see most often at Finite State: planning around December 2027 instead of September 11, 2026, building the SBOM from the build manifest instead of the binary, treating CVE count as a score, assuming compromise starts after the device ships, and publishing a vulnerability disclosure policy nobody staffs.

The first four mistakes share one root cause: the team is working from what it assumes is inside the product instead of what it can verify shipped. The fifth is an organizational problem, and it gets easier the moment the first four are fixed.

Here is the short version before we get into each one.

Mistake 1: Treating December 2027 as the Only Date That Matters

December 11, 2027 is when the EU Cyber Resilience Act applies in full. The first deadline lands well before that.

Article 14 reporting obligations start on September 11, 2026, and they apply to products already on the EU market, including devices you shipped years ago and have not touched since. If your CRA plan starts in 2027, you have already missed the first checkpoint.

The clock starts when you become aware that a vulnerability in your product is being actively exploited, rather than on the day the CVE is published. From that moment:

• Early warning: within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident
• Full notification: within 72 hours
• Final report: within 14 days of a corrective measure becoming available for a vulnerability, and within one month of the notification for a severe incident
• Where it goes: the single reporting platform, routed to the coordinating CSIRT in your Member State of main establishment and to ENISA

Twenty-four hours leaves no time to go find out what is inside a product. You either already know, or the window closes on you. That is why the September date, more than the 2027 date, should be driving your roadmap right now. Our CRA readiness work almost always starts here.

Mistake 2: Building the SBOM from the Build Manifest Instead of the Binary

Your build manifest tells you what you think you included. The binary tells you what shipped. Those two records disagree more often than anyone wants to admit, and the gap widens every time a third party touches your supply chain. Finite State researchers tear down shipped products every day, and the gap turns up in the teardown. In a Wansview WVC Q5 Wi-Fi camera sold as a baby monitor, we found CVE-2002-1819 in jdbhttpd/0.1.0, an outdated embedded web server that handed administrator credentials and cloud API tokens to a single unauthenticated request. No manifest in that supply chain declared the component, because no one who handled the product knew it was there.

A contract manufacturer swaps a library version. A vendor ships you a component with dependencies they never documented. A build script pulls a transitive package that never made it into your manifest. None of that shows up in a manifest-derived SBOM, which records intent rather than the artifact.

This matters most in the 24-hour window from Mistake 1. When a new vulnerability drops in a widely used library, the question is whether it is in the firmware sitting in customers' hands right now, and in which SKUs. A manifest cannot answer that. Binary software composition analysis can, because it reads the thing you released.

If you only fix one item on this list, fix this one. A software inventory built from shipped artifacts is the input everything else depends on.

Mistake 3: Treating CVE Count Like a Score

A team reports, proudly, that they drove open findings from 3,000 down to 2,000. Down from what, and reachable by whom?

Without reachability context, that number never measured risk. It measured how many CVE identifiers matched component versions in a scan. Some of those components cannot be reached from any external interface. Some are compiled out. Some are exploitable today on a device sitting in a hospital. The count treats all three the same, so a thousand fewer findings can mean a thousand hours of engineering time spent on the ones no attacker was ever going to reach.

Reachability analysis asks whether vulnerable code is present in the shipped build, whether execution can reach it, and whether anything outside the device can trigger that path. That turns a backlog into a priority list. We wrote about the mechanics in how reachability analysis transforms vulnerability management, and about the CRA-specific angle in reachability analysis for CRA vulnerability prioritization.

The Article 14 reporting trigger is active exploitation in your product, so a program tuned to exploitability rather than volume is already tuned to the regulation. Prioritization is one part of CRA vulnerability handling, and the rest of the Annex I, Part II obligations still apply alongside it.

Mistake 4: Assuming Compromise Happens After You Ship

A lot of supply chain risk is baked in before the device ever leaves the factory. A backdoored component. A poisoned build. A preinstalled piece of unwanted access that arrived with a supplier's image.

If your security program starts at deployment, you have skipped the part where the damage usually happens. Field monitoring and patch pipelines are necessary, and they sit downstream of the problem. Something compromised in the build is compromised in every unit that ships, and no amount of runtime telemetry undoes that.

The check that catches it is the same one from Mistake 2, applied earlier and more often: analyze the artifact you are about to release, compare it to what you expected, and investigate the difference. That check belongs in the release gate rather than the incident response plan. Treat it as the operational core of software supply chain security for connected products.

Mistake 5: Publishing a Disclosure Policy You Never Staffed

CRA's vulnerability-handling obligations include a coordinated vulnerability disclosure policy and a contact address that researchers can use. The obligation describes a working process: an address someone monitors, an owner who answers, and a record of what happened next.

The policy document is the easy part, and it is the part most teams finish. The harder questions are the ones an auditor and a security researcher will both ask:

• Who owns the intake queue this week, by name
• What happens in the first 24 hours after a researcher reports something exploitable
• How you determine which shipped products and versions contain the reported component
• Who has authority to decide a report qualifies as an actively exploited vulnerability
• Where the evidence of all of that gets stored for the technical file

The third question loops back to inventory again. You cannot triage a report in 24 hours if identifying affected products takes a week. Building the workflow behind the policy is what PSIRT rapid vulnerability response is for.

What the Five Mistakes Have in Common

Tie them together and the theme is obvious. Every one of these comes from working off what you assume is in the product instead of what is verifiably there.

The date mistake is a visibility problem, because the September obligation is unmeetable without inventory. The manifest mistake is a visibility problem by definition. The CVE count mistake is what happens when you have a list of components but no context about them. The pre-ship mistake is a visibility problem that starts at the supplier. The disclosure mistake is an organizational one, and it gets easier when you can answer "which products are affected" in minutes.

Fix the visibility problem and mistakes one through four solve themselves.

FAQ

When do CRA compliance obligations start?

Vulnerability and incident reporting obligations under Article 14 apply from September 11, 2026, including for products already on the EU market. The remaining requirements, including secure-by-design obligations, technical documentation, SBOMs, and CE marking, apply from December 11, 2027.

Does the CRA require an SBOM?

Yes. Annex I, Part II requires manufacturers to identify and document components, including an SBOM in a commonly used machine-readable format covering at least the product's top-level dependencies. That obligation sits with the December 2027 requirements, and you need component-level inventory well before then to meet the 2026 reporting timeline. You cannot report on an actively exploited vulnerability within 24 hours if you do not know which products contain the affected component. See our guide to CRA SBOM and technical documentation requirements.

What is the difference between a manifest-based SBOM and a binary-based SBOM?

A manifest-based SBOM is generated from build configuration files and lists the components you intended to include. A binary-based SBOM is generated by analyzing the compiled artifact and lists what is present in the software you shipped, including components added by suppliers, contract manufacturers, or build tooling.

Do CRA reporting obligations apply to legacy products?

Yes. Products with digital elements already on the EU market are in scope for reporting from September 11, 2026, regardless of when they were first placed on the market.

What counts as a reportable vulnerability under the CRA?

The reporting trigger is awareness that a vulnerability in your product is being actively exploited, or a severe incident affecting the security of the product. That is a much narrower set than your CVE backlog, which is one reason CVE count is a poor measure of CRA exposure.

Where to Start

Pick the mistake that is costing you the most and start there. For most teams that is inventory, because it is the input to everything else on this list.

If your September 11 plan is still a spreadsheet, we can help. Finite State's CRA services combine binary-level analysis of what you ship with evidence mapped to CRA requirements, and our Certification Accelerator assembles the technical file behind it with your team.

Request a CRA walkthrough and we will show you how a shipped firmware image comes apart: the components inside it, which of them carry actively exploited vulnerabilities, and the evidence trail behind each call.