Smart Street Lighting Cybersecurity: A City Procurement Checklist

A smart streetlight cybersecurity checklist should help a city decide whether a supplier’s answer is usable. “Encrypted,” “secure cloud” and “remote monitoring” are starting points. The review needs to show which components are protected, who can change them and how the city will manage the system after installation.

Begin with a diagram of the proposed deployment: field controllers, gateways if used, communications services, management software, integrations and support access. A strong control at one layer does not answer the questions at another.

Why smart street lighting changes a smart city’s security review

Smart public lighting brings operating responsibilities that continue after commissioning. Compared with traditional street lighting, a smart street lighting system adds network services, accounts and software-controlled functions to lighting infrastructure. Smart cities can use connected lighting systems to organize asset information and operating schedules, but they also inherit dependencies that must be maintained. The Internet of Things (IoT) connects the equipment; it does not determine who may operate it.

Public lighting is part of the physical environment. Street lights and their luminaires still have to meet the approved operating requirements when communications become unreliable. Treat these as cyber-physical systems: a lighting control decision can change field conditions, while a sensor or network fault can affect what central software reports. Public safety requirements therefore belong in the same review as information protection.

For a networked LED street lighting system, new technologies should be assessed against the proposed network and service scope. A wireless mesh and a cellular design have different connectivity boundaries. Ask which equipment participates in wireless networking, who administers it and which services it depends on. A radio frequency expressed in MHz is a technical parameter, not evidence of proper security. Read the proposed CMS architecture before comparing security measures.

Seven cybersecurity questions for connected lighting systems

NISTIR 8259A offers an IoT device-capability baseline. Use it as a reference for the review, then translate the relevant areas into deliverables for this lighting project.

Ask the supplier to identify where a requested capability is unavailable or handled by another party. An explicit gap is easier to evaluate than a broad “yes.”

Authentication and lighting control: what useful evidence looks like

Illustrative review example: the city asks how a support engineer obtains remote access. This is a sample evaluation, not a description of LEOTEK’s security architecture.

A response saying “support uses secure access” does not establish the account owner, privileges or expiry. A reviewable response identifies the individual-account policy, available authentication method, approval authority, access scope, logging and removal process. It also points to the applicable configuration instructions.

The follow-up can then be concrete: “Show us how an approved account is removed, and which record demonstrates that removal.” That tests the operating process as well as the feature description.

Keep lighting operations in the room

IT may own account policy, while lighting operations owns field response and maintenance windows. Procurement owns the deliverables. The supplier may operate some services; the city or utility may operate others. Write those responsibilities beside the diagram.

Consider an update that requires a device restart. Security needs to know the release is authentic. Operations needs to know the expected field behavior and recovery path. Both questions belong in the same change review. NIST SP 800-82 Rev. 3 explains the wider OT context, including reliability and physical-system operating constraints.

Evaluate the evidence in three passes

1. Scope: does the answer cover the equipment and services actually proposed?
2. Evidence: is there a current document, configuration example, sample record or demonstration?
3. Ownership: who maintains the control and responds when it fails?

A practical review sheet can mark an item “documented,” “demonstration pending,” “exception requested” or “not supported.” Decide which exceptions block acceptance before comparing bids. A total score should never hide a missing mandatory control.

Cyber security governance and the handover package

Retain the approved architecture, inventory fields, account roles, support contacts, update process, log-access instructions and support-lifecycle statement. Identify who will update each record when the deployment changes. That package is what the next operations team will use after the original project staff have moved on.

Denial of service, unauthorized control and confidential data

A threat review should distinguish three outcomes. Denial of service disrupts availability; unauthorized control changes something outside an approved user’s authority; exposure of confidential records affects information protection. One incident can involve more than one outcome, but the evidence and recovery actions differ. Distributed denial of service involves multiple traffic sources. DDoS attacks against an upstream service need not mean a field controller has been compromised.

