Secure by default means the product should not depend on the user discovering and enabling essential security settings after purchase or deployment. Manufacturers should define a defensible default security baseline, minimise unnecessary exposure, avoid insecure initial credentials or privileges, verify reset behaviour and retain evidence showing how the default configuration addresses the product's cybersecurity risks.
Annex I Requires a Secure Starting Configuration
Annex I Part I point 2(b) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to be made available on the market with a secure-by-default configuration. The requirement changes the starting assumption for product configuration. Security should not depend entirely on a user finding documentation, identifying risky defaults and manually hardening the product before normal use. The manufacturer should determine which settings materially affect the product's cybersecurity and choose initial values that provide an appropriate security baseline. The correct baseline depends on the product and its risk assessment, but the default configuration should not unnecessarily expose interfaces, privileges, services or functions that increase risk without being needed for the intended purpose.
- Identify settings that materially affect cybersecurity.
- Choose defensible secure initial values.
- Avoid unnecessary exposure in the shipped configuration.
- Verify the actual configuration users receive.
- Tie the baseline to the cybersecurity risk assessment.
Secure by Default Is More Than a Setup Wizard
A product can contain extensive security options and still have weak defaults. The CRA requirement concerns the configuration with which the product is made available, not merely whether stronger settings exist somewhere in an administration interface. Product teams should examine enabled services, network listeners, remote administration, privilege levels, default accounts, credential behaviour, telemetry settings, debugging functions, exposed APIs and other security-relevant features. Setup workflows can legitimately ask the user for deployment-specific information, but essential protections should not be hidden behind optional advanced configuration without a product-specific reason. Where the user must make a security-sensitive choice, the interface should avoid steering the user toward an unnecessarily insecure option simply because it is easier to deploy.
- Review enabled network services.
- Review default accounts and credentials.
- Review initial privilege assignments.
- Review remote administration defaults.
- Review debugging and diagnostic interfaces.
- Review optional features that expand the attack surface.
Default Credentials Need Particular Attention
Authentication design is addressed separately in Annex I point 2(d), but credentials are also relevant to secure default configuration. Shared or predictable default credentials can create immediate exposure when a product is connected to a network. Depending on the product, stronger approaches can include unique credentials, first-use credential creation, secure enrolment or another mechanism that prevents uncontrolled access using widely known initial secrets. The correct implementation depends on the risk assessment and product architecture. Manufacturers should also consider recovery and reset behaviour because a product that returns to an insecure universal credential after reset can recreate the original problem. Credential provisioning, storage and reset behaviour should therefore be evaluated together rather than as separate user-interface decisions.
- Avoid unnecessary shared default secrets.
- Consider unique or user-established credentials.
- Protect credential provisioning and storage.
- Test credential behaviour after reset.
- Document exceptions and product-specific reasoning.
The CRA Includes the Possibility to Reset the Product
Annex I point 2(b) expressly includes the possibility to reset the product to its original state. The reset design should therefore form part of the product's security architecture rather than being treated only as a support feature. Teams should define what original state means for the product, which configuration values are restored, what happens to security credentials, and whether locally stored user information remains or is removed. The reset function should not silently create an insecure condition that contradicts the secure-by-default baseline. Secure data removal is addressed separately elsewhere in Annex I, so reset and data deletion should not automatically be treated as the same legal or technical function. The expected behaviour should be clear in implementation and user information.
- Define the product's original configuration state.
- Restore secure default settings after reset.
- Specify credential behaviour.
- Specify what happens to user data.
- Test reset behaviour as part of security verification.
The Tailor-Made Business-User Exception Is Narrow
Annex I point 2(b) contains a specific qualification for a tailor-made product with digital elements. The manufacturer and business user can agree on a configuration other than the normal secure-by-default configuration. This should not be read as a broad permission to ship standard commercial products with weak defaults merely because the customer is an organisation. The wording is tied to a tailor-made product and an agreement between manufacturer and business user. Where this route is relevant, manufacturers should document the requested configuration, the responsible parties, the associated security assumptions and the agreement supporting the departure from the normal baseline. Other applicable CRA requirements continue to matter even where this specific configuration arrangement is used.
- Confirm that the product is genuinely tailor-made.
- Identify the business user.
- Record the agreed configuration.
- Document cybersecurity consequences and assumptions.
- Do not treat the exception as a general B2B exemption.
Secure Defaults Should Be Tested, Not Assumed
A configuration baseline can drift between design, build, packaging and deployment. Verification should therefore examine the product in the state that a user actually receives. Tests can confirm listening services, account status, privileges, remote interfaces, security features, credential behaviour and reset results. Automated configuration tests can help prevent later releases from accidentally re-enabling a service or weakening an important setting. Where the product supports multiple editions, installation modes or deployment profiles, the manufacturer should identify which configurations are supplied by default and whether the applicable security baseline remains appropriate across them. Verification records should identify the tested version and configuration so that the evidence can be connected to technical documentation.
- Test the shipped or distributed configuration.
- Check for unexpected enabled services.
- Verify default privileges and access paths.
- Verify reset behaviour.
- Repeat checks when configuration logic changes.
Secure Defaults and Automatic Updates Are Related but Separate
Annex I treats secure default configuration and security updates as separate requirements. Point 2(b) concerns the product's secure default configuration and reset capability. Point 2(c) addresses the ability to address vulnerabilities through security updates and, where applicable, automatic security updates enabled as a default setting with an appropriate opt-out mechanism and other user controls. A product can therefore satisfy one requirement while failing the other. Manufacturers should map configuration security and update behaviour separately in the Annex I matrix even where both are implemented through the same setup or administration interface. This separation also improves testing because a change to update settings does not automatically demonstrate that the rest of the product remains securely configured.
- Map point 2(b) and point 2(c) separately.
- Do not use automatic updates as proof of secure configuration.
- Test update defaults and other security defaults independently.
- Keep requirement-specific evidence.
Evidence for Secure-by-Default Compliance
Useful evidence can include the approved configuration baseline, architecture documentation, default service inventory, account and privilege model, setup workflow specifications, reset design, configuration security tests and release verification results. Where a configuration differs for a tailor-made business product, the relevant agreement and technical rationale should also be retained. Evidence should show both the intended baseline and the actual product behaviour because configuration defects frequently arise during packaging or deployment rather than during architecture design. A reviewer should be able to identify the product version, determine what settings a new user receives and understand how those settings relate to the cybersecurity risk assessment.
- Approved secure configuration baseline.
- Default service and interface inventory.
- Account and privilege configuration.
- Reset behaviour specification.
- Configuration verification results.
- Tailor-made configuration agreement where applicable.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.