Search every question across sub-FAQs

Article 64(10)(b), as corrected by the 2 July 2025 corrigendum, excludes open-source software stewards from the administrative fines referred to in Article 64(2) to (9) for infringements of the CRA.

That does not put stewards outside supervision. Article 24 gives stewards documented cybersecurity-policy, cooperation, and limited reporting duties. Article 52(3) makes market-surveillance authorities responsible for steward obligations and lets them require appropriate corrective action.

Recital 120 says Member States should not impose other kinds of penalties with a pecuniary character on the entities covered by those Article 64 carve-outs.

For micro and small manufacturers, that recital statement is tied to the 24-hour early-warning deadline failure. For open-source software stewards, it is tied to their exclusion from Article 64 administrative fines, while corrective action under Article 52(3) can still apply.

That is left to national law. Article 64(7) says each Member State must lay down rules on whether, and to what extent, administrative fines may be imposed on public authorities and public bodies established in that Member State.

For persons that are not undertakings, Recital 121 says authorities should consider the general income level in the Member State and the person's economic situation when setting a fine.

The answer depends on each Member State's legal system. Article 64(8) allows fines to be imposed by competent national courts or by other bodies according to national competences, provided the application of the rules has equivalent effect.

For compliance planning, this means Article 64 gives the ceiling and required effect, while the enforcement body, procedure, appeal path, and national penalty mechanics must be checked Member State by Member State.

The Article 64 administrative-fine framework applies from 11 December 2027. Article 71 does not give Article 64 an earlier application date.

Article 14 reporting obligations apply earlier, from 11 September 2026, and Chapter IV on notified bodies applies from 11 June 2026. Article 69(3) also extends Article 14 to otherwise in-scope products placed on the market before 11 December 2027. Those early dates do not make Article 64 administrative fines applicable early; any exposure under other EU or national law must be assessed separately.

Only at recital level. Recital 122 says Member States should examine, taking national circumstances into account, whether penalty revenues or their financial equivalent can support cybersecurity policies and increase cybersecurity in the Union.

The recital gives examples such as more qualified cybersecurity professionals, capacity building for microenterprises and SMEs, and public awareness of cyber threats. It does not create a fixed revenue allocation rule.

Potentially. The CRA itself sets administrative-fine ceilings and requires Member States to establish effective, proportionate, and dissuasive penalties, but it does not create a harmonised EU criminal offence for CRA breaches.

National law may provide additional sanctions for serious infringements. Separately, CRA non-compliance can lead to corrective or restrictive market-surveillance measures, including restrictions, withdrawal, or recall, and Article 65 applies the EU representative-actions regime to qualifying infringements that harm or may harm consumers' collective interests. The available sanctions and procedure must therefore be checked in each relevant Member State.

No. "Product family" is not a defined CRA term.

The CRA instead refers to the product with digital elements, its intended purpose, versions of software affecting compliance, technical documentation, and the EU declaration of conformity. The Commission's March 2026 draft-guidance consultation is the source for the more practical idea that similar variants may sometimes share evidence, but that guidance is not a substitute for the regulation's product-level duties.

Only where the variants are similar in the ways that matter for cybersecurity.

A family file should show that the grouped variants share the same architecture, security-relevant design, intended purpose, update path, remote processing boundary, and cybersecurity risk profile. If those conditions are met, one risk assessment and one technical documentation set can be practical, but the file still has to identify each covered model or version and explain why the shared evidence covers it.

The decisive test is whether the variant differences are relevant to cybersecurity or to the applicable conformity route.

Commercial similarity, shared branding, or a shared enclosure is not enough. Compare the variants against the CRA risk assessment and Annex VII documentation: intended purpose, essential functions, security properties, software versions affecting compliance, remote data processing, vulnerability handling, interfaces, update mechanisms, and the evidence used to verify the essential requirements.

Differences that do not affect cybersecurity properties usually do not justify a separate CRA assessment by themselves.

Typical non-security differences can include:

- physical housing

- color

- form factor

- memory size, where it does not alter security behavior or update capacity

- packaging, labels, or accessory bundles that do not change the product with digital elements

Record the reason. The family file should say why each difference does not change the attack surface, essential functions, security properties, vulnerability handling, support-period assumptions, or the test evidence used for conformity.

Differences that change the cybersecurity profile need a documented reassessment and may require a separate conformity route.

Treat the variant as a separate assessment candidate when it changes communication interfaces, software stack, authentication model, update mechanism, remote connectivity, remote data processing, third-party components, vulnerability handling, intended purpose, security environment, or the standards and test evidence used to demonstrate conformity. A changed variant does not always need a separate public product page or declaration, but the technical file must make the changed risk and evidence boundary visible.

Yes, but only if the representative evidence actually covers the variants' security behavior.

A manufacturer should be able to explain why the tested representative model exercises the highest-risk or relevant common functions, interfaces, update paths, remote dependencies, and vulnerability handling processes for the grouped variants. If an untested variant adds a new interface, different software branch, different update flow, or different remote processing dependency, the representative evidence may no longer be enough.

No.

Even where documentation is reused across a family, the CRA still requires product identification and traceability. Annex II requires user-facing information enabling unique identification, Annex V requires the declaration's object to identify the product, Annex VII requires versions of software affecting compliance, and Annex VIII requires the declaration to identify the relevant product or product model. The Commission FAQ also emphasizes that technical documentation must be comprehensive enough for market surveillance authorities.

No.

Where a new variant introduces new cybersecurity risks or changes how the essential cybersecurity requirements are implemented, the existing risk assessment, test rationale, and technical documentation must be updated before relying on the family file for that variant. If the change affects a notified-body certificate, approved type, vulnerability handling process, or quality-system scope, the relevant conformity-assessment route may also require additional approval or reassessment.