Why Automation Is Essential to Achieve EU CRA Compliance

By Colin Duggan, CEO and co-founder, BG Networks

Many companies are still unfamiliar with the EU Cyber Resilience Act (CRA), and even among those that are aware of it, there are significant misconceptions about both its scope and the amount of work required to achieve conformity. Some still view the CRA as a future-focused regulation that primarily affects new products developed after its obligations apply in December 2027. That is a dangerous misunderstanding. The practical question is not whether a product was originally designed in 2027, 2020, or 2012, but whether a product with digital elements will continue to be placed on the EU market after the CRA goes into effect. For large manufacturers, this can bring thousands of existing and legacy products into scope, including products designed long before cybersecurity was treated as a formal requirement. Conforming those products is also far more than a documentation exercise: each connected product requires a cybersecurity risk assessment, implementation of security features based on that assessment, technical-conformity documentation, vulnerability-handling processes, and a support-period strategy. For companies with large product portfolios, understanding the true scale of this effort is one of the first and most important steps toward CRA readiness.

The Scope of the CRA

The European Commission describes the CRA as applying to hardware and software products with digital elements made available on the EU market.

So, are your products in scope? A simple starting point is this: if the product is software or hardware and it has a data connection, it will be in scope. That connection can be direct or indirect. It can be logical or physical. It does not have to look like a classic internet-connected IoT device. That means the CRA applies to software products, embedded systems, industrial devices, consumer devices, networking products, hardware components, and semiconductors when they meet the connectivity test. In other words, the CRA is not just an IoT regulation. It is a broad product cybersecurity regulation applicable to any connected software and hardware that is not already covered under existing regulations such as UNECE’s R.155 cybersecurity for vehicles and the EU’s Medical Device Regulation (MDR).

Figure 1: the broad product scope of the EU CRA

Once a product is in scope, the manufacturer must do much more than run a scanner or create an SBOM. The CRA requires a product-level conformity workflow. For each product, the manufacturer needs to:

determine whether the product is in scope
determine whether it falls into the default, important, or critical categories
perform a cybersecurity risk assessment
determine which cybersecurity requirements apply and how they are or will be implemented
generate a SBOM and disposition any vulnerabilities found
generate and maintain technical documentation, and
complete the appropriate conformity assessment process before placing the product on the EU market.

Two Annexes That Define the CRA Workload

Two CRA annexes are especially important for understanding why achieving product-level conformity becomes such a large workload.

Annex I contains the essential cybersecurity requirements:

Part I addresses product cybersecurity features that are required, such as protection against unauthorized access, confidentiality, integrity, availability, and secure update capabilities.
Part II addresses vulnerability handling during the support period and relates to both processes within a company as well as the features in the device or software.

The Commission summarizes Annex I as the list of essential cybersecurity requirements that manufacturers must satisfy when designing, developing, producing, and supporting products with digital elements.

Annex VII defines the technical documentation that must be created and kept available for market surveillance authorities. This documentation is the evidence package that shows what the product is, how it was assessed, what requirements apply, and how the manufacturer demonstrates conformity. The CRA states that manufacturers must draw up technical documentation before placing a product with digital elements on the market and then keep that documentation available to authorities for 10 years after the product is placed on the market.

This Is Where the Portfolio Problem Begins

For a company with a small number of products, manual CRA readiness is possible.

Figure 2: Time to prepare one product for EU CRA conformity, including product/system analysis, cybersecurity threat & risk assessment, Annex I applicability analysis, security-control identification, gap analysis against risks & Annex I, and document generation. Does not include SBOM generation, disposition of vulnerabilities found from SBOM analysis, engineering changes to add features to remediate risks, third-party conformity assessment/certification, other organizational or process activities, and ongoing vulnerability monitoring.
Sources: BG Networks customer engagements, European Commission “Commission Staff Working Document Impact Report.”

But for a company with hundreds or even thousands of products, the number of products multiplied by the number of required tasks creates a workload that results in many person-years of work. Each product requires a category determination, threat and risk assessment, Annex I requirement mapping, internal review, and evidence management, as shown in Figure 2. Some artifacts can be reused across product families, but every product still needs a defensible product-specific record. Even a modest amount of effort becomes enormous at portfolio scale. If the portfolio is complex, poorly documented, or full of legacy products that have limited cybersecurity, that hourly total can rise astronomically.

The exact effort depends heavily on the makeup of a company’s product portfolio. A company with many unique architectures will require more time. A company with strong product-family reuse will require less time. For a portfolio where roughly 10% to 15% of the products are core products and the rest are derivatives where CRA artifacts can be reused, a reasonable planning estimate is still about 30 to 50 hours of work per product on average for execution of the CRA workflow. For 1,000 products, that means 30,000 to 50,000 hours. At roughly 1,700 actual working hours per person-year, that equates to about 18 to 30 person-years of work. For larger portfolios, the problem is multiplied.

