Deep Dive: CRA Requirement (b) – Secure by Default Configuration

The second essential cybersecurity requirement under the EU Cyber Resilience Act focuses on default product settings. At the heart of it is a simple but powerful principle: connected products must be shipped in a secure state, without requiring users to harden them manually.

“(b) be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;”

This requirement pushes security upstream, into design, development, and manufacturing. It eliminates the longstanding assumption that end users will configure security settings correctly and makes manufacturers responsible for delivering products that are protected from the first boot.

What This Requirement Means

Secure by default means that a product is in its most secure configuration when first installed or powered on. All unnecessary services must be disabled, default passwords must be unique and strong, and interfaces not needed for normal operation must be turned off.

For non-technical stakeholders, think of this scenario like buying a car with all the safety features already activated, airbags enabled, brakes tested, and child locks engaged. Users should not be required to "activate" protection manually.

Technically, this requirement has several implications. Default configurations must be based on a clear understanding of security risks and should minimize exposure. Devices should prevent remote access unless explicitly enabled, enforce access control from the beginning, and allow users to reset the product to a known secure state. Manufacturers must also avoid insecure factory presets and test default states just as rigorously as any custom configuration.

Relevant Standards and Guidelines

Several existing standards and frameworks provide partial support for implementing secure default configurations:

• ISO/IEC 27002 includes guidance on secure configuration management as part of broader security controls.

• ETSI EN 303 645 outlines security provisions for consumer IoT devices, including avoiding universal default passwords and minimizing exposed services.

• IEC 62443-4-2 defines technical security requirements for industrial control system components, including interface control, secure reset, and startup behavior.

These standards provide a useful foundation, but few define what constitutes a "secure" default in practice. There is also a lack of clear implementation guidelines for constrained embedded devices, where balancing usability and security requires tighter integration with firmware and system design.

How to Approach Implementation

Secure-by-default behavior needs to be defined, implemented, and verified as part of the product development process. That starts by identifying what functions the product must expose to users and disabling everything else: network ports, debug interfaces, test routines, and optional services.

Configuration hardening should be embedded into the CI/CD pipeline, with automated testing to verify that:

• Default credentials are not hardcoded or reused

• All access control is enforced by default

• Only necessary services and APIs are exposed

• Reset-to-factory procedures restore a secure baseline

Security folks should work closely with developers to ensure configuration security is considered from the beginning, not added after functionality is implemented. Build tooling, firmware packaging, and device provisioning workflows must all reflect the secure default state, including for embedded systems where changes are more costly after release.

In industrial environments, the challenge often lies not just in what is exposed, but in how it’s exposed. Many industrial systems still rely on widely used but insecure protocols (or are in an insecure configuration due to complexity), such as Modbus, OPC-UA, or MQTT, often deployed without authentication, encryption, or access control. The CRA elevates the level of security. Going forward, it may trigger a long-overdue transformation: secure versions of these protocols will no longer be optional, but expected as the new baseline. Until such secure-by-design alternatives become common, manufacturers must ensure that insecure protocols are either avoided or properly mitigated, through network isolation, strict segmentation, or application-layer mitigations, based on the risk profile of the product and its deployment context.

For industrial stacks that include containerized services, security by default also means locking down container runtimes, controlling which services auto-start, and using secure default configurations for orchestration systems. For embedded devices, defaults must often be baked into firmware and tested under constrained conditions. This includes generating unique keys or passwords per device, locking down physical interfaces like UART or JTAG, and disabling debug modes before production flashing. Security resets should remove the user configuration and restore only the hardened factory image, without exposing insecure fallback states.

No matter the environment, the goal is clear: products must ship in a secure state, with configurations that minimize risk without placing the burden on the user to “secure” the product themselves.

This topic builds on all key aspects of the CRA, explore our CRA Guide to access all related resources.

Compliance and Strategic Considerations

This requirement pushes security from optional configuration to mandatory design. Manufacturers must document which default settings are enforced, how they were chosen, and how users can reset devices securely. These details must be included in the product's user guide, as required under Annex II.

Strategically, secure defaults also improve usability and reduce support costs. By eliminating insecure configurations at launch, manufacturers can prevent misconfigurations that lead to vulnerabilities, support tickets, or reputational damage later.

To meet this requirement effectively, organizations must align development and security from the start, choosing secure defaults that work with the intended user experience, not against it. Security teams should support developers in choosing the right tools and test frameworks and help define what “secure” looks like for each product class.

In our next post, we’ll explore Requirement (c): Security Updates and Opt-Out, a topic that defines what it means to maintain cybersecurity once a product is already in the field.

Previous Blog CRA Requirement (a): https://tributech.io/blog/cra-requirement-a-no-known-exploitable-vulnerabilitiesNext Blog CRA Requirement (c):https://www.tributech.io/blog/cra-requirement-c-security-updates-and-opt-out