Search every question across sub-FAQs

If an actively exploited vulnerability in an integrated component is contained in the finished product, the finished-product manufacturer must notify it under Article 14 when aware of it. If the component manufacturer placed that component on the market separately, it may have its own Article 14 duty as well.

If the manufacturer knows the integrated component has a vulnerability but that vulnerability cannot be exploited in the finished product, the Commission FAQ says it is not an actively exploited vulnerability in that finished product for mandatory Article 14 reporting. Voluntary Article 15 reporting may still be used, and Article 13(6) can require upstream reporting to the person or entity manufacturing or maintaining the component.

Article 14 places the mandatory reporting duty on the manufacturer. Importers and distributors have related escalation duties rather than becoming the ordinary Article 14 reporter.

If an importer or distributor becomes aware of a vulnerability in the product, it must inform the manufacturer without undue delay. If it considers or has reason to believe the product presents a significant cybersecurity risk, it must also immediately inform the market surveillance authorities of the Member States where the product has been made available.

Yes. Article 15 allows manufacturers and other natural or legal persons to notify vulnerabilities, cyber threats that could affect a product's risk profile, incidents, and near misses on a voluntary basis to a CSIRT coordinator or ENISA.

The CSIRT may prioritise mandatory notifications over voluntary ones. If someone other than the manufacturer reports an actively exploited vulnerability or severe incident, the CSIRT coordinator must inform the manufacturer without undue delay. CSIRTs and ENISA must protect voluntary-notifier information, and voluntary reporting does not by itself impose extra obligations on the notifier.

Keep the evidence needed to support the classification and every report stage: original intake signal, source and timestamp, affected product and version, whether the issue is a product vulnerability or an incident, evidence of malicious exploitation or severe product-security impact, initial assessment notes, awareness-time decision, affected Member States where known, user-impact assessment, sensitivity marking, and any corrective or mitigating measures already taken or available to users.

For the final record, preserve severity and impact analysis, root-cause or threat-type assessment where available, malicious-actor information where available for exploited vulnerabilities, security update or mitigation details, user communications, CSIRT submissions, intermediate reports requested by a CSIRT, and the rationale for any delayed public or wider disclosure.

For older products, preserve practical investigation limits such as unavailable build environments, unsupported dependencies, missing tooling, or departed product knowledge. The Commission FAQ says those limits do not remove the Article 14 reporting duty, but they explain what could and could not be verified.

No. Article 17(4) says the mere act of notification under the mandatory or voluntary reporting provisions does not subject the notifier to increased liability.

That protection does not remove the underlying CRA obligations, but it is important for escalation playbooks because teams should not delay a required report simply because the act of notifying is visible to authorities.

There is narrow penalty relief, not a removal of the reporting duty. Article 64 exempts microenterprises and small enterprises from administrative fines for failure to meet the 24-hour early-warning deadline in Article 14(2)(a) or Article 14(4)(a).

The CRA also requires CSIRTs designated as coordinators to provide helpdesk support for Article 14 reporting, in particular for microenterprises and small or medium-sized enterprises.

The CRA requires products with digital elements to be made available on the market with a secure-by-default configuration, unless the tailor-made product exception applies. The requirement sits in Annex I Part I point (2)(b) and includes the possibility for the user to reset the product to its original state.

The default state must be tied to the manufacturer's cybersecurity risk assessment. Article 13 requires the assessment to consider the product's intended purpose, reasonably foreseeable use, conditions of use such as the operational environment and assets to be protected, and the expected time in use.

No. The CRA does not prescribe one universal default profile for every product with digital elements.

A consumer device, an industrial component, a software library, and a professional network product can have different secure defaults because their intended purpose, foreseeable use, users, integration model, assets, and threat scenarios can differ. The manufacturer still has to document why the chosen defaults meet the applicable Annex I requirements.

Not as an abstract rule. The CRA test is whether the product is designed, developed, produced, delivered, and maintained with an appropriate level of cybersecurity based on the risks, and whether the applicable Annex I controls are implemented as informed by the risk assessment.

A default can allow necessary functions if those functions are part of the intended purpose and the remaining risk is treated. A default is weak if convenience leaves unnecessary external interfaces, insecure algorithms, broad privileges, unauthenticated access, or unnecessary data processing enabled without risk-based justification.

Secure by default should be read together with the surrounding Annex I product-property requirements. Defaults may need to address known exploitable vulnerabilities, automatic security updates, protection from unauthorised access, confidentiality and integrity of data and configuration, data minimisation, availability of essential functions, reduced negative impact on other devices or networks, limited attack surfaces, incident-impact reduction, security-related logging, and removal or transfer of data and settings.

