EU Cyber Resilience Act: Socio-Technical and Research Challenges

During the first year after its implementation, CRA’s primary goal is to promote developer awareness. This campaign must be performed at a global scale, as CRA will impact on any manufacturer or software developer targeting the EU market. Although the provisions of CRA might appear vague and high-level (as we will discuss in the context of current standards), their consequences are broad and global. In fact, it is important to first understand whether developers will perceive CRA as a challenge or a barrier that may impact their processes and business. Since the CRA makes a distinction in compliance obligations based on the risk-category/type of product/service and not the size of the firm that offers those, the CRA is asymmetric but only with regards to product type, not in terms of compliance obligations and resulting cost. This could lead to a crowding out of small firms in some contexts (e.g., limited resources and mechanisms to comply). These aspects highlight the need for agencies to start awareness campaigns promptly, drawing from lessons learned from previous regulations like GDPR by CNIL and other EU Data Protection Agencies.

This first awareness stage opens interesting research opportunities to measure the effectiveness of these campaigns to raise developer awareness. It is still unclear which channels and mechanisms regulators will use to effectively raise global awareness. We propose utilizing platforms like mobile and IoT platform app stores and technical development forums (e.g., StackOverflow) for raising awareness and facilitating communication between regulators and developers. Seminar participants emphasized that these efforts must be accompanied by well-grounded and pragmatic standardization processes – still an ongoing process – , to provide comprehensive technical documentation that can facilitate compliance and understanding of current regulatory requirements. By addressing these key areas and questions, regulators and developers can work together to ensure effective compliance with CRA, fostering a more secure and resilient software development ecosystem.

The CRA requires vendors to perform self-attestation on certain security properties (e.g., use of cryptographic functions),⁷⁷7https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-
mapping meaning they must internally assess and document their compliance with the Act’s security requirements throughout its life-cycle; i.e., from the designing to the post-release stages of the product. However, these requirements vary depending on the criticality of the product, and they do not seem well-specified. Consequently, clear definitions of the responsibilities and liabilities of developers and vendors are essential to avoid uncertainty and ensure compliance but rule requirements are still too high level. One discussion revolved around whether these points may become more concrete as standards get developed. This clarity could be enhanced through collaboration with platforms like GitHub, developer forums and events, and other development repositories, and involving more actively the research community in this process.

The base of secure-by-default assessments raises questions: Will it be done via checklists or based on a set of standards? This approach has proven ineffective in prior regulatory contexts such as the USA COPPA rule, even when assisted by organizations forming part of certification schemes [7]. We suggest that we need more process-oriented approaches, focusing on a methodology rather than a simple checklist, similar to the SSDF NIST SP800-218 framework.⁸⁸8https://csrc.nist.gov/pubs/sp/800/218/final Creating guidelines and clear procedures is vital for enabling seamless compliance and fostering a secure software development environment. These frameworks, tools, and processes – currently non-existent – could be integrated into Integrated Development Environment (IDE) tools, which would indeed open exciting research and market opportunities. For instance, formal verification tools or tools for automatic Software Bill of Material (SBOM) generation and management could be developed and integrated into IDEs, providing centralized repositories of libraries to help developers manage dependencies effectively. Yet, while self-attestation encourages vendors to proactively identify and fix security issues and comply with regulatory requirements, it is possible that certain vendors may have incentives to avoid compliance and elude external controls. Consequently, this opens an interesting research problem that involves developer studies and empirical approaches to understand developer incentives and the effectiveness of various self-attestation approaches to reduce the number of vulnerable devices in the EU market. st.” SSDF NIST SP800-218 (https://csrc.nist.gov/projects/ssdf).

A significant amount of seminar time and effort focused on Software Bill of Materials (SBOMs)⁹⁹9https://www.cisa.gov/sbom extraction and generation. SBOMs are a key concept in the CRA because they provide a comprehensive inventory of all components and dependencies in a digital product, which is crucial for identifying and managing vulnerabilities. SBOMs enhance transparency and security by allowing regulators and developers to trace, verify, and address potential risks throughout the software supply chain. Therefore, ensuring the accuracy and trustworthiness of SBOMs is essential but, can SBOMs released by developers and vendors be entirely accurate? Should developers’ self-disclosed SBOMs be trusted?

