Introduction

The Cyber Resilience Act (CRA) of the European Union is anticipated to transform the cyber ecosystem for digitally enabled products like software, hardware, and Internet of Things (IoT) gadgets. The CRA is designed to regulate products sold across the EU market, ensuring cybersecurity compliance for all products with digital elements (PDEs) entering the European Union. The European Commission is responsible for proposing and adopting the CRA, and can amend its requirements as needed.

The CRA impacts businesses of all sizes, including small businesses, manufacturers, and open-source projects, by imposing new cybersecurity compliance obligations and responsibilities to address evolving cyber risks across the product with digital element.

Security teams must take prompt action to ensure compliance and strengthen their product cybersecurity posture against emerging threats, particularly with enforcement set to begin in late 2027. Managing cyber risk is a critical component of CRA compliance, as organizations must assess and mitigate vulnerabilities to protect against cyber threats and cybersecurity risk. The increasing prevalence of these threats highlights the importance of the CRA, which aims to address these challenges for organizations operating in the EU.

The CRA applies to a wide range of software products, including commercial open-source software, and consumer products like baby monitoring devices are also covered under the regulation. Strict regulatory frameworks for product cybersecurity, vulnerability management, and incident reporting are being introduced by the CRA. Even if the deadline seems far, being ready early is essential. In this article, we will outline key best practices and explain how your company can meet stringent regulatory requirements by implementing robust security measures. The CRA introduces a comprehensive plan for manufacturers to follow throughout the product lifecycle to enhance cybersecurity.

Verify CRA Applicability and Timelines for EU market

First, we need to check if products fall under the CRA– specifically digital products with digital elements like hardware, software, and cloud agents. In some cases, regulations also cover open source software.

Understand Scope and CRA Product Classification

Start by identifying the products that come under the CRA scope. That includes any products, hardware, or software with direct or indirect network connectivity.

Categorize your products into one of the categories as below:

Default category: 90% of all digital components fall under this category, including products that are not directly identified as “important” or “critical”. The products range from basic software, common IoT gadgets, to smart home devices without strong security components. In this category, compliance is managed via a manufacturer’s self-assessment.

Important category: These products present a higher cybersecurity risk and threats, therefore, require close monitoring:

Important Class I – Products include functionality like identity management systems software and privileged access management software. It includes products that provide key cybersecurity features like operating systems, password managers, browsers, identity management tools, and VPNs.

Class II – Important products that are more critical than class I products like hypervisors and firewalls. It includes intrusion detection system, tamper-resistant microprocessors, and tamper-resistant microcontrollers.

Critical Category: In this category, products have major cybersecurity abilities and if those are compromised, it could severely impact other systems and infrastructure. That includes hardware security modules, smart-meter gateways, and secure elements like smart cards and cryptographic coprocessor. Due to high risk, these products require regular monitoring, mandatory regular third-party audits, and EU cybersecurity certification.

This classification determines your compliance rigor: critical products require independent assessments, while default ones rely on self-assessment.

21 Mandatory Cybersecurity Requirements:

Essential requirements based on product properties:

1. Product security requirements.

2. Requirement for vulnerability handling.

14 CRA Requirements for Product Cybersecurity:

1. Security by design – It is critical for the security team to assess the risk management process and ensure that appropriate mitigation strategies are implemented for the risks identified. The team must determine whether the documented process includes best practices for secure governance, design, implementation, and testing, such as OWASP SAMM, BSI TR-03185, and ISO 27034, before the product goes to the market.

2. Absence of Known Exploitable Vulnerabilities – The security team must verify that the latest security update has been successfully installed before a user accesses the Product with Digital Elements (PDE) for the first time. The verification is important to maintain the integrity and security of the product. The tester must confirm that any actively exploited vulnerabilities that the development team is aware of have been addressed.

3. Secure by Default Configuration – It is important to assess whether the PDE can be reset to its original state through a factory reset or reinstallation without any alteration. The team must verify that sensitive security data and keys are NOT hardcoded into the product’s software.

4. Security Updates – The automatic update mechanism must be turned on by default (with a clear option for users to opt-out). It is important for the security team to determine whether the PDE checks for updates at a suitable and regular period. The team must check that the product’s automated upgrade.

5. Access Control – The security team must ensure that the Products with Digital Elements (PDEs) implement appropriate control mechanisms, such as authentication and access management systems, to protect against unauthorized access and report potential unauthorized access incidents.

6. Data Confidentiality – The PDE should use evaluated cryptographic implementation. The performer must check that the cryptographic implementation is actively maintained.

7. Data Integrity – If the validation fails, the security tester must assess that the user is warned and notified of the restoration option. The team must follow cryptographic best practices to ensure data integrity and maintain robust security controls. The user should be able to remove software that was installed by the user themselves. It is important for the tester to determine that the PDE manages its own resources systematically, including, among other things, access to the file system, utilization of network connections, allocated/used memory, and management of other shared resources.

8. Data Minimization – The security team need to verify that only specified data is collected. They must ensure that any data that they process, whether personal or otherwise, is appropriate, persistent, and confined to the minimum necessary for the intended purpose of the product incorporating a digital component.

9. Availability of Essential Functions – The accessibility of fundamental and critical functions must be ensured, even post-incident, through resilience and denial-of-service attack prevention measures. It is key to check that all unnecessary interfaces are deactivated; and that local safety of functions is maintained during a loss of network, and all secure operations are resumed after temporary interruptions like network loss, power loss, and unavailable services.

