By 
On October 10th, 2024, the EU Parliament mandated security standards for connected software with the enactment of the Cyber Resilience Act (CRA). The act mandates that full compliance needs to be achieved within 36 months. However, according to Article 14, vulnerability reporting obligations must be met within 21 months of enactment.
Why is Cyber Resilience Act important?
Because the regulation applies to products with digital components able to connect to a network, including both direct and indirect connections. This definition goes beyond typical software and includes IoT devices, web applications, server infrastructure, and containerized services in software supply chains.
Virtually all products sold in the EU that use digital components or network connections fall under the scope of the CRA act. The clock is running, as we have under 2 years to fulfill the first requirements and less than 3 years to achieve full compliance.
Cyber Resilience Act Goals
Ok, so if companies don’t comply?
Non-compliance carries a financial penalty of €15 million or 2.5% of global annual turnover, whichever is greater. The regulation applies to every company selling products in the EU, even if they’re outside the EU. What is interesting is the change is liabilities. This shift in blame is also interesting, because now C-level, corporate leaders will be personally liable in case a security incident takes place. And depending on the impact, class action lawsuits will follow breaches.
So this is nothing to be joking about.
If that is not enough, failing to comply usually means blocked market access to EU/US markets, or supply chain exclusion, this on top with public disclosure and hefty fines does not look good for companies that just want to ship and launch stuff without taking into consideration security implication.
And is actually good news for consumers as well. This is especially important for people who don’t want their personal data sold on dark web markets.
Key obligations?
Under the reporting obligations, there’s a three-tier notification structure:
- An early warning about actively exploited vulnerabilities needs to be submitted by manufacturers within a 24-hour timeframe.
- A detailed vulnerability notification will be sent out within 72 hours of detection.
- A final report is required within 14 days of a corrective measure becoming accessible.
Other obligations of manufacturers?
Thanks for asking, it’s a lot to handle at first, but here it is:
- Conducting security risk assessments
- Maintaining technical documentation
- Implementing vulnerability handling processes
- Providing security updates for a minimum 5-year support period
- Generating software bills of materials (SBOM)
- Establishing incident response procedures
What are the developer team’s responsibilities?
Development teams must integrate security measures into every phase of the software development process. Continuous security testing, managing vulnerabilities, and automated compliance checks are key parts of the development pipeline.
To only name a few specific security controls:
Security-by-default architecture
This usually means that there must be implemented at the SDLC (Software Development Lifecycle) level either static code analysis(SAST), or dynamic application scanning (DAST), ideally both.
SAST is usually done at the code level and is valuable to catch known issues or vulnerability that the code may present further one. Of course, it depends on the application tech stack to choose an appropriate tool.
DAST on the other hand, will be scanning the live environment for existing vulnerabilities. Ideally, this should cover the situation where everything was scanned and passed security checks, but then a dependency in the live environment is discovered to contain a critical vulnerability.
Zero known exploitable vulnerabilities at release
As a developer, this is easier to say than done. While as scary as it sounds, again, an automated scanning tool should do the trick. Evidently, a good security posture implies coding guidelines and covering security gaps before waiting for a pentest.
Secure default configurations
The CRA states products must “be made available on the market with a secure by default configuration”. This means when your software or device is first installed, it must have the most secure settings activated without requiring user intervention.
For development teams, this means secure configurations for databases, API endpoints, authentication mechanisms, and networking settings must be pre-configured.
Automated security updates with user opt-out capability
From Annex I: products must “ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism”.
This is actually a significant feature that, of course, adds a hefty weight in the development process. Because as we found out, even an automated security update can do damage if not properly handed.
Data confidentiality and integrity protection
The CRA mandates products must “protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms”. Also requires protection against “manipulation or modification not authorised by the user”. This means implementing:
- Data encryption in transit
- Data encryption at rest
- Integrity checks for data
- Protection against unauthorized modifications
Attack surface minimization
Products must “be designed, developed and produced to limit attack surfaces, including external interfaces”. This means:
Reducing unnecessary network ports
- Limiting exposed APIs
- Minimizing third-party dependencies
- Removing unnecessary features or services
Access control systems
The regulation requires products to “ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems”. Development teams must implement:
- Authentication mechanisms
- Identity management
- Access controls
- Reporting of unauthorized access attempts
Conclusions
CRA’s increasing presence offers easy security gains for users, but companies and developers will face challenges in implementation. This is an improvement for the OWASP top 10, and finally we can see some more drastic shifts.