While the German Federal Office for Information Security (BSI) and other EU national agencies have released guidelines for SBOM generation and management,¹⁰¹⁰10https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html it is known that vendors and developers face challenges in keeping track of all dependencies when integrating open-source tools and third-party code, as many of their dependencies can be proprietary black-boxes outside their control [5, 3, 6, 8]. Additionally, as several research studies show, developers also struggle at maintaining effectively their dependencies: prior work results show that app developers only slowly adapt new library versions, exposing their end-users to large windows of vulnerability [1].

This complex scenario is compounded by the high number of supply-chain attacks that can negatively impact the security guarantees of a digital product. However, one discussion point was about the level of information expected to be disclosed by developers about their dependencies, and whether this will be effective at tackling issues such as those described by Backes et al. [1]. This opened a discussion about the need for proper labeling [3], and how to include versioning (and customization, as for example in open-source libraries) of dependencies in the SBOMs throughout the whole lifecycle of the product, as libraries and dependencies can experience multiple changes and releases along the supply chain. This may have direct consequences on users’ security. For example, will all developers using open-source tools maintain and send upstream patches to their products to fix vulnerabilities they have found in their products? Will they have the right mechanisms to ensure that all their customers get the patches?

Establishing a reliable method to gain control over the supply chain and verify the correctness of SBOMs using both black- ¹¹¹¹11Black-box testing or closed-box testing is a form of software testing that is performed with no knowledge of a system’s internals, and it can be carried out to evaluate the functionality, security, performance, and other aspects of an application. and gray-box ¹²¹²12Gray-box testing is a method you can use to debug software and evaluate vulnerabilities with some but limited knowledge of the workings of the component being tested. testing techniques is essential, especially when considering the potential lack of developer awareness or in cases of potentially deceptive developers. Microsoft has developed open-source tools for SBOM generation.¹³¹³13https://github.com/microsoft/component-detection¹⁴¹⁴14https://github.com/microsoft/sbom-tool These tools could be integrated into IDEs to raise awareness and would benefit from a community-built repository of third-party library fingerprints for detection. However, we note that creating such repository is a daunting effort (particularly in terms of maintaining it due to versioning and – in the case of commercial libraries offering analytics and advertising SDKs – due to company merges and acquisitions). Moreover, it is also known that fingerprint-based methods with static analysis methods can easily introduce false positives (e.g., identifying libraries that may not be actually integrated in the code), and false negatives (e.g., not identifying libraries in obfuscated programs), as the research literature in the mobile domain has shown [9, 5]. One challenge would be how to extract SBOMs from software running in the cloud, either partially or entirely as in the case of Amazon Skills [4]. In these scenarios, the platform could do the dependency checks, however there are lambda functions that can be used by deceptive developers to avoid scrutiny.

Shadow libraries and dependencies, i.e., where developers (partially) copy-paste someone’s code to take responsibility, might make it difficult to fix critical code as these developers may be using under-resourced/homebrew code without investing in its testing/development/maintenance.

In fact, many vulnerabilities manifest across connections between chunks of code. Therefore, it is necessary to manage the exposure to responsibilities for these problems. For instance, an incorrect use of methods provided by a cryptographic library can have devastating consequences for software security. Unfortunately, the concept of SBOM may only reveal that a particular library is used but not such development errors.

Participants pointed out that most scenarios will require SBOM extraction and generation from binary files since developers may introduce libraries during compilation time or even compiled products with incomplete SBOMs [2]. There is a risk of an entity not knowing what chain of dependencies are in their software, and automation could reveal unexpected hidden risks. Yet, it is an open research challenge to check the correctness of SBOMs from binaries, especially for regulators needing to verify vendors’ and developers claims. This may have legal consequences given EU laws prohibiting reverse engineering as we will discuss in §6.1.

