The European CRA requirements are primarily defined in Annex I. There are four additional Annex documents as well:

• Annex II - Describes the documentation required to be included with each product.
• Annex III - Provides examples of the two classes of products.
• Annex IV - Outlines the EU Declaration of Conformity.
• Annex V - Lists the technical documents to be included with each product.

The EU Joint Research Centre (JRC) and European Union Agency for Cybersecurity (ENISA) issued a document to outline how the CRA requirements map to existing industry standards, including EN IEC 62443. Their free document at enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping is a helpful guide for companies who have already adopted one of these standards.

Annex I is divided into two sections. Section 1 addresses the properties of the products and Section 2 addresses how the supplier will respond to the discovery of vulnerabilities.

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks;

(2) Products with digital elements shall be delivered without any known exploitable vulnerabilities;

(3) On the basis of the risk assessment referred to in Article 10(2) and where applicable, products with digital elements shall:

(a) be delivered with a secure by default configuration, including the possibility to reset the product to its original state;

(b) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems;

(c) 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;

(d) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, as well as report on corruptions;

(e) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended use of the product (‘minimisation of data’);

(f) protect the availability of essential functions, including the resilience against and mitigation of denial of service attacks;

(g) minimise their own negative impact on the availability of services provided by other devices or networks;

(h) be designed, developed and produced to limit attack surfaces, including external interfaces;

(i) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;

(j) provide security related information by recording and/or monitoring relevant internal activity, including the access to or modification of data, services or functions;

(k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users.

If you are developing a test system that is subject to these requirements, you will need to adopt a development process that meets the first requirement. There are multiple security development frameworks available, including the Microsoft Secure Development Lifecycle and the US Government Secure Software Development Framework documented in NIST 800-218. While these are not developed for test systems or products like LabVIEW or TestStand, they contain general principles which apply to any system development. You can use these to create a process for your team that will meet the CRA requirements.

As you plan the features of your test system, you will need to consider the additional requirements of the CRA. You will need to plan for controlling access to the test system, both by users and by external systems. You will need to identify which data needs to be protected through encryption and how that data will be encrypted. You will need to develop defenses against attacks. You will need to document activity into audit logs. And you will need to plan for security updates to the components of the system.

This work will incur an additional burden on your development team, and you need to carefully consider the additional costs during your project planning phases. Work with your customer to understand the options for security and who will own the responsibility for post-deployment system updates to maintain the security of the system.

It is important to note that security must be viewed at the system level. Some components will not meet all of these requirements alone. But combined with other parts of the system, those gaps should be protected so that altogether you can demonstrate full system security.

Finally, do not underestimate the value and the effort to provide full security documentation. You should document how the system meets the CRA requirements. And you should include documentation to restore the system to a baseline secure configuration - this will be a critical resource if an attack ever disables the system. It can also be used to ensure the system is not adjusted away from that secure configuration.

Manufacturers of the products with digital elements shall:

(1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product;

(2) in relation to the risks posed to the products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates;

(3) apply effective and regular tests and reviews of the security of the product with digital elements;

(4) once a security update has been made available, publically disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and information helping users to remediate the vulnerabilities;

(5) put in place and enforce a policy on coordinated vulnerability disclosure;

(6) take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements;

(7) provide for mechanisms to securely distribute updates for products with digital elements to ensure that exploitable vulnerabilities are fixed or mitigated in a timely manner;

(8) ensure that, where security patches or updates are available to address identified security issues, they are disseminated without delay and free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

The documentation you deliver with the system may need to include an SBOM.. An SBOM includes all of the software components of the system. In recent attacks, companies have experienced an urgent hunt for components to identify which systems contain the software which is open to attack. SBOMs provide a way for companies to maintain an inventory of software, compare that inventory to reported issues, and manage systems that contain the issues.

More SBOMs will increase transparency to end users of the ways that their systems are vulnerable to attacks. Suppliers will be called on more frequently to provide security updates. Suppliers are required by the CRA to provide these updates for 5 years after delivery of a product or system - your team needs to develop a plan to provide that support.

Taken altogether, these CRA requirements will improve the security defenses of test systems. But it also increases the amount of work on system developers and the expectations they have on suppliers like NI.

See how NI provides resources to help your team meet these expectations.

• Subscribe to security announcements
• Download security updates
• Report a security issue