Figure 3: Preparation timing for a large product portfolio (1,000 in-scope products);
Sources: BG Networks analysis from customer engagements

These estimates also assume the organization already understands the EU CRA, cybersecurity engineering & methodologies, and how to generate technical security controls. They do not include the time required for personnel to learn the regulation, interpret evolving guidance, train product teams, or become proficient in cybersecurity risk methods. They also do not include product redesign if the risk assessment reveals cybersecurity feature gaps.

So, can your organization find people who understand the regulation and product cybersecurity and staff the task, meeting the mandated deadline of December 11, 2027? Probably not. Finding folks who understand product cybersecurity is challenging as it is very different from enterprise cybersecurity.

Here’s where AI and automation step in.

AI and Automation Make the Task Feasible

AI-driven automation significantly changes the scope of the task by reducing the time needed to complete the CRA workflows. Instead of asking engineers or compliance teams to start every product from scratch, an automation platform can process product documentation, such as a data sheet or user manual, and quickly generate a view of whether the product is in-scope or out-of-scope. It considers the intent of the product, interfaces, connectivity, software or hardware characteristics, and other facts needed for the first stage of CRA analysis. It subsequently generates the required threat and risk assessment, maps relevant cybersecurity requirements to reduce risk, and creates documentation.

Figure 4: Time to prepare one product for EU CRA conformity using automation.

The most important time savings come from eliminating repetitive manual work. A human expert should not need to follow the same threat-model and risk assessment process hundreds of times. A product-security lead should not need to manually reconstruct similar Annex I mappings for every product variant. A compliance team should not need to build technical documentation packages from scratch every time a product family has a derivative.

Figure 5: Time savings from automated EU CRA preparation vs. manual methods for representative large product portfolio

Automation allows the organization to create structured product records, reusable analysis patterns, consistent ratings of risk, and documentation outputs. The humans still make the important decisions. They review the generated analysis, correct assumptions, confirm technical facts, approve risk conclusions, and decide what product gaps need remediation. Automation does not remove cybersecurity expertise from the process. It makes that expertise go much further.

Bridging the Expertise Gap with a Boost from Automation

Automation is especially important because most large companies operate with an organizational structure that has a single central cybersecurity team and many product development teams. The central security or compliance team usually understands the regulation best, but they are bandwidth limited. The distributed development and business teams understand the products best and need to make the tradeoffs if investments are needed to reach conformity. A manual approach puts both groups in a tenuous position. The central team cannot manually produce and normalize every risk assessment and technical file across the entire portfolio. The distributed teams do not have the time or bandwidth to become experts in the complex CRA regulation and assessing conformity.

A better operating model is for the central team to use automation to generate all needed CRA information at scale. The distributed product/business teams then review the generated output. They correct product-specific assumptions, clarify the intent of the device, and make product-related gap and remediation decisions. This model leverages centralized CRA expertise while still relying on the products/business teams to make decisions that impact products. It also gives the organization a consistent workflow instead of asking each business unit to invent its own spreadsheet-based process.

Preparing to Leverage Automation

Companies that want to move quickly should not begin by trying to manually write technical files for every product. The better first step is to prepare the portfolio for automated analysis. Step one is simple: gather available documentation for all products including those that may be in scope and products that may be out of scope. Step two is to use automation to process those documents and identify which products are actually in scope for the CRA. That gives the organization a practical starting point instead of forcing teams to inspect every product manually. Step three is to run a pilot for a small number of representative products. The goal of the pilot is to generate threat and risk assessments, understand what security information the CRA requires, identify common documentation gaps, and learn how the review process should work.

This does not need to be a year-long readiness exercise. A company can gather basic product documents, process a representative set of products, and begin understanding its CRA exposure in a matter of weeks. That early work gives leadership a much clearer view of the portfolio: which products are impacted and how much work will it take to bring the portfolio into conformity. It also helps the central product-security and compliance teams build a repeatable operating model before the full portfolio workload arrives.

The EU CRA’s impact comes from the combination of broad scope and product-by-product conformity work. Software, hardware, connected systems, embedded devices, semiconductors, industrial products, consumer devices, and networking equipment can all be pulled into the CRA’s large net when they have digital elements and data connections. For companies with large portfolios, the problem is not simply understanding the regulation. The problem is applying it across thousands of products, many of which were designed before cybersecurity was treated as a core product requirement. Manual work may help companies begin, but it cannot scale the hours, consistency, and documentation required for portfolio-wide conformity. The number of hours required for a large portfolio can reach above 30 person years; this is not only schedule prohibitive given the EU CRA deadline, it also has a huge financial impact, with costs potentially reaching in the multi-millions of dollars range. Automation is the practical path to determining impact, generating risk assessments, identifying required security controls, and moving large portfolios toward EU CRA readiness.

This article was originally published on EE Times DesignLine.