Several tooling systems are available to aid this process, such as OWASP CycloneDX¹⁵¹⁵15https://cyclonedx.org/ and SPDX¹⁶¹⁶16https://spdx.dev/ by the Linux Foundation. It is important to ensure developers do not run scared if there is too little information available, making the compliance process too daunting. CRA may result in more awareness of what elements the code is linking to. A kind of ‘dependency amnesty’ could encourage those down the chain to provide an SBOM. Otherwise, each developer needs to know all the code they use, even if it’s in a library made by someone else. ol and the high number of supply chain attacks that can negatively impact on the security guarantees of a digital product. It is essential establishing a reliable method to gain control over the supply chain and verify the correctness of SBOMs using both gray- and black-box testing techniques as questions arise about when to trust an SBOM disclosed by the developer due to lack of developer awareness or in the case of potentially deceptive developers. Another discussion point was regarding how to do labeling and versioning of SBOMs throughout the whole lifecycle of the product as libraries and dependencies can experience multiple releases.

Vulnerability disclosures are critical in the context of the CRA as they ensure that all identified security weaknesses are promptly reported and addressed to the software developer/vendor when identified, thereby reducing the risk of exploitation. By mandating transparent and timely disclosure of vulnerabilities, the CRA aims to foster a culture of accountability and continuous improvement in software security, thus enhancing the resilience of digital products and protecting consumers and businesses from cyber threats.

The research community, including organizations like OWASP,¹⁷¹⁷17https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html has established several best practices for responsible disclosures to ensure that security vulnerabilities are addressed effectively and ethically. Generally, these practices involve a coordinated process where researchers privately notify the affected vendors about the discovered vulnerabilities, providing them with detailed information and a reasonable time frame to develop and deploy fixes. The standard time frame for fixing a security issue is around 90 days, although this can vary depending on the severity of the vulnerability and the complexity of the fix required and the challenges to demonstrate evidence of in-the-wild exploitation. Researchers are encouraged to maintain confidentiality and offer assistance during this period. In practice, there are many challenges and hidden incentives that often impede proceeding according to these best practices. As discussed in the seminar, vendors and software developers are not always proactive in releasing patches for their products, and researchers often struggle at finding the right communication channel or contact point at a particular vendor. Additionally, defining what constitutes a vulnerability is complex, with debates on whether all vulnerabilities require a CVE ¹⁸¹⁸18CVE stands for Common Vulnerabilities and Exposures. CVE is a glossary that classifies vulnerabilities. The glossary analyzes vulnerabilities and then uses the Common Vulnerability Scoring System (CVSS) to evaluate the threat level of a vulnerability. and how to handle vendors that do not acknowledge some vulnerabilities (i.e., “won’t fix”). In fact, the CVE format, while widely used by the security community, is not always the best option. Examples are attacks related to personal data access or privacy concerns.

When a developer claims that a reported vulnerability is actually a feature and decides not to fix it, it presents a significant challenge in the responsible disclosure process. This situation requires careful handling to ensure security concerns are addressed without dismissing valid reports. Researchers should document their findings thoroughly and provide a clear explanation of why the identified issue constitutes a vulnerability, including potential risks and impact on users. They can escalate the matter by seeking a second opinion from independent security experts and even openly disclose the vulnerability to raise broader awareness (e.g., through interactions with the press or academic publications). In some cases, involving regulatory bodies or industry standards organizations may be necessary to resolve the dispute and ensure that security vulnerabilities are not overlooked under the guise of being a feature. This approach helps maintain a balance between legitimate security concerns and the developer’s design choices, ensuring that user safety remains a priority. CRA articles 32-34 and ENISA’s “Good Practices for Vulnerability Disclosure”¹⁹¹⁹19https://www.enisa.europa.eu/publications/vulnerability-disclosure set minimum requirements for vulnerability disclosures and offer detailed guidance on handling and disclosing vulnerabilities, including scenarios where there might be disagreements on whether an issue is a vulnerability. In the USA, CISA has also defined a new framework for documenting vulnerabilities. It will be important to monitor if CRA will have a positive impact on the responsible disclosure process to ensure that vendors effectively take measures.