For implementation, that means the default profile should identify which services, ports, interfaces, credentials, roles, cryptographic options, telemetry, logging, update channels, and data stores are active at first use and why each is necessary.

Annex I requires products to be designed, developed, and produced to limit attack surfaces, including external interfaces. Secure defaults should therefore avoid exposing interfaces, services, APIs, debug functions, administrative endpoints, network listeners, or legacy protocol modes that are not needed for the intended purpose at first use.

The Commission FAQ gives concrete examples: a cryptographic library may need insecure or deprecated algorithms disabled by default and certificate validation enabled by default; a microcontroller with a built-in network stack may need network interfaces disabled by default until the integrating manufacturer enables them for its own product purpose.

The CRA does not use the phrase least privilege in Annex I, but its controls point in that direction. Annex I requires protection from unauthorised access through appropriate control mechanisms, including authentication, identity, or access management systems, and requires reporting on possible unauthorised access.

In practice, a secure default should not ship with shared, predictable, or unnecessary privileged access. Initial roles, service accounts, APIs, remote administration, and integration credentials should start with only the access needed for the intended purpose, with higher-risk permissions requiring deliberate configuration and traceable user action.

Annex I requires products to process only personal or other data that are adequate, relevant, and limited to what is necessary for the intended purpose. A default configuration should therefore avoid collecting, storing, transmitting, logging, or enabling access to data that is not needed for the product's stated purpose and security properties.

If the product can technically process data outside its stated intended purpose, the manufacturer should consider whether that foreseeable use or misuse creates significant cybersecurity risks. The Commission FAQ says user information may need to explain those risks where the product's technical capability could lead to significant cybersecurity risks.

No. User information is required, but it is not a substitute for secure-by-default design where the requirement applies. Annex I requires the secure default configuration at market placement; Annex II then requires instructions that allow secure installation, operation, use, update installation, and decommissioning.

Instructions are especially important for assumptions that users must satisfy, such as secure deployment environments or integration requirements. They should explain what must be done to maintain the intended security outcome, not shift an avoidable insecure default onto the user.

Annex II requires the product to be accompanied by information on the intended purpose, the security environment provided by the manufacturer, essential functionalities, security properties, and any known or foreseeable circumstance that may lead to significant cybersecurity risks.

For secure defaults, useful user information normally identifies the default security posture, what has intentionally been disabled or restricted, how security-relevant updates are installed, how automatic security update installation can be turned off where applicable, how changes to the product affect data security, and how data and settings can be securely removed during decommissioning.

Automatic security updates are a separate but closely related Annex I requirement. Where applicable, vulnerabilities must be addressable through security updates, including automatic security updates installed within an appropriate timeframe and enabled as a default setting.

That default must come with notification of available updates, a clear and easy-to-use opt-out mechanism, and the option to temporarily postpone updates. Annex II also requires instructions on how the default automatic-installation setting can be turned off.

No. Recital 56 recognises that automatic updates are not appropriate for every product. It says automatic-update expectations do not apply to products primarily intended to be integrated as components into other products, and do not apply where users would not reasonably expect automatic updates, including products intended for use in professional ICT networks and especially critical or industrial environments where automatic updates could interfere with operations.

That does not remove vulnerability-handling duties. Regardless of whether the product receives automatic updates, the manufacturer should inform users about vulnerabilities and make security updates available without delay.

No. The Commission FAQ states that the manufacturer is not responsible under the CRA if the user does not install security updates, including where the user opts out. But the manufacturer still needs compliant update mechanisms, vulnerability handling, advisory messages, user notifications, and instructions.

The product and process design should therefore make the secure path the default while preserving the CRA-required user choice to opt out or temporarily postpone automatic update installation where automatic updates apply.

When a manufacturer places a component on the market separately for integration into another product, the secure-by-default obligation applies to the component as placed on the market. The component manufacturer is not responsible for later configuration or deployment choices made by the integrating manufacturer.

This distinction does not make the default irrelevant. The Commission FAQ uses cryptographic libraries and microcontrollers as examples where the component's own delivery configuration may need secure defaults, while the downstream integrator may later enable or change settings for the integrated product's intended purpose.

Yes, but only with a clear, documented justification. Article 13(4) requires the manufacturer to include the cybersecurity risk assessment in the technical documentation and, where a requirement is not applicable, to include a clear justification.

The Commission FAQ gives two examples: the requirement may be incompatible with the product's nature, or the risk assessment may show no relevant risks requiring mitigation for that requirement. If related cybersecurity risks still exist, the manufacturer should treat them by other means, such as limiting the intended purpose to trusted environments or informing users about the risks.