EU Cyber Resilience Act FAQ Secure by Default

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.

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.

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.

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.

The secure-by-default requirement includes the possibility to reset the product to its original state. The CRA does not prescribe one universal reset design, so the implementation must fit the product and its cybersecurity risk assessment.

The reset path should restore the assessed original configuration without creating a new insecure state. Manufacturers should document what the reset changes, how credentials, keys, logs, user data, network settings, and update settings are handled, and how the reset relates to the separate Annex I requirement for users to remove data and settings securely and permanently.