Beyond obfuscation: complete security

Many legacy lighting and emergency systems rely on plain text or “security by obscurity”, which can hide details but doesn’t protect networks. zencontrol uses industry-proven TLS 1.2 and 1.3 with strong encryption (including AES-256-GCM) to provide real security: encrypted, authenticated communications with integrity checks, and devices that verify peers before exchanging data.

Encryption & cryptographic standards

Each zencontrol device stores a unique 32-byte key and supports TLS 1.2/1.3 with strong cipher suites. Local device-to-device traffic uses TLS 1.2 with pre-shared keys, while cloud connections use PKI with 4096-bit RSA certificates. Credentials are salted and hashed, and firmware updates are cryptographically signed and delivered over secure channels to prevent unauthorised code on controllers.

zencontrol defaults to AES-256 (not AES-128) for significantly greater brute-force resistance and future headroom, including against quantum search (e.g. Grover’s algorithm reduces effective strength). This aligns with guidance to move away from sub-128-bit security strength and with higher-bar government profiles that require 256-bit AES for sensitive data.

We also avoid weak or deprecated options (e.g. AES-128-CCM where advised against), rapidly patch when vulnerabilities emerge, and run software on supported, regularly updated platforms (not end-of-life systems such as Windows CE/Windows Embedded Compact).

Authentication & user management

Effective security starts with strong authentication. zencontrol cloud requires authorised user accounts (controllers are not exposed anonymously) and enforces strong passwords (12–64 characters with upper/lowercase, numbers and symbols, while blocking common sequences). Accounts lock for one hour after seven failed attempts, passwords are salted and hashed, and MFA is supported to protect accounts even if a password is compromised.

Access is controlled and auditable: tokens are issued per device or API client so they can be revoked individually, permissions are defined via access control lists, and changes are recorded in tamper-evident logs.

To reduce insider risk, site owners manage users and apply least privilege: only a small number of trusted “Owners”, with others added as site or tenancy members and limited to specific systems or locations. Access can be revoked at any time, and owners can remove themselves as long as at least one owner remains.

Security chain of proof & device provisioning

Each control system has a physical QR code that must be scanned in the commissioning app to add it to a site. This creates a chain of proof by recording the controller’s serial number, unique key, and ownership. Once provisioned, a controller can’t be added to another site unless the owner deliberately removes it—preventing unauthorised claiming or re-provisioning. Devices can’t be taken over by simply connecting to the network; they must be provisioned through this verified process.

Resilience without the cloud

zencontrol runs locally, so core building functions operate independently of external networks. Cloud connectivity can be disabled at any time without impacting operation. When cloud services are used (e.g. remote monitoring and analytics), communication is secured with TLS and requires only outbound connections. NTP is used for time synchronisation, and NTP/DNS can be hosted locally so the system can run without an internet connection—delivering cloud convenience without sacrificing local autonomy.

Fine-grained access for multi-tenant buildings
Create site members with tightly controlled permissions and feature visibility. Administrators can grant read/write access only to the required control systems, floors, or device groups—for example, a tenant can manage lighting and blinds only on their leased floor, while facilities has full-site access. Contractors can be given temporary access to a specific control system and removed when complete. Actions can be audited and permissions revoked at any time via the cloud portal.

Legacy systems & insurance risk

Older lighting controllers built on end-of-life platforms create real exposure. For example, Windows Embedded Compact (Windows CE) is no longer supported (mainstream support ended in 2018 and extended support ended in October 2023), meaning no security patches for newly discovered vulnerabilities—an unnecessary risk that can also complicate compliance and cyber-insurance requirements. Weak cryptography can add further risk; some cipher modes (such as AES-128-CCM in certain implementations) have been associated with unencrypted data transfer and are discouraged.

zencontrol avoids these pitfalls: the software stack is actively maintained on supported platforms, services are hardened, and updates are cryptographically signed and delivered quickly. The result is a system designed to remain secure throughout its service life, reducing regulatory exposure and giving insurers confidence in the security posture.

Comprehensive logging & monitoring

Security goes beyond encryption. zencontrol logs configuration changes, firmware updates, and user actions, with audit logs stored securely so you can see who changed what and when. Per-device and per-API-client authentication tokens enable targeted revocation if suspicious activity is detected.