EU Cyber Resilience Act (CRA): What Tool Providers Really Need to Know

Software tools are central to the development, verification, production, and maintenance of safety-related and security-critical systems. Compilers, static analysis tools, model-based development environments, build systems, servers, firewalls, and IT management tools strongly influence the correctness and integrity of resulting products. Faulty, misused, or manipulated tools may introduce systematic errors that propagate across multiple downstream products and remain difficult to detect.

While functional safety standards traditionally address tool confidence in a systematic way, security standards do not and instead focus on system aspects. We call this the “Tool Security Gap”.

Recent cybersecurity incidents demonstrate that tools can also represent dangerous attack vectors within complex software supply chains. Unlike in the safety domain, tools may be even more critical than other aspects and therefore require systematic treatment. The European Union Cyber Resilience Act (CRA) gives tools the same priority as software, since it does not differentiate between software and tools. It introduces binding cybersecurity obligations for products with software (including tools) placed on the market.

Let's start with the definition of a tool.

In functional safety standards such as ISO 26262 and IEC 61508, a tool is software used to support development, verification, production, or maintenance activities, but is not integrated into the operational system delivered to the end user. Examples include:

• Compilers

• Simulators

• Static analysers

• Calibration tools

• Production-line testers

Tools differ from application software executed in the field and from libraries that are reused unchanged within application software. This distinction reflects the indirect influence of tools, whose impact is exerted through development and production processes rather than through runtime behaviour in the deployed system.

ISO/SAE 21434 requires that tools capable of influencing the cybersecurity of an item or component be managed. This includes tools used during development, production, and maintenance. However, the standard deliberately remains high-level and does not define explicit tool security levels, classification schemes, or qualification objectives, leaving implementation largely to organisational interpretation.

Several incidents illustrate the systemic risk posed by compromised development tools and dependencies. The Ken Thompson “Trusting Trust” scenario demonstrates how a manipulated compiler can introduce hidden behaviour into all generated binaries. Stuxnet provided the first real-world example of a toolchain attack with direct safety impact by manipulating a PLC development environment while masking abnormal behaviour.

More recent supply chain attacks, such as SolarWinds and the XZ Utils backdoor, show how compromised build processes or widely reused components can silently affect large numbers of downstream users. These examples highlight that development tools and dependencies represent high-value attack targets whose compromise can have widespread, cascading effects.

Below, you’ll find answers to some of the most common questions about the EU Cyber Resilience Act (CRA). If you’re a tool provider looking for clear guidance or support, feel free to get in touch with us.

Yes. The Cyber Resilience Act applies to products with digital elements placed on the European market and does not distinguish between application software and development tools. Software tools with digital functionality and network connectivity, such as update mechanisms, license servers, telemetry features, or communication interfaces, may therefore fall within the scope of the regulation.

For tools within scope, the CRA requires risk analysis, implementation of appropriate risk reduction measures throughout design, development, and production, vulnerability handling processes, and supporting technical documentation. Transitional provisions apply to unchanged tools, with an initial focus on reporting obligations.

The good news is: if your tool has not significantly changed, you only need to establish the vulnerability reporting.

Article 14 of the Cyber Resilience Act defines mandatory vulnerability reporting obligations for manufacturers of products with digital elements. For software tools that remain unchanged, Article 14 constitutes the primary initial CRA requirement. In this phase, manufacturers are required to establish processes to identify, assess, and report actively exploited vulnerabilities and incidents, without yet implementing the full set of risk reduction measures.

Reporting follows a staged approach, including early warnings, formal notifications, and, where applicable, a final report. Clear responsibilities for vulnerability handling and maintained information on affected users or deployments are required. Full CRA compliance becomes mandatory once tools are modified or further developed.

Vulnerability reporting follows a staged approach, including early warnings, formal notifications, and, if needed, a final report. Manufacturers must define clear responsibilities for handling vulnerabilities and maintain accurate information on affected users or deployments.

Full CRA compliance becomes mandatory when a tool is modified or further developed. At that point, manufacturers must implement the complete set of obligations, including risk reduction measures, cybersecurity controls, and full technical documentation.

CRA compliance for tool providers typically starts with setting up vulnerability handling and reporting processes, including defined roles, reporting channels, and documentation artefacts. For new or updated tools, it expands to structured risk analysis, cybersecurity control implementation, residual risk management, and technical documentation. Most development tools can use Module A (self-assessment/internal control) for conformity assessment.

Our Compliance and Safety Framework (COSAFE) integrates requirements from functional safety, cybersecurity, and regulatory frameworks such as ISO 26262, ISO/SAE 21434, and the CRA. It emphasises structured process definition, traceability between requirements and activities, verification planning, and the generation of compliance-relevant documentation.

Within COSAFE, Validas offers a certification guarantee stating that there will be no problems in assessments, no delays, and no extra costs. This guarantee is based on a semi-formal approach to modelling processes, requirements, and compliance. This approach is implemented through the PMT (Process Management Tool).

• Stuxnet (toolchain / ICS attack) - Stuxnet analysis PDF

• SolarWinds (software supply chain compromise) - CISA SolarWinds remediation guidance

• XZ Utils Backdoor (2024 supply chain attack) - Red Hat–referenced advisory context