As a development principle, secure by default affects configuration design, enabled services, initial privileges, credential behaviour, exposed interfaces, packaging, installation and reset behaviour. Product teams need to design and verify the state users actually receive, not merely provide stronger optional settings.
Secure by Default Is Explicit in Annex I
Unlike secure by design, secure by default appears directly in the CRA's essential cybersecurity requirements. Annex I Part I point 2(b) requires, on the basis of the cybersecurity risk assessment and where applicable, products with digital elements to be made available on the market with a secure-by-default configuration. The rule also includes the possibility to reset the product to its original state and contains a specific qualification for a tailor-made product where the manufacturer and business user agree otherwise.
- Secure by default is an explicit Annex I requirement.
- Its application is connected to the cybersecurity risk assessment.
- The requirement concerns the configuration made available on the market.
- Reset to the original state is included in point 2(b).
The Development Question Is What State the User Actually Receives
For secure development, the important question is not only whether a security feature exists. The team needs to examine whether that protection is active, appropriately configured and preserved through packaging and deployment. A product can contain sophisticated authentication, logging or access-control features and still expose users if insecure options are enabled by default. Configuration design should therefore be treated as part of product security architecture rather than left entirely to installation documentation.
- Review the delivered product state.
- Review enabled services.
- Review exposed interfaces.
- Review initial privilege assignments.
- Review security-feature defaults.
Secure Defaults Reduce Dependence on Optional Hardening
Optional hardening guidance can still be useful, especially where customers have different deployment environments, but the default product should not unnecessarily depend on users finding and applying essential protections after installation. Product teams should identify which settings create meaningful cybersecurity risk and determine defensible initial values. The product's intended purpose and foreseeable use remain important because a secure baseline must still allow the product to perform its intended functions.
- Identify security-sensitive settings.
- Define approved initial values.
- Avoid unnecessary exposure.
- Do not make essential protection depend entirely on advanced user configuration.
- Keep the baseline consistent with intended product use.
Default Accounts and Credentials Are Development Decisions
Credential behaviour illustrates why secure by default belongs inside product development. Shared passwords, predictable credentials or excessive initial privileges can create exposure before users have an opportunity to harden the product. Depending on the product and risk assessment, teams can consider unique credentials, secure enrolment, first-use credential creation, constrained initial privileges or other approaches. The appropriate implementation is product-specific, but the default credential model should be consciously designed and tested.
- Avoid unnecessary universal default secrets.
- Review first-use authentication.
- Review initial account privileges.
- Review credential storage and provisioning.
- Test behaviour after reset.
Attack Surface Is Influenced by Defaults
Services and interfaces that are safe when intentionally enabled in a controlled deployment can still create risk when they are active by default everywhere. Secure-default review should identify network listeners, remote administration, debugging functions, development interfaces, optional protocols and other features that expand the attack surface. Where a feature is not necessary for the normal intended purpose, requiring deliberate activation can be safer than enabling it automatically.
- Inventory enabled services.
- Review remote-management exposure.
- Review debugging and diagnostic functions.
- Review optional protocols.
- Disable unnecessary exposure by default where appropriate.
Secure by Default and Secure by Design Are Complementary
Secure by design and secure by default solve different problems. Secure by design asks whether the product's architecture and functionality were built to reduce cybersecurity risks structurally. Secure by default asks whether the product's starting configuration preserves those protections without unnecessary user intervention. Strong architecture can be undermined by weak defaults, while strong defaults cannot repair fundamentally unsafe architecture. CRA secure development therefore needs both principles working together.
- Secure by design influences architecture.
- Secure by default influences starting configuration.
- Architecture and configuration should reinforce each other.
- Verify both separately.
Reset Behaviour Is Part of the Security Model
Annex I point 2(b) includes the possibility to reset the product to its original state. Development teams therefore need to define what original state means. Reset behaviour should specify configuration values, account state, credential handling, enabled services and the treatment of user information. A reset mechanism that restores a weak configuration can recreate vulnerabilities that the secure-default baseline was intended to prevent. Reset behaviour should therefore be included in security testing and release evidence.
- Define the original product state.
- Restore the intended security baseline.
- Define credential behaviour.
- Define the treatment of user data separately.
- Test reset across relevant product variants.
The Tailor-Made Business-User Qualification Is Specific
Annex I point 2(b) allows the manufacturer and a business user to agree otherwise in relation to a tailor-made product with digital elements. This qualification should not be treated as a general rule allowing ordinary B2B products to ship with insecure defaults. Where a genuinely tailor-made product uses an agreed configuration different from the normal secure baseline, the design assumptions and agreement should be documented so the reason for the configuration is traceable.
- Confirm the product is genuinely tailor-made.
- Identify the relevant business user.
- Document the agreed configuration.
- Document the security assumptions.
- Do not treat ordinary B2B sales as a blanket exception.
Secure Defaults Need Release Verification
The configuration specified by architects is not always the configuration delivered by installers, images, packages or manufacturing systems. Release verification should therefore inspect the actual product state distributed to users. Automated checks can verify enabled services, account status, privilege settings, update configuration, exposed interfaces and other security-sensitive values. Evidence should identify the product version and configuration tested so it remains useful for technical documentation and later change review.
- Test the distributed product state.
- Verify configuration after installation.
- Verify configuration after reset.
- Use automated regression checks where useful.
- Retain version-specific results.
This Development Page Has a Different Role From the Existing Requirement Page
CyberResilienceAct.help already contains a separate Essential Cybersecurity Requirements article dedicated to the detailed Annex I secure-default configuration requirement. This page serves a different purpose. It places secure by default inside the secure-development lifecycle and explains how configuration decisions interact with architecture, credentials, attack surface, release processes and verification. Keeping these intents separate prevents the secure-development cluster from simply reproducing the earlier Annex I requirement analysis.
- This page focuses on the development principle.
- The existing requirement page focuses on Annex I point 2(b) mechanics.
- The two pages serve different search intents.
- Future Cluster 5 articles build from the development perspective.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.