The Department of Energy lighting cybersecurity brief (May 2018) discusses denial-of-service and interception concerns in connected lighting. It is general facilities guidance, not a finding about LEOTEK streetlights. Apply the question to the supplied system: what happens to local schedules, alarms and operator access when a dependency is unavailable?

For a procurement exercise, model denial of service or unauthorized control as separate scenarios with approved test conditions. Ask how service interruption is detected, who receives notice and how current field state is reconciled after recovery. Review collected data separately: asset locations, account records and maintenance details can have different access and retention requirements. Do not infer that a real-time dashboard is a security monitoring service.

DOE also published a connected-lighting threat-profile resource. Use such research to organize potential threats to system security. It does not establish that every identified threat occurs in the proposed architecture or that a particular countermeasure is implemented.

Network and system security across trust boundaries

Consider an illustrative command that changes a district’s approved dimming schedule. The request begins with a person or an integration, passes through the management service, and reaches field equipment through the supported communications path. Asking whether the radio link is encrypted addresses only part of that journey. The review also needs to establish who was authorized to request the change and whether the receiving equipment accepted the intended configuration.

Draw the command path and mark where responsibility changes: city account, supplier service, communications provider, gateway where used, and controller. At each boundary, identify the principal being authenticated, the action being authorized and the record available afterward. This is a proposed threat-review exercise, not a claim that every lighting architecture uses those components or that a particular LEOTEK product implements a specific security feature.

NISTIR 8259A distinguishes device identification, configuration, data protection, interface access, software update and cybersecurity-state awareness in its core baseline. For procurement, translate the relevant capabilities into an inspectable demonstration. A long checklist with no system boundary can leave a critical support account outside the review while repeatedly checking the same device feature.

NIST illustrates how levels, tiers and DMZ segments can organize a network-security review. For the proposed schedule change, identify the permitted path and the enforcement point at each boundary. Then request evidence that an unauthorized account cannot use the same path, together with the records an operator would inspect after a rejected command.

The drawing supplies an architecture reference, not proof that a vendor has implemented or tested those controls. Keep that implementation evidence in the project handover.

A plausible misuse scenario is more useful than a blanket promise

Suppose a contractor’s account should have been removed after the service period ended. In this hypothetical review, the account remains active and can change schedules across more assets than its former assignment required. Encryption may work correctly throughout the transaction. The weakness being tested is account lifecycle and authorization, not necessarily the cryptographic protection of the connection.

Have the supplier demonstrate a permitted action, an action outside the test user’s role, and the withdrawal of that user’s access. Keep the asset scope and account role explicit. The project team should agree on a safe test environment and approved conditions; operational lighting should not be disrupted merely to make a procurement demonstration dramatic. NIST’s OT security guide supplies broader OT context for preserving physical-system operations during security work.

The evidence should connect an action to an identity, time, affected assets and result. A lighting alarm is not automatically a security audit record. Conversely, an audit entry stating that a command was accepted is not field verification that the intended light output occurred. Treat those as separate observations and correlate them where the system supports it.

Security has recurring operational costs

Initial feature review is only one part of ownership. Credential renewal, account review, security notices, supported updates, log retention and incident escalation all need responsible organizations. A procurement package that buys a secure configuration without funding its upkeep leaves an important planning gap. The operating model should explain what the city must do and what is included in the supplier’s service.

An illustrative cost comparison can expose the issue. One offer includes a recurring service for managing supported updates; another requires city staff to coordinate them. Comparing only hardware price ignores the work allocation. Record the assumed staff time, support period and exclusions for each offer before calling either more economical. These are planning inputs, not a recommendation for a particular commercial arrangement.

Ask what happens when normal support is unavailable

The most revealing handover exercise may be an exception: an administrator is unavailable, a supplier service is unreachable, or an urgent change occurs outside normal hours. The team should know who can approve intervention, what records remain accessible and how to verify the field state afterward. The answer must fit the actual architecture and service agreement.

