First FAQ on the Cyber Resilience Act

The authors of this blog are participating in the EU-funded project CRACY, helping SMEs understand and comply with the Cyber Resilience Act.

On 3 December 2025, the European Commission has adopted a frequently asked questions document on the Cyber Resilience Act (CRA), providing further clarification and examples on how manufacturers should approach the forthcoming compliance obligations for their products with digital elements (PDEs).

For a more general discussion of the CRA contents and scope, please see our previous blogpost on the topic.

While the FAQ addresses a large variety of topics in the regulation, the sections on manufacturer obligations in its Chapters 4 and 5 are particularly revealing, and frankly, quite demanding. As opposed to a concrete view of the manufacturer’s risk assessment obligations, the picture that emerges is one where manufacturers are expected to function as theoretical cybersecurity experts, with especially far-going obligations when it comes to risk assessment and component integration. Notable missing areas are information on free and open-source software as well as remote data processing solutions. This lack of information may be due to future guidance under Article 26 of the CRA (hopefully) coming out later this year or in the beginning of 2026.

This blog post examines three critical areas where the FAQ provides important clarifications:

1. Risk assessment requirements
2. Essential requirements for products with digital elements
3. Vulnerability handling obligations

The FAQ makes clear that the CRA’s risk assessment requirements are comprehensive and demanding, yet without imposing a binding framework. Manufacturers must conduct thorough assessments covering risk identification, analysis, and evaluation, as well as risk treatment throughout the entire lifecycle (i.e., from design and development through production, delivery, and maintenance).

There is no one-size-fits-all framework. The FAQ emphasizes context-specific threat modeling. Manufacturers must tailor their risk assessments to the specific situation in which their product will be used. A product destined for critical infrastructure and operated by trained personnel in a factory setting presents a very different risk profile than the same technology deployed as a consumer good in homes. This context-sensitivity is sensible in theory but adds layers of complexity in practice.

Perhaps the most striking aspect of the risk assessment requirements concerns “intended purpose”and“reasonably foreseeable use or misuse”. Even though these are concepts from other EU harmonisation legislation, they pose particular challenges in the context of the CRA, where the regulation applies to a large variety of technologies, ranging from the smallest IT to the largest OT systems. In that context, the FAQ does not mitigate their application but rather places a particularly heavy burden on manufacturers, especially those producing components that may be integrated into other products.

Manufacturers must consider both downstream integration and end-use scenarios. If your product might be incorporated as a component in another manufacturer’s product, you need to think through the relevant risks related to different types of integration. The FAQ essentially asks component manufacturers to envision all the things their chip, module, or component could be used for. This lays the threshold of what is “reasonable” quite high. It is a significant analytical burden that may be challenging for SMEs but also manufacturers of versatile components with broad potential applications.

The FAQ goes further still. Some user modifications are characterized as “reasonably foreseeable use”. Manufacturers should explicitly identify risks associated with user modifications, implement treatment measures, and provide appropriate information and instructions to users about these modification possibilities.

The FAQ even extends to reasonably foreseeable misuse, offering the example of ethical hacking by users. Manufacturers are expected to communicate risks related to such scenarios. The implications are somewhat startling: manufacturers may effectively need to provide risk assessments for scenarios where users deliberately dismantle or probe their products. This represents a considerable expansion of traditional product safety thinking.

As if the existing requirements were not demanding enough, the FAQ suggests that manufacturers may consider reasonable projections about changes in the threat landscape and how these might impact risk assessment throughout the product’s lifetime. This forward-looking obligation asks manufacturers not just to assess current risks, but to anticipate how cyber threats might evolve over the years their product remains in service. It is unclear how far one must go. It might be possible to think that this could boil down to a standard boilerplate phrase stating that quantum computing and AI may disrupt every part of cybersecurity as we know it. However, actually looking into the future in risk assessments is likely to be a lot more demanding.

The FAQ also emphasizes that using harmonized standards does not guarantee full compliance with risk assessment obligations. While harmonized standards do provide a presumption of conformity, manufacturers retain ultimate responsibility for ensuring their risk assessment is complete and accurate. This is another area where the FAQ clarifies that manufacturers cannot simply rely on established frameworks but must exercise independent judgment and expertise.

The FAQ provides important clarifications on when manufacturers must address vulnerabilities in their PDEs.

