CRA Readiness Takes More Than Reading the Regulation
The regulation establishes what manufacturers have to achieve, but it doesn’t tell you how. Filling that gap takes human expertise and judgment – and time to act on it.
Doc McConnell
Head of Policy and Compliance
A few days ago, ETSI opened the public comment period on 17 draft standards written to support consistent implementation of the EU Cyber Resilience Act (CRA). This helps to answer a key question for product manufacturers: exactly what they’ll need to do to meet the essential cybersecurity requirements in the CRA.
Even though these standards are a step in the right direction, they still require judgment calls by manufacturers. Consider this requirement for smart home security products: “Where … automated installation of updates does not create an unacceptable risk to essential function availability or safety, the [smart home security product] shall support the automated security update of its software within an appropriate time frame.” Deciding how to implement this will require subjective determinations: what constitutes “unacceptable” risk, “essential function availability,” or an “appropriate” time frame?
Answering these questions requires expertise both in product security and in policy compliance. It requires balancing judgment calls about the capabilities and limitations of the products with informed opinions about how different product choices will be viewed by regulators. These questions mean that the most useful CRA work I’ve done so far has looked less like an audit and more like a strategy meeting: reasoned trade-offs between valid options, informed by the costs and benefits of each.
What the Regulation Doesn't Tell You
Most of the product security leads I work with have read Annex I. They know the Article 14 reporting obligations take effect on September 11, 2026, and they have a working view of the conformity assessment procedures. The program stalls when questions come up that the regulation text doesn’t answer:
Which products are actually in scope? And which scope applies? The CRA regulates individual products with digital elements rather than whole industries, so applicability is a determination made product by product. This is harder for manufacturers in certain industries, like automotive suppliers, since the CRA exempts finished vehicles but may apply to components in the supplier’s catalog. Portfolios with regional variants, white-label builds, and dual-use modules take real work to sort, and certain devices may fall into a grey area between “default” and “important” products with digital elements. It’s important to get those decisions right up front, since they affect engineering decisions down the road.
What level of security is “good enough”? The draft ETSI standards now open for comment are vertical product standards; the horizontal standards that will apply across every product category are still in development at CEN/CENELEC. And nothing has been cited in the Official Journal, which means the harmonized standards may still change. In the meantime, manufacturers have product decisions to make now, based on incomplete information. Wading through the existing standards—IEC 62443 for industrial control systems, ISO/SAE 21434 for automotive, or FDA cybersecurity requirements for medical devices—to guess at the right security controls now carries real risk. This is an area where specialized compliance guidance and expertise can help a company make decisions confidently. A third-party perspective on internal product security is also itself a valuable artifact. A reputable security company can provide assurances and evidence to company management, boards, and auditors or regulators to reinforce that the product meets stringent security standards.
How to react under pressure. The CRA requires reporting actively exploited vulnerabilities in a product to ENISA within 24 hours after becoming aware of it, with additional information due within 72 hours and a final report within two weeks of a mitigation becoming available. Deciding what vulnerabilities to report, what information to share, what an effective mitigation should look like, and how to communicate with affected customers is a complex task, made harder by the tight CRA timelines. An experienced external team can help guide a company through these decisions, point-by-point, and provide documentation to back up those decisions.
None of these questions are answered by a straight read of the CRA. These decisions all live in the gaps in between the regulatory requirements. Professional advisory services can help fill those gaps by bringing together the capability to analyze firmware for vulnerabilities, respond effectively to a product security incident, and develop regulator-ready documentation.
Making Decisions Before the Answers Arrive
The instinct to wait for clarity is reasonable. Designing against a draft standard that could still change risks wasting effort, and no one wants to build a control set twice.
That is the wrong instinct for the CRA. Manufacturer requirements begin to take effect in under a month, and the timeline to finalize and harmonize the standards is still unknown. Even on an optimistic path, the EU is unlikely to make these decisions before manufacturers have to schedule their 2027 product releases.
There is also a straightforward economic argument for deciding early: it’s cheaper to build controls early than to retrofit them later. During a period of uncertainty, relying on expert guidance to select those controls is a responsible, defensible decision, especially when those experts provide documentation to back them up. When the standards do land, you are building from a strong foundation, not scrambling to make up for lost time.
What the Finite State Managed CRA Service Produces
At Finite State, we offer a managed service that combines our engineering expertise and security platform with experienced, expert advisors. We run the program as a continuous engagement for a single product, or an entire portfolio, with five outputs maintained across every release:
- A living SBOM, generated from the product firmware and binaries, exportable in CycloneDX and SPDX, and updated on each new release. Binary analysis needs no source code, which is what makes legacy products workable. Every other output builds on this one.
- A cybersecurity risk assessment, with threat modeling, control mapping, and gap analysis aligned to CRA Annex I, grounded in what the binary analysis actually found. Auditors and customers asking what you did to secure the product get a documented answer.
- Continuous vulnerability monitoring, correlating your SBOM against 250+ intelligence sources, with VEX-backed context maintained over time and notifications when a finding reaches your designated product.
- Managed disclosure support, including draft documentation for the 24-hour, 72-hour, and 14-day filings, a CVD policy template, and up to 15 managed drafts per service period. Submission stays with you.
- A technical documentation package and DoC template, assembled per Annex VII, with a Declaration of Conformity template formatted to Annex V and essential-requirements traceability to Annex I.
The engagement is scoped to the products you need covered and maintained for 12 months, to get the products ready for self-assessment. Setup runs about two weeks from the point we have the binary and basic product context, so a team starting now is operational before the reporting obligation applies.
Our platform and our analysts handle the mechanical work, maintaining the binary-derived SBOM, the correlation, the reachability analysis, the VEX record, and the documentation package as one governed record. Engineers on your side stop assembling component lists and just review a final version. A drafted notification is waiting when your PSIRT lead needs one. Self-assessment begins from an Annex VII package that has been maintained release over release. You stay in control of all the judgment calls; we give you the information and evidence you need to make them confidently.
Questions Worth Asking Before September 11
If you want a quick read on where your program stands, these are the questions I would put to your team this month:
- Do you know which of your products fall under which CRA requirements? Can you defend that decision?
- What security controls are you selecting, and how are you making those choices?
- When an actively exploited CVE lands, can you establish within hours whether the vulnerable code is present and reachable in your build, rather than merely listed in your inventory?
- Who writes, reviews, and approves the early warning notification to ENISA during a product security incident? Can they do it in 24 hours?
- Do you have a current SBOM for every product you might have to report on, derived from what actually shipped rather than from a build manifest?
Teams need to answer all five to be compliant in September 2026 and to have a foundation for December 2027.
The Payoff Runs Past September
September 11 is the immediate deadline, but the value of an advisory partnership continues to grow over time. We will see additional draft CRA standards released, changes to the existing drafts as they are finalized, and decisions made by market surveillance authorities that contradict prevailing assumptions. Manufacturers will be best positioned to navigate this uncertainty when they can turn to proven expertise and sound, expert judgment.
An advisory partnership also serves a valuable role in ongoing product security governance and risk management, by offering third-party validation of the product security team’s work. Over time, this external perspective helps both to steer important strategic decisions and to provide objective evidence of the product’s quality, reassuring consumers and adding value to the company’s reputation and brand.
Not sure where your products stand? Let’s have a conversation. Short on time? Our managed CRA service lets you scale your existing team. Request a CRA consultation →
