Search every question across CRA sub-FAQs

Potentially, yes.

The CRA requires that vulnerabilities can be addressed through security updates and that manufacturers provide mechanisms to securely distribute updates. It does not say that every compliant update path has to be wireless, cloud-delivered, or continuously remote.

The ETSI materials in the local CRA corpus make that practical point explicit. ETSI EN 303 645 says update mechanisms can range from direct download from a remote server to delivery via a mobile application or transfer over a USB or other physical interface. ETSI TR 103 621 gives concrete examples of signed updates delivered from a manufacturer-prepared USB stick and of constrained devices accepting firmware uploaded through a user interface after signature verification. So OTA is one compliant implementation pattern, not the only one. This is an inference from the CRA's functional wording together with the ETSI examples.

Potentially, yes.

The CRA does not say that each individual device must itself poll update servers or personally validate every update package. What it requires is that vulnerabilities can be addressed through security updates and that update-distribution mechanisms are secure.

ETSI EN 303 645 says that, for some products, it can be more appropriate for an associated service rather than the device itself to check whether security updates are available. The same ETSI material also explains that, where updates are delivered over a network interface, authenticity and integrity can be verified through a trust relationship, and that for constrained devices verification can be performed by another trusted device. ETSI TR 103 621 gives a concrete example of a smart home controller that validates update signatures and then transmits the trusted update to sensors and actuators over a trustworthy channel. So gateway- or app-mediated update handling can fit the CRA, provided the trust model and security controls are robust enough. This is an inference from the CRA's functional wording together with the ETSI examples.

No.

The CRA's default-enable, opt-out, notification, and postponement rule is about automatic security updates where applicable. Separately, Annex I Part II point (2) says new security updates should, where technically feasible, be provided separately from functionality updates.

So the CRA does not create a general rule that feature or functionality changes must be installed automatically by default. If a functionality change is itself necessary to deliver the security fix, bundling may still be allowed, but that does not turn functionality updates as a category into mandatory default automatic updates.

Yes.

Annex I Part I point (2)(c) expressly requires the option to temporarily postpone automatic security updates where automatic security updates are applicable. The CRA therefore does not require every automatic update to install at the first possible moment regardless of operational context.

The ETSI guidance in the local CRA corpus gives practical examples of this, including user-defined installation times and postponing download and installation until the product is connected to an unmetered network, while still allowing an override for security updates. That does not remove the CRA's requirement that updates be disseminated without delay and that vulnerabilities be fixed or mitigated in a timely manner. It means the update flow can still accommodate controlled postponement.

Yes.

The CRA technical-documentation rules do not treat secure update distribution as just an operational detail. Annex VII requires the technical documentation to include the necessary information and specifications of the manufacturer's vulnerability-handling processes, including a description of the technical solutions chosen for the secure distribution of updates.

So the manufacturer needs more than a working update channel. It also needs documentation showing what secure update-distribution approach it chose for the product.

Not automatically.

The CRA itself speaks at a higher level and requires mechanisms to securely distribute updates. The ETSI materials in the local CRA corpus make clear that protected transport can be one valid part of the trust model, but that secure update handling is about the overall mechanism resisting misuse and ensuring appropriate authenticity and integrity for the use case.

ETSI EN 303 645 explains that valid trust relationships can include authenticated communication channels, but it also points to verifying authenticity and integrity of updates and to anti-rollback measures. ETSI TS 103 701 says secure update mechanisms need security guarantees appropriate to the use case and that at least integrity and authenticity are required. ETSI TR 103 621 gives an example using TLS plus mutual authentication and digitally signed, versioned firmware packages. So a protected channel may be part of a compliant design, but it is not a shortcut that removes the need to ensure the update itself is trusted and protected against misuse.

Potentially, yes.

The CRA does not say that a product must be permanently online. It requires that vulnerabilities can be addressed through security updates and that manufacturers provide mechanisms to securely distribute those updates.

The ETSI examples in the local CRA corpus show several models that fit that basic pattern: a smart kitchen appliance that can be initialized and used offline and checks for updates when first connected; a limited-bandwidth device that is securely updated via a manufacturer-prepared USB stick; and a smart tracker that only downloads updates when in range of a paired mobile device. So intermittent connectivity does not by itself make a product non-compliant, provided the manufacturer still ensures an update path that is secure and suitable to timely remediation. This is an inference from the CRA's functional wording together with the ETSI examples.

It does both.

Article 64 requires each Member State to lay down and enforce penalty rules, but the CRA itself also fixes the main administrative-fine categories and maximum ceilings. National law still determines the detailed enforcement setup, provided the penalties are effective, proportionate, and dissuasive.

No.

The CRA harmonises the main fine tiers and maximum caps, but not every procedural and institutional detail. Member States still decide how penalties are implemented in national law, who imposes them, and whether public bodies can be fined.

The highest fine tier applies to:

- non-compliance with the essential cybersecurity requirements in Annex I

- non-compliance with the obligations in Articles 13 and 14

The maximum is EUR 15,000,000 or, if the offender is an undertaking, 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.

The middle tier covers a broad set of obligations for economic operators, conformity assessment, notified bodies, and authority access. Article 64(3) lists the relevant provisions directly, including Articles 18 to 23, Article 28, Article 30(1) to (4), Article 31(1) to (4), Article 32(1) to (3), Article 33(5), and Articles 39, 41, 47, 49 and 53.

The maximum is EUR 10,000,000 or, if the offender is an undertaking, 2% of total worldwide annual turnover for the preceding financial year, whichever is higher.

Supplying incorrect, incomplete, or misleading information in reply to a request from a notified body or a market-surveillance authority can lead to fines of up to EUR 5,000,000 or, if the offender is an undertaking, 1% of total worldwide annual turnover for the preceding financial year, whichever is higher.

No.

The CRA sets maximum ceilings, not automatic penalty amounts. The final amount in an individual case depends on the national system and the case-specific factors in Article 64(5).

Article 64(5) says authorities must take all relevant circumstances into account and give due regard at least to:

- the nature, gravity, duration, and consequences of the infringement

- whether similar fines have already been applied by the same or other market-surveillance authorities to the same operator

- the size and market share of the operator, including whether it is a microenterprise, SME, or start-up

Potentially yes, but not without limits.

Article 64(5)(b) requires authorities to take earlier fines by the same or other market-surveillance authorities into account, and Article 64(6) requires authorities that apply fines to communicate that through the Union information system. Recital 120 adds that cumulative fines across several Member States for the same type of infringement must still respect proportionality.

No.

The derogation is narrow. As corrected by the 2 July 2025 corrigendum, Article 64(10)(a) removes the Article 64(2) to (9) administrative-fine regime only for manufacturers that qualify as microenterprises or small enterprises, and only with regard to a failure to meet the 24-hour deadline in Article 14(2)(a) or Article 14(4)(a).

That is not a general exemption from CRA penalties or from other CRA obligations.

The CRA recital points the other way.

Recital 120 says that, given the Article 64 carve-out for microenterprises and small enterprises for that 24-hour reporting deadline failure, Member States should not impose other kinds of penalties with pecuniary character on those entities for that situation.

No, not under the Article 64 administrative-fine regime.

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

No.

Article 52(3) still makes market-surveillance authorities responsible for supervising steward obligations under Article 24 and for requiring corrective action where a steward does not comply. Recital 120 also says Member States should not replace the exempted administrative fines with other pecuniary penalties for stewards.

That depends on national law.

Article 64(7) says each Member State must decide whether, and to what extent, administrative fines may be imposed on public authorities and public bodies established in that Member State. Recital 121 points the same way.