How does CRA secure by default work for components sold for integration into other products?
The component manufacturer is responsible for the configuration in which the component is placed on the market separately. The component manufacturer is not responsible for how an integrating manufacturer later reconfigures or deploys that component.
The Commission FAQ gives this directly for products such as cryptographic libraries and microcontrollers sold for integration.
Can a manufacturer rely on setup instructions instead of shipping the product in a secure default state?
No.
The CRA requires a secure-by-default configuration at placement on the market. The March 2026 draft guidance also says that information to users cannot be used to compensate for product-design shortcomings or to justify leaving incompatible risks untreated.
Can the secure-by-default requirement ever be inapplicable to a product?
Yes, but only on a documented, risk-based basis.
If the manufacturer concludes that a requirement is not applicable, Article 13(4) requires a clear justification in the technical documentation. The Commission FAQ says this can be the case where the requirement is incompatible with the nature of the product or where the risk assessment shows no relevant risks requiring that mitigation. But if the manufacturer still identifies cybersecurity risks in relation to that requirement, it has to address those risks by other means, for example by limiting the intended purpose to trusted environments or informing users about the risks.
Is there any exception to the secure-by-default requirement?
Yes, but it is narrow.
Annex I allows deviation only where the product is tailor-made, fitted to a particular purpose for a particular business user, and the manufacturer and that user have explicitly agreed to different contractual terms. That exception does not create a general enterprise-product carve-out.
Are ordinary enterprise products or lightly customised products automatically "tailor-made" for this exception?
No.
The Commission FAQ says a product is not tailor-made merely because it undergoes minor customisations before sale. It gives examples such as a CRM platform sold to multiple businesses, or platforms customised through plugins or APIs while remaining fundamentally the same product for every customer.
Does the tailor-made carve-out let the manufacturer deviate from any CRA requirement it wants?
No.
The Commission FAQ says the CRA allows deviation only from two essential requirements in this context: secure-by-default configuration in Annex I Part I point (2)(b), and the requirement to provide security updates free of charge in Annex I Part II point (8). It is not a general waiver from other Annex I requirements.
If secure by default is not applicable because of the product's nature or interoperability needs, can the manufacturer simply omit equivalent safeguards?
No.
Where an essential cybersecurity requirement is not applicable but related cybersecurity risks still exist, the CRA materials say the manufacturer should address those risks by other means. The examples given are limiting the intended purpose to trusted environments or informing users about the risks.
What does the manufacturer need to document about secure by default?
The manufacturer needs to document how the product complies with the relevant essential cybersecurity requirements, including the secure-by-default requirement where it applies. If the manufacturer concludes that the requirement is not applicable, that justification must be documented. If the manufacturer relies on the tailor-made exception, the technical documentation should also contain relevant evidence showing that the product is genuinely tailor-made.
That matters because secure by default is not just a design aspiration. It forms part of the manufacturer's conformity case under Article 13(4) and Article 31.
Does the CRA require manufacturers to patch every vulnerability they discover during the support period?
No.
The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed. The Commission FAQ explains that this does not mean every vulnerability must receive a dedicated patch. The response depends on the risk assessment.
If not every vulnerability needs a dedicated patch, what other remedies can satisfy the CRA?
The Commission FAQ says remedies can take different forms depending on the risk. These can include immediate patches, advisories on workarounds, configuration guidance, updates to user manuals, later software updates, or other mitigation measures.
Must security updates be provided separately from functionality updates?
Yes, where technically feasible.
That is the rule in Annex I Part II point (2). Recital 57 explains that the purpose is to avoid forcing users to install functionality changes just to receive the latest security fix.
Why does the CRA push for separation between security and functionality updates?
To improve transparency and to ensure users are not required to install new functionality updates for the sole purpose of receiving the latest security updates.
Can a manufacturer still combine a security update with a functionality change?
Yes, if separation is not technically feasible.
The Commission FAQ gives the example of a vulnerability fix that requires replacing a parser with a safer one that changes some functionality. In that situation, the CRA does not require strict separation.
Can a functionality change itself be the security fix?
Yes.
The Commission FAQ explains that disabling or changing a vulnerable function can itself be the security update. The key point is whether the change is needed to address the vulnerability.
Must CRA security updates come with user-facing guidance?
Yes.
When security updates are available to address identified security issues, they must be accompanied by advisory messages with the relevant information, including potential action users should take.
Does the CRA require secure update-distribution mechanisms?
Yes.
Manufacturers must provide mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner.
Are CRA automatic security updates always required for every product?
No.
The CRA requires products, where applicable, to support automatic security updates with default enablement, an opt-out mechanism, notifications, and the option to postpone. Recital 56 and the Commission FAQ explain that automatic updates are not always applicable, especially for components and for products where users would not reasonably expect automatic updates, including some professional and industrial environments.
If CRA automatic updates are used, must users still be able to opt out or postpone installation?
Yes.
Annex I Part I point (2)(c) requires a clear and easy-to-use opt-out mechanism and the option to temporarily postpone updates. Recital 56 adds that users should retain the ability to deactivate automatic updates.