The tailor-made exception is narrow. Recital 64 and Annex I allow deviation from secure-by-default configuration only for tailor-made products fitted to a particular purpose for a particular business user, where the manufacturer and that business user explicitly agree to different contractual terms.
The Commission FAQ says this may cover custom-developed hardware or software for a specific business user, or products developed for integration into a specific customer's highly controlled environment. It does not cover ordinary enterprise products, minor customisations, CRM platforms sold to multiple businesses, or platforms that remain fundamentally the same product while being customised through plugins or APIs.
Section 4.2.5 explains what is and is not tailor-made and gives examples involving custom products, controlled environments, CRM platforms, plugins, and APIs.
Does the tailor-made exception waive all CRA requirements?
No. The Commission FAQ states that the tailor-made deviation concerns two requirements: secure-by-default configuration in Annex I Part I point (2)(b), and free-of-charge security updates in Annex I Part II point (8). It is not a general waiver from Annex I, vulnerability handling, risk assessment, technical documentation, user information, or conformity obligations.
A manufacturer relying on the exception should keep evidence that the product is genuinely fitted to a particular purpose for a particular business user, that different contractual terms were explicitly agreed, and that the remaining applicable CRA requirements are still addressed.
Annex I Part I point (2)(b), Annex I Part II point (8), Article 31, and Annex VII frame the limited deviations and technical documentation expectations.
What evidence should a manufacturer keep for secure-by-default decisions?
Keep the risk assessment showing which Annex I Part I product-property requirements apply, the threat model and assumptions for intended purpose and reasonably foreseeable use, the default configuration inventory, the rationale for enabled and disabled services or interfaces, authentication and access-control defaults, update-default behavior, logging and monitoring defaults, and data minimisation decisions.
The technical documentation should also include user information and instructions, the design and architecture information needed to assess conformity, descriptions of vulnerability handling and secure update distribution, descriptions of solutions adopted to meet Annex I where harmonised standards or common specifications were not applied, and reports of tests verifying conformity.
Article 13(4), Article 31, and Annex VII require technical documentation covering the risk assessment, user instructions, design and development information, adopted solutions, and test reports.
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.
Under the CRA, 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.
Annex I Part I point (2)(c) requires automatic security updates only where applicable; recital 56 explains product categories where users may not expect them.
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.
Under the Cyber Resilience Act, is the manufacturer responsible if a user refuses or fails to install a security update?
No.
The Commission FAQ states this directly. The manufacturer must make the update available through the required mechanisms and keep users informed, but is not responsible under the CRA if the user does not install the update.
Under the CRA, if a vulnerability cannot be fixed adequately, can withdrawal or recall become necessary?
Yes, in exceptional cases.
Article 13(21) requires corrective measures to bring the product or the manufacturer's processes into conformity, or withdrawal or recall as appropriate. The Commission FAQ explains that this may become necessary where a serious vulnerability cannot be adequately remediated.
Even when CRA automatic updates are not applicable, must the manufacturer still inform users about vulnerabilities and make security updates available?
Yes.
Recital 56 states this expressly. Even where a product is not designed to receive automatic updates, the manufacturer should still inform users about vulnerabilities and make security updates available without delay.
Under the Cyber Resilience Act, must a manufacturer keep delivering security fixes for every historical version of a software product?
Not always.
Article 13(10) allows the manufacturer, under specific conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of the earlier versions can access that latest version free of charge and without additional costs to adjust their hardware or software environment.
Article 13(10) and recital 40 allow remediation for the latest substantially modified software version only when earlier-version users can move free of charge and without additional environment costs.
Under the CRA, if earlier versions can move to the latest substantially modified version, does that end all obligations for the older versions?
No.
Recital 40 says the manufacturer may limit remediation to the latest substantially modified version only under the Article 13(10) conditions, but other vulnerability-handling obligations still continue for all subsequent substantially modified versions placed on the market. The same recital also says minor security or functionality updates that do not amount to a substantial modification may be provided only for the latest version or sub-version that has not been substantially modified.