A contractor needs remote access to fix a schedule. The venue shares its administrator password, the job is completed, and the account remains active for years. Nothing dramatic happens at handover, but control of the installation has quietly become harder to explain.
Connected lighting security is largely about preventing this kind of ordinary uncertainty. Who can change a scene? Which device connects to the internet? Can the owner remove a supplier’s access? What happens if the portal is unavailable? These questions belong in procurement, before the system becomes part of everyday venue operation.
What Is the Minimum Practical Security Brief?
Require an asset inventory, named accounts, appropriate access restrictions, protected remote administration, a documented update process and recoverable configuration backups. Agree how the lights operate without the external service. Assign an owner to each control, because an unmaintained security feature is only a checkbox.
A proportionate connected lighting security plan protects availability as well as information. The aim is not to make routine operation difficult. It is to let authorized staff use the lighting while limiting unauthorized changes and providing a tested route back to normal operation.
| Procurement item | Evidence to request | Owner after handover |
|---|---|---|
| Asset inventory | Device, software and network register | Venue facilities and IT teams |
| Access roles | Operator, administrator and temporary service permissions | Venue account administrator |
| Remote support | Approved connection path and access log | IT team and named service provider |
| Updates | Support period, notification and rollback process | Contracted system maintainer |
| Recovery | Offline-operation and restore test | Venue operations team |
Identify What Is Actually Connected
Start with a simple system drawing. Show luminaires, drivers, local buses, gateways, switches, routers, operator devices and external services. Identify where the installation crosses from a local lighting network into the venue network or the public internet.
A DALI or DMX interface on a driver does not, by itself, mean the luminaire is directly internet-connected. The exposure may sit in a gateway, a remote desktop service or a cloud account. Treating every component as identical can waste effort while leaving the real access point poorly controlled.
Record who supplies and manages each connected device. A venue may own the hardware while a contractor owns the cloud tenant or cellular account. Those arrangements need to be explicit, particularly when several suppliers are involved.
Do not stop at a device count. Include model references, software versions, locations, support contacts and the purpose of each connection. The register should let the owner recognize an unexpected device and determine whether an existing one is still supported.
Use a Recognized Baseline Without Claiming Certification
NISTIR 8259A provides a starting point for IoT device capabilities: identification, configuration, data protection, logical access to interfaces, software updates and cybersecurity-state awareness. These categories help structure supplier questions; they are not a certificate that a lighting installation is secure.
For each category, ask what the proposed equipment actually supports. Can settings be restricted? Can unnecessary interfaces be disabled? How are updates authenticated? Can the owner see relevant security events? Record limitations rather than accepting a general statement that the system follows industry practice.
Use the answers to build the project’s connected lighting security requirements. A small sports club may need a simpler implementation than a major venue, but both need clear account ownership and a recoverable operating configuration.
Where a jurisdiction imposes specific legal obligations, obtain a current assessment for that market and product role. Do not turn a general technical checklist into a claim of compliance with every national cybersecurity rule.
Give People Their Own Accounts and Only the Access They Need
Routine operators generally need to start approved scenes, view status and manage permitted bookings. They may not need to change firmware, network settings or device-level parameters. Separate those functions in the permission model.
A shared administrator account makes accountability difficult. Use named users where supported and a documented process for joiners, role changes and departures. The owner should be able to disable a former contractor without losing access to the lighting installation.
CISA recommends multifactor authentication for remote and privileged access. Ask the platform supplier how it is implemented and how recovery works. A second factor is less useful if everyone shares the same recovery route without oversight.
Plan for staff turnover. Keep administrative recovery information in an approved organizational process, not in one person’s private mailbox. Test an ownership transfer during handover so the venue knows it can manage accounts without permanent dependence on the installer.
Make Remote Support Temporary, Visible and Controlled
Remote support can reduce travel and speed up diagnosis. Its value does not justify an undocumented permanent connection. Identify the approved tool, the systems it can reach and the process for enabling and ending a session.
The CISA guide to remote-access software is a useful reference for reviewing these arrangements. Ask suppliers to describe their access method in terms the venue’s IT team can evaluate, rather than calling it simply secure remote maintenance.
For connected lighting security, a service session should have a named purpose and accountable user. Where practical, use time-limited permission and preserve a record of access and changes. Specify who can authorize an urgent session outside normal hours.
Do not expose a controller’s management interface directly to the internet merely for convenience. Have the responsible IT team approve the architecture and any required firewall rules. A cellular router also needs review; it is a separate connection, not an exemption from access management.
Keep the Lighting Network Separate From Unrelated Traffic
A sports venue may have public Wi-Fi, ticketing, offices, cameras and lighting controls. There is usually no operational reason for every device in those systems to reach every other device. Document the communication paths that the lighting system genuinely needs.
CISA’s guidance on common misconfigurations highlights segmentation and access-control weaknesses. For a lighting project, ask IT to implement and test suitable separation rather than relying on a diagram that merely labels one area as a lighting network.
A VLAN name alone does not prove isolation. The relevant rules must govern traffic between segments and access to management interfaces. Verify the intended restrictions without disrupting active venue services.
Keep network requirements in the tender. If the system needs particular outbound destinations, name them and explain why. This helps the owner review future changes and avoids the common handover problem of a contractor requesting broad access because the original requirements were never documented.
Ask Who Maintains Software After Installation
Connected equipment may remain installed longer than a particular application version is supported. Request the support period for gateways, controllers and cloud services, including how the supplier communicates vulnerabilities and end-of-support dates.
Updates need an operational process. Identify who reviews them, when they can be installed and what configuration backup is required. Avoid an arrangement where a change is applied during an occupied event without the venue’s knowledge.
Ask for a recovery method if an update fails or affects compatibility. This may involve a supported rollback, a replacement device or restoration of a known configuration. The exact method depends on the equipment; it should be demonstrated rather than assumed.
A credible connected lighting security proposal describes maintenance responsibilities as carefully as initial features. “Automatic updates” and “no automatic updates” can both create problems when nobody has defined testing, scheduling and support.
Keep Local Operation Available When External Services Fail
Cloud access, internet service and local control are different dependencies. Ask which functions remain available when each is interrupted. A cached schedule, a local wall station and a manual operating process may provide useful continuity if they are included and properly configured.
Do not accept “works offline” without a demonstration. During a planned test, disconnect the external connection and verify the agreed scenes, local permissions and schedule behavior. Confirm what happens when connectivity returns, including whether delayed commands are applied.
Agree a fallback that suits the venue’s operational and safety requirements. Retaining a normal playing scene may be appropriate in one circumstance, while other situations need a different response. This is a project decision, not something a generic article can prescribe.
Emergency lighting and evacuation provisions remain separate design responsibilities. A local control button is not a substitute for required life-safety systems. Record that boundary so an ordinary network-resilience feature is not accidentally described as emergency compliance.
Keep Useful Logs and Recoverable Backups
Record changes that matter: account creation, privileged access, scene edits, schedule overrides and configuration updates. The logs should identify the actor and time, with a retention period appropriate to the venue’s operating needs and applicable obligations.
A backup should include the information required to rebuild operation, not just a screenshot of the dashboard. Ask for controller configuration, address maps, approved scenes and relevant network settings in the formats supported by the equipment.
Store recovery material securely and test it. A file that nobody can restore is not a proven backup. Keep access limited, because configuration exports can contain sensitive connection or account information.
Prepare a short incident procedure. Staff should know whom to contact, how to preserve useful records and how to move to the agreed local operating mode. They should not improvise network changes or bypass electrical safeguards while trying to get a session started.
Define the Security Boundary Around an FL09 Installation
ZC’s FL09 is the luminaire platform in this discussion. Its documented control configurations provide possible interfaces for integration; they do not establish the security features of a third-party gateway, booking service or remote-management platform.
Ask ZC to confirm the supplied driver and control interface. Ask the controls integrator to identify the connected devices and software. Ask the venue’s IT team to approve access and network arrangements. Put those responsibilities in a shared schedule so no important function sits between suppliers.
The FL09 driver installation options may change where serviceable equipment is located. Include physical access to those locations in the review. A lockable cabinet can help manage access, but physical security does not replace account controls or configuration protection.
Do not claim that an FL09 installation is cyber-certified, encrypted end to end or supplied with a managed security service unless the relevant configuration and evidence support that statement. Accurate boundaries make a B2B proposal stronger than broad assurances that cannot be demonstrated.
Write an Exit Plan Before Signing the Subscription
Ask what the owner receives if it changes service provider. The answer should cover account administration, configuration exports, asset records and any licenses needed for local operation. Do not assume that ownership of luminaires means ownership of every software dependency.
Identify functions that stop when a subscription ends and those that remain available. Remote reports, booking integration and local scene recall may have different commercial conditions. Put those differences in the agreement so the facilities team can plan around them.
Review how supplier access is removed. Ending a contract should trigger a check of named accounts, remote tools, service credentials and external connections. The venue should retain an approved recovery route after those changes, rather than removing the only administrator and creating a new operational problem.
Keep a list of support dependencies that cannot easily be replaced. A proprietary configuration tool may be acceptable when the support arrangement is clear and durable. The risk is not the label proprietary; it is discovering an essential dependency only after support has become unavailable.
This exit review is also useful for ordinary staff changes. It turns control of the installation into an organizational responsibility instead of a relationship with one individual.
Finish With an Owner-Controlled Handover
Before acceptance, demonstrate account transfer, removal of temporary installer access, configuration recovery and operation without the external service. Confirm that the owner has the support contacts and a current asset register.
Test the process with someone who did not build the system. Can that person identify the responsible supplier, request approved support and locate the recovery instructions? This reveals whether the handover works as an operating procedure rather than only as a document archive.
The lasting measure of connected lighting security is whether the venue retains understandable control over its own installation. Security should remain manageable after a contractor changes, a subscription ends or a gateway needs replacement.
Frequently Asked Questions
Does a DALI or DMX driver need an internet connection?
Not simply because it supports that interface. Internet connectivity usually involves additional system components. Identify the actual gateways and remote services in the proposed architecture before assessing access risks.
Is a VPN enough to secure lighting controls?
No single tool covers the whole system. Access permissions, device maintenance, configuration, logging and recovery still matter. The responsible IT team should approve the complete remote-access arrangement and verify its restrictions.
Should a small club avoid connected lighting?
Not necessarily. Connected controls can support useful operating functions, but the club should choose a manageable scope with clear ownership, limited access and local fallback. Complexity without a support plan is the concern, not connectivity by itself.
What should happen when the service contract ends?
The agreement should define account ownership, data export, local operation, support and removal of supplier access. Confirm those conditions before purchase so the venue does not discover its dependencies only when renewal is due.