The first in a series: On the record — my road to the Cyber Resilience Act.

Every light switch, thermostat and door controller in a modern hotel is now a computer on a network. For most of my career, the security of those computers came down to goodwill. A supplier said it was secure, and you took their word for it.

That is changing. This month 2N, whose intercoms we integrate with, led its newsletter with “Cybersecurity starts with secure design.” When the people who make the doors and the people who make the controls say the same thing, buyers are right to expect more than a promise. They should expect evidence.

What the Cyber Resilience Act asks

The EU’s Cyber Resilience Act, Regulation (EU) 2024/2847, sets security rules for products with digital elements sold in Europe. That covers hardware and software alike, which means the control systems, drivers and software we build at LCD and Centro. In plain words, it asks manufacturers to:

• make products secure by default, with no shared default passwords and with data protected;
• know every component inside the product, and not ship known vulnerabilities;
• give people a clear way to report security flaws, and handle the reports properly;
• tell the authorities within 24 hours when a flaw is being actively exploited;
• keep products patched for a declared support period, normally at least five years.

Two dates matter. The reporting duties have applied since 11 September 2026. Everything else applies from 11 December 2027.

Why I started now

I could have waited for 2027. I chose not to, for three reasons.

Our customers are already asking. Hotel groups send every supplier a security questionnaire. The Act gives those questions a legal backbone, and I’d rather answer them with evidence than with adjectives.

Our installers share the duty. Under the Act, the distributors and importers who sell a product have duties of their own. If we aren’t ready, the integrators who trust us aren’t ready either.

Security added at the end is weak security. The habits the Act asks for work best when they’re part of how a team builds every day, not a project before a deadline.

What I found when I looked

I started the self-assessment in March and have kept it going ever since. I went through the regulation, requirement by requirement, against the Centro Box, the product we install on Crestron processors. For each requirement I wrote down the evidence. Where there was none, I wrote that down too.

The real answer was: not ready yet.

The product itself was in decent shape. It runs on site and works without the cloud. It uses HTTPS by default, and there’s no shared default password. The gaps were mostly in process:

• We had no full list of the software components inside each release.
• Our Centro websites and code had no published security contact.
• We had no written procedure for reporting an exploited flaw to the authorities.
• We had no formal risk assessment and no declared support period.

Then I followed the trail into our Crestron Home and device drivers. The shared libraries they’re built on had grown far beyond what the drivers actually use, and every extra component is one more thing to track and patch.

What we’ve done since

Every gap became a task for us to progress:

• Every part of a Centro Box release now has a software bill of materials (SBOM). That covers the engine, the staff app, the guest web app and the Crestron Home driver.
• Our builds now refuse to ship a component with a known High or Critical vulnerability. The first runs found real issues, including one in the embedded database engine, and we fixed them.
• There’s a security contact everywhere: [email protected], our disclosure policy, and a security.txt file on each website.
• We tightened up even more. Stored passwords are encrypted, key files are locked down, and the admin pages send browser security headers.
• We declared a support period. Every Centro Solution gets security updates for five years from purchase.
• The driver libraries are slimmer. The core library has shed components our drivers never used, and an old third-party library with a known weakness has gone. There’s more to do, and I’ll show it in the next article.

The same habits apply to the custom software we write for individual clients. Its source is checked automatically for outdated components, credentials live in a password store instead of in scripts, and we attack-test our own work in-house. I’ll come back to that in January.

Where we stand today

We’ve made significant progress, but there’s still work to do. The formal risk assessment is still being written, our written procedure for reporting an exploited flaw is still being finalised, and we still need to complete the Act’s conformity assessment, so I won’t call Centro “compliant”. What I can say is that we’re designing our products to meet the Act, and to go beyond it, and that you can check our progress. That’s the point of this series.

What comes next

Every couple of weeks I’ll take one part in turn:

1. how we know what’s inside every release;
2. how the Centro System Manager protects a building from the first minute;
3. what happens when someone reports a flaw;
4. what all of this means for installers, and for custom software.

I’ll use dates and specifics, and I’ll say where we’re still working.

One thing you can do today: if you look after IT or security for a hotel group, ask your controls suppliers the question I asked myself: “Show me the evidence.” Our answers are on our security page: centro.network/en/security.

Neil Silver, LCD and Centro

• Category: Opinion
• Tag: security