Hardening and access
The access boundaries of a local-first site, why the local management path must not be exposed to the internet, and how roles, credentials and updates are handled.
| Document revision | r0.1-draft |
|---|---|
| Status | draft |
| Applies to | LS-GW-100, LS-GW-300, LS-WS-1G, LS-WS-2G, LS-RC-16A, LS-DIN-4CH |
| Regions | global |
| Published | Oct 15, 2026 |
| Review due | Apr 15, 2027 |
| Author | Engineering documentation (owner unassigned) |
| Reviewer | Engineering sign-off pending (reviewer unassigned) |
A local-first site is easier to keep closed, because the devices do not need inbound access from the internet to work. The security position therefore rests on a small number of boundaries rather than on a large number of controls. This document states those boundaries and how access is administered; it does not publish credentials, key lengths or algorithm names, which belong to the release they ship with.
The access boundaries
The local management path stays local
The gateway's local interface is for commissioning and local operation. It is reached from inside the site's own network, and the site's uplink is outbound only. Putting the local interface on the internet is the single change that breaks the security model this system is designed around.
The cloud layer is optional and minimal by design
Where cloud management is enabled it is management-only: it receives what the site chooses to send and does not require inbound access to operate control. Disabling it must leave the site fully functional, which is the same property Failover and local policy proves.
Roles are per person, not per device
Administration is assigned to named people through roles, not shared as a single site password. Removing a person's access must not require re-provisioning the site. This keeps an audit trail meaningful: an action can be attributed, and therefore reviewed.
Administration
Provisioning
Credentials are provisioned per site during commissioning and are never shipped in documentation or in a default that survives first boot. Change any pre-installation credential before the site is left unattended.
Credential handling
Store credentials in the installer's own management system, not in the site's rule configuration. A credential copied into a rule or an endpoint label travels with the configuration backup; it should not.
Updates as a security control
Applying firmware revisions is a security action, not only a maintenance one. The update procedure and its revision check are in Firmware update; an unapplied revision is a known, unpatched behaviour.
Least privilege for the field protocols
A building system reading the site's data does not need to command it. Grant a field-protocol consumer read access for the points it needs and nothing more; the alternative — a broad write mapping — is how a monitoring integration acquires the ability to switch real loads.
Failure modes
- Local interface reachable from the internet: the security model is void; remove the inbound route and reach the site through its own management path.
- Shared site password: individual action cannot be attributed; assign roles instead.
- Credential embedded in configuration: it propagates with backups; keep credentials outside rules and labels.
- Field-protocol consumer with write access it does not use: reduce the mapping to the points actually required.
Placeholder — pending engineering sign-off: the credential-provisioning scheme, the role names, the session and timeout policy and the minimum TLS version for any protected transport are not published yet and are set with the release.
Limitations
- No algorithm, key length, credential format or default account appears on this page. Where such a value is needed it is published with the firmware revision it belongs to.
- This page describes the site's access boundaries; it does not describe physical security, which is a property of the enclosure and the plant room, not of the firmware.
What this document does not cover: how a vulnerability is reported and handled is stated on the security disclosure page, and the interfaces this policy protects are in API and webhooks.