EU Cyber Resilience Act FAQ Secure by Default

The CRA requires products with digital elements to be made available on the market with a secure-by-default configuration, based on the manufacturer's cybersecurity risk assessment and in light of the product's intended purpose and reasonably foreseeable use.

This is not a generic slogan. It is a concrete Annex I requirement.

No.

The default configuration has to be determined through the risk assessment for the specific product. What is secure by default for one product category may not be secure by default for another.

No.

The CRA ties the default configuration to the product's intended purpose, reasonably foreseeable use, and the manufacturer's cybersecurity risk assessment. So the legal test is not whether the product is maximally locked down in the abstract, but whether its default configuration is secure for the way the product is meant and reasonably expected to be used.

That depends on the product, but the CRA and Commission materials point toward defaults that reduce cybersecurity risk at first use.

The Commission FAQ gives examples such as insecure or deprecated cryptographic algorithms being disabled by default, certificate validation being enabled by default, or network interfaces being disabled by default until needed.

Yes.

Annex I Part I, point (2)(b) expressly includes the possibility to reset the product to its original state.

Where applicable, yes.

Annex I Part I, point (2)(c) says vulnerabilities must be addressable through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe and enabled as a default setting. That default setting must come with a clear and easy-to-use opt-out mechanism and the option to postpone updates temporarily.

Yes.

The CRA requires a clear and easy-to-use opt-out mechanism and an option to postpone updates temporarily. Annex II also requires instructions on how the default automatic-installation setting can be turned off.

No.

Recital 56 says the automatic-update expectations do not apply to products primarily intended to be integrated as components into other products. It also says they do not apply to products for which users would not reasonably expect automatic updates, including products intended for use in professional ICT networks and especially in critical and industrial environments where automatic updates could interfere with operations.

Yes.

Recital 56 says that irrespective of whether a product is designed to receive automatic updates, the manufacturer should inform users about vulnerabilities and make security updates available without delay.

Not automatically, but the manufacturer is not responsible under the CRA for the user's refusal to install updates.

The Commission FAQ says the manufacturer is not responsible if the user does not install security updates, including where the user opts out. But the manufacturer still must design the product and its processes so updates can be distributed, notified, and installed as required.

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.

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.

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.

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.

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.

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.

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.

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.