Yet, regulators face the challenge of ensuring that every vulnerability is disclosed, clearly defined, and ultimately patched in the products. Moreover, the risk of criminalizing researchers who find vulnerabilities exists: while reverse engineering is usually allowed for achieving interoperability, research, and security analysis, companies can decide to take legal action against security researchers. Additionally, there is the potential exploitation of identified vulnerabilities by authorities as part of this process that could be used for cyberwarfare, such as zero-day exploits. It would be necessary to facilitate mechanisms to increase the transparency of these processes and the interactions between researchers and vendors, hence increasing public awareness on patched and unpatched vulnerabilities.

CRA opens multiple interesting research and industrial opportunities in the context of vulnerability disclosure and product lifecycle management. For example, better defining what a vulnerability constitutes (would privacy threats fall in this context?), finding effective means for balancing intellectual property protection and security – a challenging socio-technical problem in the context of the CRA – , or conducting empirical measurements to see whether CRA has indeed contributed to fix vulnerabilities in digital products. Performing such empirical analysis would be similar in objectives to those measurements showing whether GDPR has contributed to protect users’ privacy on the web. Consequently, measuring the impact of regulations in-the-wild is inherently hard to measure as there is a diffusion process of impacts across digital ecosystems and jurisdictions.

Product life cycle management is essential to ensure that security measures are maintained throughout the entire lifespan of a product, from development to end-of-life. This continuous oversight helps in (promptly) addressing and patching emerging vulnerabilities and maintaining compliance with security standards and requirements over time. However, product life cycle support may vary significantly depending on manufacturer/developer incentives and security standards, the product type (e.g., a smart bulb vs. a smartphone), so the CRA should include clear and specific vendor requirements tailored to different product categories and their inherent threats.²⁰²⁰20CRA article 6 states: “When placing a product with digital elements on the market, and for the expected product lifetime or for a period of five years from the placing of the product on the market, whichever is shorter, manufacturers shall ensure that vulnerabilities of that product are handled effectively and in accordance with the essential requirements set out in Section 2 of Annex I.”

Seminar participants did not observe strict requirements on how vendors should acknowledge vulnerabilities, the confidentiality clauses (as it can be abused by vendors to avoid fixing issues), and the time required for fixing the vulnerability (Annex I states “without delay”), as well as usability requirements to inform users about the security properties of a product and means to reduce threats or patch products. Based on GDPR experience, it is unclear whether vendors will diligently and clearly inform users, and what will be the temporal support of vendors over their products as, for example in the case of smartphone manufacturers, they will have to dedicate engineering teams to support various product lines with specific hardware requirements. This has been identified as another problem that could be better studied through developer studies and large-scale empirical measurements.

The second day, the group discussed the latest²⁶²⁶26As of March 2024 ENISA’s standardization guidelines. These aim at identifying relevant existing cybersecurity standards for each CRA requirement, analyzing their scope, and highlighting potential gaps to be addressed. The guidelines help in integrating standards into development processes, ensuring that developers follow secure-by-default principles throughout the product lifecycle.²⁷²⁷27https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/. The file containing the updated version (April 4th 2024, released after the seminar) of the standardization guidelines is available here. During the seminar we had access to the previous version of these guidelines and the general observations that we made about the scope and coverage of these standards apply also to the updated version.

As regarding the security guidelines relating to the properties of products with digital elements the group wonders whether there will be tools available to help lower-resourced entities to meet these standards due to asymmetric approaches that may increase the burden to small-size organizations based on the type of product. Moreover, the group collected several observations on the proposed guidelines. For example, the document refers to “product with digital element”, this definition should be better specified as in its current form it, for example, also applies to a 1970s radio alarm clock with a digital display. The group also discussed the high level scope and description of requirements, which could be potentially abused by vendors to avoid scrutiny and may not apply to specific types of products and sectors.

The general consensus among participants is that, although the guidelines offer some direction for developing security standards, they still leave several aspects open to interpretation and their scope must be extended to the broad range of digital products, while being flexible enough to catch up any technical development, use-case, and innovation.

