CAREL application migration to STone under the Cyber Resilience Act

The greatest value of an existing application is that it already works. We know its logic, the device’s behaviour, the I/O map and how it communicates with the rest of the installation. That is why we start the migration from an analysis of the existing solution, not from a blank project.

You get not only a new version of the application, but also the hardening, tests and documentation you can use in your product’s technical file. This is not ordinary CAREL controller programming — it is migration with hardening and code signing.

Cyber Resilience Act: why it’s worth starting now

The Cyber Resilience Act introduces new security requirements for products with digital elements. For HVAC/R equipment manufacturers this means, among other things, having to address software security, vulnerability management, updates and appropriate product documentation.

11 September 2026

The first obligations begin — reporting of actively exploited vulnerabilities and severe incidents.

End of 2026

Harmonised standards are expected to be published. In the following stages we will be able to align the prepared documentation with the relevant standards.

11 December 2027

Full application of the CRA begins. Products covered by the regulation placed on the EU market will have to meet the CRA requirements.

It’s not worth waiting with the migration until the new application is needed “yesterday”.

Migration from 1tool and c.suite to STone — step by step

We don’t start from zero. We run the migration in three stages, and we base acceptance on how the device behaves, not on how the program was written before.

1. Application analysis

We review the control logic, inputs and outputs, communication and protocols, BMS maps, terminals, web pages, accounts and permissions, and existing documentation. On that basis you get a report, a list of the key issues and a quote for the further work.

2–4 working days. The report stays useful even if you ultimately choose a different migration path.

2. Moving the application to STone

The migration method differs depending on the source platform:

• c.suite → STone — we port the application, reusing its existing logic and program structure.
• 1tool → STone — we recreate the application in STone, preserving its function and behaviour.

This is not a mechanical rewrite of code. The goal is to preserve how the device works, not how the program used to be written. That is why we base acceptance on regression tests and the signal table from the old application.

What you get: a new STone application, regression tests, FAT acceptance and SAT on the first device, and a price set in advance once the analysis is complete.

Typical schedule: c.suite 8–10 weeks, 1tool 12–16 weeks.

3. Application hardening and documentation

Migration to STone is also an opportunity to put the application’s security in order. We introduce measures appropriate to the specific product, among others: no default passwords and a forced credential change, user roles and profiles, lockout after failed login attempts, session timeout, restricted BMS writes, validation of data arriving from the network, a security event log, disabling unused services, reducing the attack surface, and signing the application with the manufacturer’s digital key. We set the scope of hardening based on the actual application and the device architecture.

STone digital signature: your application, your key, your controllers

STone lets you use the mechanism of digital application signing and binding a controller to the manufacturer’s key. In practice this means you can control which program may run on your devices.

• Authorised application. Every release of the application is signed with your key, and the controller checks the signature before accepting the program.
• Protection against unauthorised code. A program without the correct signature is rejected. This also applies to a modified version of your application.
• Fleet control. You can check which controllers are bound to your key and spot a unit that has been wiped or changed state.
• The key stays yours. The signing key is the manufacturer’s property. We help generate it, store it securely and use it in the release process. The contract also sets out a procedure for handing the process over to the manufacturer, should they choose to run it themselves in the future.

SBOM and technical documentation under the CRA

The CRA covers the whole product, so the documentation must also cover its software layer. We prepare documentation about the application, among other things: software architecture, the security measures applied, the update process, signing-key management, application validation, software dependencies, an application-layer SBOM, and the information needed to handle vulnerabilities.

We prepare the SBOM in CycloneDX (ECMA-424) format, together with VEX information where applicable. The application documentation is a contribution to the product’s technical file — it does not replace the whole device’s documentation or the manufacturer’s obligations.

CRA: who is responsible for what — manufacturer, IceLAB, CAREL

The CRA covers the product as a whole. That is why we split responsibility clearly.

• Device manufacturer (you). Yours are, among others, the product risk assessment, the declaration of conformity, the whole product’s documentation, the vulnerability-management process and the required reporting.
• IceLAB. We are responsible for the application layer: migrating the application to STone, hardening, signing the application, the controller-binding mechanism, the key-management process, the application documentation, the SBOM, and tests and validation.
• CAREL. CAREL is responsible for its layer of the product: the controller, operating system, firmware, platform security, system updates and component documentation.

We do not try to replace the controller manufacturer or the device manufacturer. We bring these three layers into one coherent whole.

The limits of application security — worth knowing

Not everything can be solved at the application level. That is why we show clearly what is in our scope and what stays with the CAREL platform or the device manufacturer.

• Modbus and BACnet. If a given communication offers no encryption, we restrict what can be written and control the input data, but we cannot turn an unprotected protocol into encrypted transport.
• Secure boot and firmware. That is the controller platform’s layer and the platform manufacturer’s responsibility.
• Whole-product conformity. We do not issue a “CRA certificate”. We prepare the application layer and documentation that the manufacturer can use in the conformity assessment of their product.

What about pCO5 devices already running?

Migration does not mean an automatic need to replace the entire existing fleet. The CRA relates mainly to products covered by the regulation placed on the market within the relevant period of application. So it is worth separating two questions: devices already working at customers’ sites and new devices you still want to produce and sell. It is for the second group that moving to a new platform can be an important part of preparing the product for the years ahead.

Maintaining the STone application

Migration does not have to end when the program is handed over. We can carry out further maintenance of the application throughout the product’s support period: signing subsequent releases, handling controller binding, application updates, adapting to new CAREL platform versions, updating documentation and support when a vulnerability is found. This way the manufacturer does not have to build the release and update process from scratch each time.

Flat subscription — 36 months minimum.

Service and controller replacement

When a controller is replaced, the technician does not need full access to the key-management process. A new controller can be bound to the right key and then receive an authorised application. The process can be done remotely and leave a trace in the logs. This limits the number of people who need access to the signing key while simplifying device handling in the field.

Optional: passwordless technician authorisation (NFC)

For devices equipped with a suitable NFC mechanism we can also design a mobile-based authorisation model. The technician does not receive a shared password for the whole fleet — instead their app can use a challenge-response mechanism and their own key to confirm their identity. A given person’s access can later be revoked without changing a shared password across all devices. This option is optional and we tailor it to the specific product architecture.

Why IceLAB

• We know STone in practice. We write STone and work with real CAREL applications — not just the platform documentation. We publish about it in the Knowledge Base and solve the platform’s real problems: building .pack packages and build errors.
• We understand refrigeration. We know the equipment these applications control: compressors, valves, refrigeration circuits, installations and BMS communication. That is why we test not just the code — we test the device’s behaviour.
• We combine automation and OT security. A controller application’s security cannot be separated from how the device works in a real installation. We combine STone programming, HVAC/R automation and OT security.
• We build a solution for years. We don’t want the manufacturer to depend on one person holding a password or a copy of the program. We prepare the keys, the release process and the documentation so they can be managed in the years to come as well.