10. Minimization of Negative Impact – The security team must determine that the PDE manages network resources during normal functioning, meaning that network resources utilized solely for the PDE’s intended purpose and foreseeable uses are released when no longer required. The team must minimize the adverse impacts that connected products, or the products themselves have on the availability of services offered by other networks or devices.

11. Limitation of Attack Surfaces – The security tester must assess that only interface services required for the initial setup are enabled before their usage by the user. First, they need to check which services and interfaces are required for the usage of PDE. Then, enable only those services and interfaces by default.

12. Mitigation of Incidents – The security team must verify that the PDE includes a permission system for interfaces offered to other items and determine that the PDE’s permission system is detailed enough to manage.

13. Recording and Monitoring – The security team must ensure that there is a system in place on the PDE to document and track all changes made to settings, and that the documented data holds sufficient details to examine irregularities in modifications relevant to security settings. This includes the originator, the timing, and the content/kind of the modification in the configurations. The checker should check whether the changes to the settings are logged automatically and verify that a system is in place on the PDE to document and oversee all user logins. The observer must determine that the documented information holds sufficient details to examine irregularities in user verifications. This encompasses the moment of authentication, the interface that was accessed or function, the origin of the authentication if present, and the outcome of the authentication attempt. The tester must ensure that user authentications are documented as a standard practice, and that the documented details provide sufficient data for analysis. This encompasses the initialization duration of a service and a routine status. The analyser should verify that an authorized user can deactivate and reactivate the system. The assessor must verify that the initiation and termination of the recording and monitoring activities are documented.

14. Deletion of data and settings – The Security Team must verify that the manufacturer provides a secure, admin-authenticated mechanism to permanently erase all user data, credentials, and configuration settings, fully aligned with EU Cyber Resilience Act (CRA) mandates. The assessment must confirm this deletion irreversibly restores the product to its factory default state, with no recoverable sensitive data left in active storage or backups. Clear, public instructions for executing the wipe must also be available to end-users.

7 Vulnerability Handling Requirements

1. Identification of components and Vulnerabilities – The security team must check that there is an – Software Bill of Materials (SBOM) documenting the software components of the PDE in the standardized format e.g. SPDX and CycloneDX. They must assess that hardware components with digital elements are documented. They must verify that there is a process in place to identify vulnerabilities affecting the PDE, and that they need to document the vulnerabilities and their mitigation. During vulnerability assessments and remediation, it is crucial to ensure that company information is protected, as this sensitive data could be exposed or targeted during a cybersecurity incident.

2. Address Vulnerabilities – The security team must assess whether the developers/manufacturer have documented and implemented a process to ensure that identified vulnerabilities are analyzed without undue delay and remediated in accordance with their associated risk level. This assessment must include vulnerabilities that can be actively exploited.

3. Regular Security Testing and Reviews – The manufacturer’s documentation and implementation of the method to test the PDE security attributes must be assessed by the team. They must assess if the maker routinely checks the PDE’s security features, such as every three months or whenever there is a significant modification to the device. According to that, the test must meet the security standards of this technical guideline and the assessment criteria. They must assess if the assessment criteria include a functional evaluation that is adequate for each security need, or if no functional assessment is conducted, that a sufficiently credible explanation is recorded and provided.

4. Publish Addressed Vulnerabilities – The Security Team must verify that the Manufacturer publishes security advisories for all addressed vulnerabilities promptly, aligning with patch releases. This assessment must confirm that each advisory includes the CVE identifier, severity score, affected versions, and fix instructions on a public security page. The Team must also check that the Manufacturer maintains a searchable archive of past advisories and offers notification options, such as RSS feeds or security mailing lists, to alert customers of new updates. Also check that security advisories are published in a format that can be processed by a computer. It is key to note that the security adversaries are published using a common security advisory framework.

5. Coordinated Vulnerability Disclosure Policy – As part of the vulnerability disclosure policy, the observer must determine whether the manufacturer has published an easy-to-reach contact option for reporting vulnerabilities, that the manufacturer has documented and implemented a vulnerability disclosure process. They should implement and publish a formal CVD policy in line with CRA requirements.

6. Secure Distribution of Updates – The Security Team must verify that all product updates are cryptographically signed to prevent tampering, delivered via encrypted channels to avoid interception, and automatically rejected if modified or unsigned—core EU CRA requirements for secure update distribution.

7. Dissemination of Updates – Tester are required to ensure that manufacturers promptly and, unless a business user and a manufacturer agree otherwise regarding a custom PDE, freely distribute security updates along with advisory messages that give users pertinent information, including possible courses of action.

Conclusion

The Cyber Resilience Act (CRA) of the European Union represents a significant shift in the cybersecurity landscape, strengthening manufacturers’ responsibility to ensure the security of their products throughout the entire lifecycle. It is important for the organizations to act promptly.

Compliance includes the following steps:

• Product categorization – To identify your product category.
• Secure development practices – To implement secure design principles, develop secure open source software, and engage in open development processes. To maintain SBOM, risk assessment, and to identify and address the vulnerabilities.
• Vulnerability management – To establish processes for timely identification, documentation, and remediation of vulnerabilities.
• Incident reporting – To detect, report, and maintain detailed records of incident.
• Document transparency – To record risk assessments, security measures, and compliance activities. All documentation should be readily available for inspection by regulatory authorities.

Organizations should also monitor cybersecurity trends to adapt their compliance strategies and stay ahead of emerging threats.