Cyber Resilience Act (CRA)
for legacy device software

Vulnerabilities must be fixable through security updates, and updates must be distributed securely – without delay, free of charge and, where technically feasible, separately from feature updates. Many legacy devices have no designated mechanism for this: updates are done by a service technician, via USB stick or not at all. We retrofit an update mechanism that fits your hardware and your operations, for example with signed update packages, so that only approved software reaches the device.

Products must not be placed on the market with known exploitable vulnerabilities. Legacy software often contains components for which regular security updates are no longer available. A common example: standard support for Qt 5.15 ended on 26 May 2025; since then, only paid security patches for most Qt libraries have been available, excluding third-party components. We update or replace such dependencies step by step – for Qt, for instance, by migrating to Qt 6.

Manufacturers must test their products regularly, remediate vulnerabilities without delay, publish information on fixed vulnerabilities and provide a contact address for reports. But a patch only helps if it can be delivered quickly and without side effects. That is why we continuously match newly disclosed vulnerabilities against your SBOM and safeguard changes with automated tests – so that a security update does not itself become a risk to functionality.

The CRA sets out how the support period is determined: it must reflect the product’s expected period of use and be at least five years, unless the product is expected to be in use for less than five years. You must inform your customers of the end date, and every security update must remain available for at least ten years after its release, or for the rest of the support period if that is longer. For machines and plants that run for ten or twenty years, this becomes a technical question: can the software still be built, tested and delivered in fifteen years? We secure the build environment, toolchain and dependencies so that the answer is yes.

Products must be delivered with a secure default configuration, be resettable to their original state, protect against unauthorized access and offer as little attack surface as possible, including on external interfaces. Older devices typically contain hard-coded default passwords, open debug and service access or services nobody needs anymore. We find such weak points and close them without blocking service and maintenance in the field.

Make a preliminary classification of products – default, important (class I or II) or critical –, define the conformity route and take other applicable regulations into account.

Compare the current and target state, prioritize the biggest gaps and risks, and derive an action plan with owners and a schedule.

Set up processes for vulnerabilities, reporting and updates, adapt the software, embed tools and training.

Structure technical documentation and evidence, establish SBOM generation as an ongoing process.

Prepare the declaration of conformity and supporting documents and file them in an audit-ready way. The conformity assessment itself lies with the manufacturer and, depending on the product class, a notified body.

Monitor vulnerabilities, provide updates, keep to reporting channels, carry out internal audits – so that CRA compliance is not just achieved but sustained.