Cyber Resilience Act

What the CRA requires

The Cyber Resilience Act applies from December 2027. Among other things it requires manufacturers to provide:

• a software bill of materials covering the components included,
• secure updates across a committed support period,
• a route for reporting vulnerabilities,
• notification to CSIRT and ENISA within 24 hours.

A manufacturer cloud expressly falls under it. Connecting your devices brings the cloud into scope, whether it is your own or a service provider’s.

Who stays responsible

We say this plainly before talking about contributions: the CRA obligations lie with the manufacturer of the product. With you. The conformity assessment, the declaration, the bill of materials for your own firmware and the support period you commit to remain yours. No platform takes that off you, and anyone promising otherwise has not read the CRA.

What a platform does influence is something else: how often you have to meet these obligations and whether you have the means to.

How often is the real question

Take a manufacturer with four controller families whose connectivity runs through four different vendor clouds.

From December 2027 each of those chains needs an answer to the same questions. Which software versions are in the field? How long will this cloud be supported? Who reports within 24 hours if a vulnerability appears there, and to whom? How does a security update reach the devices hanging off it?

Four chains means four answers, four schedules, four other companies to ask and none of them yours to decide.

One platform means one answer.

What HVACloud contributes

You know what is in the field. A device is provisioned at the factory and is known in your instance from then on. The question “which devices are affected by this vulnerability” becomes a query rather than an investigation. Factory and field commissioning

You can reach the field. Over the air updates go from the cloud to the panels, approved group by group. A security update becomes an approval rather than a drive out. Without such a route, a committed support period is a promise without the means to keep it. Operations and administration

Devices that cannot do it themselves. A controller with no way out of its own cannot be updated, and that is exactly what the CRA hangs on: without a route for updates, no support period can be held. Whatever hangs off a panel or a GWPro and accepts an update over its interface is served through it. We provide the route, the firmware and its conformity stay with you. Operations and administration

Access is narrow. Only approved hardware connects, against documented criteria, and you decide inside your tenant which hardware that is. Remote access to a device is granted per device, it is time limited and it is logged, and that log is audited. Hardware

Operation is certified. sinnograte is certified to ISO 27001, for development and for operation. That does not replace your conformity assessment, but it is the evidence for the part of the chain that sits with us. Trust center

The reporting route exists. There is a way to report vulnerabilities in the platform, with a committed response time. Trust center

How this connects to the German subsidy

The German subsidy requirements and the CRA are two independent bodies of rules with different deadlines. They lead to the same decision.

Both require something above the controller that holds for the whole fleet and that you control yourself. Whoever solves one requirement in four places will solve the other in four places too.

Staying eligible for subsidies in Germany

What we do not claim

We do not interpret the CRA for you, and we do not declare your device conformant. That is the job of your type approval and, where required, a notified body.

What we can show is the chain: which devices are known, how an update gets to them, how long we support what, and what we report when in an incident. Ask for it and we will go through it with your IT.

Arrange a conversation