What protects the installation, layer by layer.
Lighting is critical infrastructure with thousands of devices in public space, so security questions deserve specifics rather than adjectives. Below is what is implemented on the device, on the radio, on the way out of the site and in the platform.
Edge controller in a cabinet — installed site
Four places where something has to be protected.
The device on the pole, the radio between devices, the gateway that leaves the site, and the platform that stores it all.
Keys in hardware, firmware that is checked
Encrypted, and closed to strangers
One tunnel, few doors
Who can see what, and where it lives
A system that works offline is a smaller target.
Most of the damage an attacker could do to a lighting network depends on the network being the only place where decisions are taken. In iLCS they are taken at the edge, so the platform is where you watch and configure — not where the street gets its instructions minute by minute.
The same design decision that keeps a city lit through an internet outage also reduces what a compromised connection is worth.
Cabinet doors are monitored and every opening is time-stamped in the history — the same mechanism that catches copper theft catches an unexpected visit.
Remote commands can be locked out on site. Someone working in a cabinet cannot be overridden from a screen elsewhere.
The connection is opened from the field outwards. There is no port to expose and no address to reach the installation on, which removes the most common way into a remote system.
We use the accurate words — and the strongest practical protection.
Security marketing in this market runs on two or three phrases that sound strong and mean little. We prefer to name the algorithm, the key length and where the key is kept, because that is what a technical review can verify.
Protected on every leg, with keys in hardware
The radio frame, the tunnel out of the site, the transport and the storage are each encrypted and authenticated, with the keys held in a secure element on the device and in a TPM on the controller. In a mesh where every node relays traffic and takes decisions locally, this is the architecture that actually protects the installation — a single opaque tunnel from device to cloud would remove exactly the local intelligence that keeps the street working offline.
"Military grade" means nothing. This is what we use
AES on the radio with keys generated and kept in hardware, a dedicated crypto chip on every node, TPM 2.x on the cabinet controller, signed firmware, certificate-authenticated VPN, TLS on every service, encryption at rest. The strongest protection available at each layer, named layer by layer.
Documents, not adjectives
Device conformity is backed by test reports from an independent laboratory — radio, electromagnetic compatibility, RF exposure and electrical safety — and we hand those over, not only our declaration. Everything else on this page is described precisely enough that your own technical review can check it.
Send us your security questionnaire and we will answer it line by line, with the specifics — which algorithm, which key length, where the key is kept and who can reach what.
Send the questionnaire →Device conformity, on request.
Radio, EMC and electrical safety test reports for the field devices — EN 300 328, EN 301 489, EN 55032/55035, EN 62368-1 and the rest of the package — with the declarations of conformity.