In the latest discussion, the group examined existing standards, including the ETSI Cyber Security for Consumer Internet of Things: Baseline Requirements from 2020.²⁸²⁸28https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf Participants noted some outdated recommendations and problematic choices, such as entrusting the threat model to the manufacturer. For example, Provision 5.5-5 states “device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. The exception is for network service protocols that are relied upon by the device and where the manufacturer cannot guarantee what configuration will be required for the device to operate. NOTE 3: Protocols that are an exception include ARP, DHCP, DNS, ICMP, and NTP.” In this particular example, this standard leaves fundamental network security improvements by ignoring encrypted versions of some of these protocols such as DNS-over-HTTPS (DoH) and the encrypted version of NTP, known as NTPS.

This approach could allow vendors to avoid liability for certain vulnerabilities or claim that patching is difficult due to the device’s nature. The group emphasized that standardization efforts must consider developers’ software development approaches, needs, and the complexities of the supply chain. They should also be updated more frequently to incorporate newer security measures and protocols, and unknown exploits.

The group also discussed the need for standards for SBOM (Software Bill of Materials) management and clear definitions of what constitutes a vulnerability and guidelines for the disclosure process that may protect security researchers and consumers from potential enterprise interests. In conclusion, the general opinion is that the definition of appropriate standards may be a challenging task due to the complexity of existing technologies and the constantly evolving threat landscape: standards can quickly become obsolete and give final consumers a wrong sense of security.

The principles of security-by-design and security-by-default are essential in the CRA, which should be effectively captured in upcoming standards. Specific sectoral security requirements must be clearly defined to establish a comprehensive catalogue for certification and also for a complete catalogue of threat models. Participants consider that reference threat models and Key Performance Indicators (KPIs) are critical for facilitating and measuring CRA adoption. Additionally, understanding the costs of regulatory enforcement and vendors’ compliance in relation to their available technical, engineering and human resources is vital.

Mandatory technical documentation for compliance verification, along with third-party assessments or endorsements by trusted Certificate Authorities can help to enhance compliance. However, self-certification can be exploited by deceptive actors, particularly if this process does not involve code reviews or software testing as occurred in the case of organizations participating in the U.S. Federal Trade Commission COPPA Safe Harbor program.²⁹²⁹29https://www.ftc.gov/enforcement/coppa-safe-harbor-program

While attestation at the level of Member States is essential, incentives for data sharing across jurisdictions could improve enforcement and control, particularly benefiting those Member States with less human and technical resources, also reducing the arbitrary decisions that have been observed in enforcing GDPR in certain countries. There are questions about the feasibility and scalability of general auditing tools for devices and whether the Cyber Resilience Act (CRA) provides new tools for enforcement. The duration of attestation and the time required to remove potentially vulnerable devices from the EU market also needs consideration.

The intersection of Intellectual Property (IP) protection laws and the CRA also raises concerns, which may require changes to current intellectual property laws to facilitate reverse engineering for compliance and independent testing. Vendor liability and certification authority accountability, especially if cheating occurs, need examination and consideration. The distribution of responsibilities among supply chain actors for a given service or product, and the exclusion of cloud services from the CRA’s scope, focusing solely on device software and hardware, are points for consideration from a research perspective.

To conclude the following questions and observations need to be addressed:

• $\mathrm{■}$

  What are the (broader) economic impacts of CRA enforcement? Which metrics can be used or need to be developed to measure this impact?

• $\mathrm{■}$

  How will the CRA change developers’ incentives (e.g., with regard to their R&D efforts)? How will developers perceive the CRA and how will they respond to it? Will they view it as a burden or a beneficial regulation, and will they try to avoid regulatory scrutiny as seen with GDPR?

• $\mathrm{■}$

  Implementation of security-by-design principles in complex devices like IoT.

• $\mathrm{■}$

  Consideration of manufacturer disclaimers to avoid scrutiny and limit liability.

• $\mathrm{■}$

  Development of device and software verification standards and guidelines, both for device manufacturers and for independent certification authorities (and labs) or regulatory bodies. ³⁰³⁰30https://owasp.org/www-project-iot-security-verification-standard/

