Search every question across sub-FAQs

Charging a price for the product is the obvious commercial signal, but recital 15 is broader. It also points to paid technical support beyond actual cost recovery, an intention to monetise related services, requiring personal-data processing as a condition of use for reasons beyond security, compatibility, or interoperability, and donations exceeding costs.

For a bespoke engagement, assess whether the product with digital elements is supplied for distribution or use on the Union market as part of a commercial activity, not merely whether the product is custom.

The CRA materials identify two deviations only: secure-by-default configuration in Annex I Part I point (2)(b), and the requirement that security updates addressing identified security issues be disseminated free of charge in Annex I Part II point (8).

Both deviations depend on the tailor-made conditions being met. They do not remove the remaining product-related essential requirements, vulnerability-handling requirements, manufacturer obligations, conformity assessment, CE marking, or declaration of conformity.

Only within the narrow tailor-made deviation. The manufacturer still needs to show why the non-default configuration is part of a particular-purpose product for a particular business user and is covered by explicit different contractual terms.

That evidence should sit alongside the cybersecurity risk assessment. The deviation should not be treated as permission to ship an undocumented insecure setup or to ignore reasonably foreseeable use.

Yes, but only for the free-of-charge element and only where the tailor-made conditions and different contractual terms support that deviation.

The CRA does not use the tailor-made exception to remove the rest of the update obligation. Security updates addressing identified security issues still need to be disseminated without delay and accompanied by advisory messages with relevant information, including potential action for users.

No. The Commission FAQ says a product is not tailor-made when it undergoes minor customisations before sale without specific contractual terms or arrangements.

The FAQ gives examples of a CRM platform sold to multiple businesses and platforms that use plugins or APIs for customisation but remain fundamentally the same product for every customer. Ordinary enterprise configuration therefore does not establish the tailor-made exception.

The Commission FAQ gives examples such as custom-developed hardware or software designed for a specific business user's needs, and products developed for integration into a specific customer's highly controlled environment, such as a closed network or air-gapped environment, where specific contractual terms apply.

Those examples are not automatic exemptions for industrial, closed-network, or air-gapped deployments. The product still needs to be fitted to a particular purpose for a particular business user, and the explicit contractual terms still need to exist.

Yes, when the product is in scope and placed on the market. The tailor-made deviation does not create a separate conformity route or remove conformity assessment.

The manufacturer still needs the applicable conformity assessment procedure, technical documentation, CE marking, and EU declaration of conformity. The selected route depends on the product's CRA classification and the applicable rules, not on tailor-made status alone.

The Commission FAQ says the manufacturer is expected to include all relevant data or details showing compliance with the relevant essential cybersecurity requirements, including appropriate evidence that the product is tailor-made.

For this topic, useful documentation should connect the customer-specific purpose, the business user, the explicit contractual terms, any secure-by-default or paid-update deviation, the cybersecurity risk assessment, the applicable Annex I requirements, and the tests or other evidence used to verify conformity.

Yes. The CRA does not provide a general Annex II exemption for tailor-made products.

Manufacturers still need to provide the required information and instructions to the user. For a customer-specific build, that means the user-facing information should match the actual intended purpose, support period, secure installation and operation assumptions, and any contractual update model that is being relied on.

Keep evidence that answers six questions: what product with digital elements is being supplied, who the particular business user is, what particular purpose the product is fitted to, which explicit contractual terms differ, which of the two allowed deviations is being used, and how the remaining CRA requirements are still met.

Useful records include the customer-specific requirements or architecture, the signed contractual clause or order terms, the cybersecurity risk assessment, the rationale for any non-default configuration, the security-update terms, test reports, vulnerability-handling process evidence, the conformity assessment record, and the EU declaration of conformity where the product is placed on the market.

No. The CRA text limits the deviation to an agreement between a manufacturer and a business user for a product fitted to that particular business user's purpose.

A product does not qualify because a consumer selected options, commissioned a personalised configuration, or negotiated a price. Without a qualifying business user, particular business purpose, and explicit different contractual terms, the secure-by-default and free-security-update requirements apply in the ordinary way.

CRA technical documentation is the product-level evidence file that shows how the manufacturer ensured conformity with the applicable essential cybersecurity requirements.

Article 31 requires the file to contain all relevant data or details of the means used by the manufacturer to ensure conformity. Annex VII then sets the minimum content, where applicable, for the relevant product with digital elements.

The file needs a traceable scope. It should identify the product variants and compliance-relevant software versions covered, the remote data processing and third-party components included in the assessment, and the evidence version that supported each market release. Without that mapping, a test report or risk assessment may be technically valid but attached to the wrong product configuration.

The manufacturer must draw up the technical documentation before placing the product with digital elements on the market.

After placing on the market, Article 31 requires the file to be continuously updated, where appropriate, at least during the support period. The Commission FAQ also treats the file as something that must be available when the product is placed on the market, regardless of where the records are physically stored.

Annex VII requires, as applicable, a general product description, intended purpose, software versions affecting compliance, relevant hardware images or illustrations, and the user information and instructions from Annex II.

It also requires design, development, production, and vulnerability handling information; the cybersecurity risk assessment; support-period determination information; standards, common specifications, certification schemes, or alternative technical solutions used; test reports; the EU declaration of conformity; and, where applicable, the software bill of materials for authority checks.

The record should show the product's intended purpose and reasonably foreseeable use, the risks assessed across design, development, production, delivery, and maintenance, and how those risks informed the implementation of Annex I Part I requirements.

Where a product-property requirement is treated as not applicable, Article 13(4) requires a clear justification in the cybersecurity risk assessment included in the technical documentation. That means the record should preserve the applicability decision, the reason for excluding the requirement, and any risk treatment used instead.