Keep a current inventory of components and support responsibilities with the continuity plan. When the system expands to another district or integration, revisit the boundary diagram rather than assuming the original review covers the change. The lasting procurement deliverable is a system the owner can operate and govern over time, supported by evidence for its actual configuration. Citing a NIST document is a reference for that discussion, not certification that a product or deployment is secure.

Define what a restricted account can actually do

An account labeled read only still needs a precise scope. Can it see every location, export the fleet inventory or retrieve detailed operational history? Can it acknowledge alarms even if it cannot change a lighting schedule? A role name is a convenient label, but the permitted actions determine its operational and information exposure. Ask for a role-to-action matrix that the city can test with representative accounts.

For an illustrative acceptance exercise, give a contractor access to one assigned district. Verify that the account can perform the agreed task there and cannot issue a command or retrieve restricted information for another district. Include the application interface and any supported programmatic route in the agreed test scope. Do not infer that hiding a button establishes an access boundary. This proposed exercise turns the capability questions in NISTIR 8259A into observable procurement evidence; it is not a product certification.

Separate ordinary work from emergency authority. A broadly privileged account may be needed for a controlled recovery action, but it should have an owner and a documented use process. Otherwise an exceptional arrangement can become the everyday maintenance route. Ask how emergency access is granted, reviewed and withdrawn, and how the city will recognize its use after the original commissioning team has left.

A security event needs an operational interpretation

A failed login and an unexpected lighting schedule change should not disappear into one undifferentiated alarm total. The first may concern attempted access; the second may require immediate operational investigation. Decide which records the city receives, which party reviews them and how a security finding reaches the lighting team. More stored logs do not necessarily produce a faster response when nobody owns the decision.

Consider an illustrative report that several controllers accepted changes outside the planned maintenance window. The response needs the affected asset identifiers, time basis, initiating account and requested action. It also needs the current lighting state. Those records help the teams distinguish an authorized emergency action, an operator error and a suspected misuse. They do not establish the cause automatically. Retain uncertainty until the evidence supports a finding.

NIST’s OT security guide provides the OT context for keeping security decisions connected to operational requirements. A procurement discussion should therefore cover both who investigates the event and who can restore an acceptable lighting condition. An IT service ticket that is technically resolved while an operational exception remains open is an incomplete handover between teams.

Make the security promise survive the contract handover

Ask who receives vulnerability notices, who determines whether the installed configuration is affected and who authorizes a mitigation. A generic assurance that updates are available leaves those responsibilities unresolved. The city also needs the supported product versions and the process for identifying equipment that cannot receive a proposed change. Otherwise unsupported units can remain hidden inside a fleet-wide completion percentage.

Put those responsibilities into the service handover alongside the asset inventory and operating procedures. Review them when the contractor, platform or city contact changes. A useful cybersecurity checklist ends with named owners and evidence the city can retrieve. That makes the security capability maintainable over the system’s service period, rather than an impressive answer that only the original bidder knows how to demonstrate.

Cybersecurity questions from city teams

Use the companion guides on device identity and firmware rollout for a deeper review. Send LEOTEK your proposed architecture and evidence checklist to frame the technical discussion.

Conclusion: make evidence and ownership part of procurement

A connected lighting initiative should end with a lighting system the owner can operate, maintain and govern. Before a city decides to adopt connected technologies, agree on the system boundary, mandatory evidence and acceptance exceptions. Revisit that record when equipment, access, services or integrations change. The prospect of a useful new function is a reason to evaluate its dependencies as carefully as its benefits.

Discuss the proposed LEOLink and RenAI configuration

Review LEOLink system options and RenAI management functions alongside your procurement requirements. Send LEOTEK your architecture, operating scope and evidence request so the technical discussion addresses the actual equipment and service.

Further reading and technical sources

Additional research and calculation basis

• NISTIR 8259A (May 2020), IoT device cybersecurity capability core baseline
• NIST SP 800-82 Revision 3 (September 2023), OT security guidance