Manufacturers must make PDEs available without known exploitable vulnerabilities. However, the FAQ offers some relief: vulnerabilities that exist only in theoretical conditions, such as laboratory settings or simulations, or in situations that would not occur in the product’s actual operational environment, do not trigger this obligation. They are not “exploitable”. That said, given the expansive interpretation of “reasonably foreseeable use and misuse” discussed above, the operational environment may be broader than manufacturers might initially assume.

The FAQ also clarifies that manufacturers are not required to fix newly discovered vulnerabilities in the window between placing a product on the market and it reaching the end user. This would for example be the case where a product is sitting on the shelves in a store, prior to being bought. However, vulnerability handling obligations do apply during the support period once the product is put in operation.

An important clarification concerns the “secure by default” requirement. This obligation applies only to components placed on the market separately, not to how those components are later configured or deployed by integrating manufacturers.

This creates an interesting market dynamic. It will be easier to assemble products and integrate components outside the EU, then place only the final PDE on the European market. Under this approach, individual components do not need to fulfil the essential requirements, including secure by default, as long as the final product does. The burden is therefore shifted onto the final integrator. This may influence supply chain strategies and where in the production process EU compliance becomes critical.

Related to this, the FAQ confirms that integrating manufacturers are not required to ensure that all components used in their products meet every essential requirement independently. The manufacturer’s responsibility takes effect when they place the product on the market. Manufacturers will have to perform a due diligence assessment of the components to ensure that the final PDE conforms to the essential requirements.

The FAQ takes a pragmatic, risk-based approach to vulnerability management that will be welcome news for many manufacturers.

The FAQ states that manufacturers are not required to provide a patch for all discovered vulnerabilities. Depending on “exploitability” levels, it may not be necessary to implement a separate update if there is no actual risk of the vulnerability being exploited in practice. It does state that every discovered should be remediated somehow, but that a patch may not always be the most appropriate solution. In very low risk cases, the FAQ states that documenting the vulnerability and providing recommendations to users may be enough in terms of remediation. This risk-based approach to remediation is a welcome tool for manufacturers.

Similarly, product recalls due to unfixable vulnerabilities should be exceptional, required only when the vulnerability presents a very significant risk of compromise. This aligns with the principle that not every vulnerability demands the most extreme response.

A particularly significant clarification concerns products that integrate components not originally placed on the EU market, or components placed on the market before the CRA became applicable. In these cases, the integrating manufacturer is tasked with addressing the vulnerabilities in those components itself. The component manufacturer has no obligation to assist, as they are not in scope of the CRA. This same principle applies when a component’s support period has ended but the integrated product’s support period continues.

This creates a substantial responsibility for integrating manufacturers. They must conduct due diligence when selecting components and be prepared to take on long-term vulnerability management for components whose original manufacturers may no longer be supporting them.

The FAQ clarifies the notification requirements when vulnerabilities are discovered in integrated components. If there is an actively exploited vulnerability in a component, both the PDE manufacturer and the component manufacturer must provide notification. However, if a vulnerability exists but is not being actively exploited, the integrating manufacturer must notify the component manufacturer but is not required to notify end users.

One area where the FAQ provides relief: manufacturers have no duty to carry out continuous monitoring of vulnerabilities or actively scan for them. While manufacturers must handle vulnerabilities responsibly when they become aware of them, there is no obligation to maintain constant surveillance for potential security issues.

The FAQ makes clear that manufacturers face substantial obligations throughout the product lifecycle. The burden is particularly heavy during the design and development phase, with its demanding risk assessment requirements, but as the FAQ emphasizes, obligations during the maintenance and support period are equally significant.

This is only the beginning of the Commission’s guidance efforts. Article 26 of the CRA mandates additional guidance on several topics, including the scope of the regulation with particular focus on remote data processing solutions and free and open-source software, the application of support periods for particular product categories, guidance for manufacturers subject to both the CRA and other EU harmonization legislation, and the concept of substantial modification.

While this FAQ does address the interplay with other harmonisation legislation to some extent, gaps remain. For instance, manufacturers working under both the Machinery Regulation and the CRA would benefit from clearer guidance on how to align technical documentation and risk assessment requirements across both frameworks.

Manufacturers should begin preparing now for these demanding requirements, particularly if they produce components that may be integrated into other products or if they themselves integrate third-party components. The days of cybersecurity as an afterthought are definitively over under the CRA regime.

Authors

Wout Platteau and Pedro Demolder