• $\mathrm{■}$

  Concerns that developers might perceive the CRA as a burden, similar to GDPR, potentially leading to non-cooperation with regulatory investigations, to avoid regulatory scrutiny (e.g., anti-testing) or barriers for small firms to enter the market and innovate, thus potentially stifling innovation by such firms.

In this discussion, group members examined the methods and challenges associated with measuring CRA compliance and standard adoption. The discussion covered various approaches and tools for verification, as well as the potential benefits and drawbacks of different strategies.

Effective measurement of compliance with standard adoption requires the development of testable guidelines for technologies that ease the integration of Continuous Integration (CI) tools for standard verification. Software-based compliance verification is proposed as a potentially more effective alternative to traditional certification authorities, based on check-lists. Additionally, the potential for IoT Industry alliances (e.g., IoxT³¹³¹31https://www.ioxtalliance.org/) and their certifications to satisfy CRA requirements needs careful consideration. Establishing clear guidelines by device categories and addressing the gap between certification, adoption guidelines, and enforcement is crucial for compliance.

Enforcement and standardization are closely intertwined, particularly within the framework of the CRA and its voluntary certification program. Effective regulatory enforcement necessitates the alignment of these efforts with standardization processes, while also addressing the challenges posed by Intellectual Property laws. The complexity of identifying trustworthy certification programs is compounded by varying national accreditation systems and the emerging market for certification schemes. Yet, the creation of standards discussed earlier, also necessitates sufficient resources and authoritative bodies, with the current reliance on industry proposals posing a limitation. The US system, such as NIST’s Cybersecurity CMMC³²³²32https://www.nist.gov/mep/successstories/2020/leading-way-cmmc-compliance could serve as a viable model.

While the tools for CRA enforcement are yet to be determined, they are anticipated to be clarified with the law’s approval. However, these regulatory efforts must be aware of the limitations of current software testing methodologies, particularly in terms of scope and scale (not to mention the testability of specific regulatory requirements). Proposals include self-assessment for low-risk products and a EU-wide certification framework for high-risk products, with the European Commission expected to publish a list of high-risk categories. This requires observing these developments and analyzing their alignment with current white- and black-box testing capabilities for device and software security analysis.

The evolving interplay between regulatory enforcement, standardization, and economic impacts underscores the need for precise definitions of enforceable properties, robust evaluation and compliance tools, and comprehensive certification processes. Moving forward, participants believe that the success of the Cyber Resilience Act (CRA) will depend on aligning these efforts with existing software engineering and analysis frameworks, and adapting intellectual property laws like the EU Copyright Act. These are necessary measures to ensure thorough and effective regulatory enforcement.

• $\mathrm{■}$

  How can we measure the compliance of standard adoption and regulatory compliance in various sectors, particularly complex consumer IoT products integrated in multi-party and multi-agent environments?

• $\mathrm{■}$

  What are the differences between the scope of existing guidelines and CRA ultimate goals, and how can guidelines be tailored by device categories (e.g., IoT) or sectors?

• $\mathrm{■}$

  (How) Can the efforts started by IoT industrial alliances (e.g., IoxT), including standardization and certification processes, be leveraged for CRA compliance?

• $\mathrm{■}$

  Can standard and CRA requirements be integrated into CI tools to automate verification prior release?

• $\mathrm{■}$

  How can the balance between intellectual property protection and CRA compliance be managed? Are changes to intellectual property laws necessary to facilitate CRA enforcement and independent verification?

• $\mathrm{■}$

  What are the liability implications for vendors and certification authorities (and labs) if they are found to be non-compliant?

• $\mathrm{■}$

  What role will gatekeeping intermediaries and stakeholders, such as platform operators, e-commerce platforms and software distribution channels, play in removing non-compliant software/products from their platforms?

• $\mathrm{■}$

  What tools or frameworks can complement certification authorities with software-based test cases (black-box) for automated and independent compliance verification?

• $\mathrm{■}$

  What white-box and black-box tools can aid self-assessment for compliance based on risk, particularly for low-risk and high-risk products and the supply chain?

• $\mathrm{■}$

  What principles and methodologies of current certification processes from other regulated markets, such as food safety regulations or aerospace, be adapted to CRA?

Standardization bodies must establish and refine comprehensive standards and guidelines for CRA quickly. These should offer guidance on the scope of the regulation and consider sector-specific or device-specific requirements. The research community must evaluate whether these requirements align with threats and risks identified by the community on consumer-oriented products to effectively protect consumers and identify vendors with deceptive and insecure practices. It is also fundamental to investigate how digital platforms and software distribution platforms can help mitigate the impact of malicious actors through guidelines and publication policies as in the case of the COPPA and GDPR regulations (e.g., collection of unique identifiers and other data types in children-oriented apps).

The development of standards and guidelines is fundamental for CRA adoption and compliance. We must have a multi-disciplinary debate to develop these standards and guidelines, and to analyze and discuss the scope of new standards, including the necessity for sector-specific standards. Regulators should actively promote these standards and provide clear, specific guidance on compliance, learning from the adoption and enforcement pitfalls of GDPR: standardization efforts should go hand in hand with tools for assessing compliance by vendors. The research community could inform these efforts and assess their scope and effectiveness, drawing on their research experience with consumer IoT devices and cybersecurity.

It is essential to conduct longitudinal developer-oriented studies (e.g., surveys) to gauge developer awareness, readiness, and incentives for compliance with CRA requirements. To maximize success, these efforts could be done in collaboration with regulatory bodies and digital platforms and marketplaces. We also consider important to encourage contributions to open-source projects by providing incentives, and addressing legal and IP issues to balance security and independent certification, with innovation. In fact, transparency regarding security guarantees (e.g., vulnerability patching) and obligations from vendors to users is crucial. Considerations of usability and incentives are also important (for instance, if someone buys an expensive smart refrigerator that is later found to be vulnerable, do users have incentives to isolate it as it will become just a regular fridge?). What legal expectations are there for such situations? It is important to consider the impact of CRA on the economy, including consumer expectations, market adoption, and international implications.

Once standards are in place, it is key to develop methodologies and tools to assist developers with compliance, including tools for SBOM generation and vulnerability management. We also advocate for and support research in formal verification methods to ensure the accuracy and reliability of SBOMs and other compliance measures that developers can use during the design and development of their products. This is especially important for resource-constrained organizations with limited financial resources. Yet, these tools must be complemented with others for independent testers (e.g., regulators, certification authorities, researchers) to facilitate external certification and assessment, recognizing that self-attestation and check-list based approaches may not always be effective. These efforts must investigate the feasibility and scalability of developing a general tool for auditing devices under CRA, and assessing the testeability of certain regulatory requirements. We must not ignore usability considerations and developer incentives for using these tools and maintaining product security throughout their life cycle. While there are companies and research efforts already offering tools for managing SBOMs, the experts expressed concerns regarding the technical challenges of SBOM generation and the aptness of regulatory requirements, which only require developers to disclose high-level dependencies. We consider essential creating effective black-box analysis tools for library version detection as it is critical for pin-pointing specific program vulnerabilities.

Increase public outreach efforts to enhance transparency regarding security guarantees and mitigations offered by vendors, considering usability and incentives for users. Furthermore, regulators need to actively inform and guide vendors on CRA compliance requirements to avoid the pitfalls experienced with GDPR.

We consider key to study the overall economic impact of CRA enforcement and develop metrics to evaluate this impact. This will allow us to assess developer perceptions of CRA to understand to which extent it is seen as a burden and in which respects it is seen as a necessary and appropriate regulation by vendors. We recommend performing active scans of the EU’s Internet Protocol (IP) address space to monitor the deployment of legacy non-compliant devices with public IP addresses and assess CRA’s impact on replacing or isolating them.

Several participants urged for a Systematization of Knowledge (SoK) on CRA, focusing on informing the research community about this new regulation and the identified cross-disciplinary research challenges. Additionally, we considered the need to establish an EU MSCA-ITN (Marie Skłodowska-Curie Actions Innovative Training Network) to train future CRA experts with the necessary multidisciplinary background and skills.