Secure by default: CRA's baseline security expectations
The topic of this blog post series is the Cyber Resilience Act (CRA) requirements. One important CRA requirement is that digital products must be secure by default (Annex I, I.2b). Thus, the user can safely use the product out of the box without taking action to secure it. Historically, IT systems have often been insecure unless users or administrators hardened them, but the CRA does not allow this approach. Humorously, we can say that in the past you needed an expert to make a system secure, but now you need an expert to make the system insecure.
Secure configuration out of the box
In practice, “secure by default” means that products are shipped with a secure configuration. Services and similar interfaces must require authentication, and insecure features must be disabled. The CRA also requires that users can restore products back to their original (secure) default state. For products tailor-made for business-to-business purposes, CRA has a carve-out for the secure by default requirement and parties may agree not to follow this requirement.
The “secure by default” principle should be applied to all product features. For example, when using passwords, they cannot be shared between product copies. The user must either be prompted to set a password on first use or each copy must have a unique, strong password. Other examples include tight firewall rules, strict default administrator password policies, and mandatory multi-factor authentication.
Security updates
The CRA requires that there are no known exploitable vulnerabilities when the product is released to the market (Annex I, I.2a). This is a solid requirement, but it protects only during the fleeting moment of market entry. New vulnerabilities appear frequently, and unpatched products will soon become insecure. To address this, the CRA requires that vulnerabilities are addressed by security updates that are enabled by default (Annex I, I.2c).
However, the CRA further requires that users may, at their own discretion, deny or delay updates. This may be done, for example, for safety or reliability reasons, as updates may change product behavior in subtle ways. These security updates must be available free of charge for the duration of the product support period, except in business-to-business products where this can be agreed differently (Annex I, II.8).
Insecure features
As previously stated, insecure features must be off by default. The CRA goes even further and demands that all exposed services and features must be justified by the intended purpose of the product to limit its attack surface (Annex I, I.2j). If a service or function is not required, it should be disabled or removed. In particular, development and testing functions and ports must not be present on production systems. Minimizing services and features reduces the product’s attack surface and makes it less likely to contain mistakes and bugs that lead to security problems. Fewer features mean less code and fewer external libraries, resulting in fewer public vulnerabilities and less pressure for security updates.
Minimized data collection
The same minimization principle applies to collected, processed, and stored data (Annex I, I.2g). Collected data and its retention period should be minimized to what is essential for the intended purpose of the product. Once data is no longer required, it should be discarded. Minimizing stored data has many benefits for cybersecurity:
In case of an incident, the less data exposed, the smaller the damage potential
A system with little valuable information is less interesting to attackers
It is easier to protect a small amount of sensitive data than large datasets
However, it must be acknowledged that collected data is often valuable for the vendor's business and is seen as a resource that should be collected in large quantities. This conflicts with security principles and legal responsibilities, which view sensitive data as a liability. The balance between these views must be found in co-operation between business, legal, and security teams. Note that the EU's General Data Protection Regulation (GDPR) imposes its own requirements for the processing of personal data.
Change in responsibility: From users to manufacturers
The CRA fundamentally reverses the historical relationship between products and security. Traditionally, users or administrators had to actively make systems safe, but the CRA places that burden on the manufacturer. The product must arrive secure: with safe default settings, a minimal attack surface, active security updates, and only the data it actually needs. Users should not need to think about security to be secure.
