Cybersecurity for Sensors and Controllers: A Pre-Connection Checklist

The short answer

Before a sensor or controller joins a shared city network, an attacker can often compromise it through a default password, an unpatched firmware flaw, or an over-permitted network path. This checklist walks through what to verify first: asset classification, vendor commitments, hardened identity and interfaces, network segmentation, logging, and formal change control. Completing it reduces the chance that a single field device becomes an entry point into the municipal systems that depend on it.

Key takeaways

Treat every sensor or controller as a potential entry point into the wider network, not as a passive instrument.
Document each device—make, firmware, function, owner, and intended segment—before it is allowed on the network.
Use procurement to set security requirements in writing, including unique credentials, patching, and vulnerability handling.
Isolate field devices in an OT segment with deny-by-default firewall rules; never place them directly on a general or internet-facing network.
Enable event logging, encryption, and change-control approval before the first packet is sent.
Controllers that can actuate physical processes need stricter controls than read-only sensors.

Know the device and where it sits

Pre-connection security starts with an honest inventory, because most compromises of field devices exploit forgotten or undocumented assets. Before any new sensor or controller is allowed to reach a shared city network, record its make and model, exact firmware version, function, owner, physical location, and the network segment it will join. A device that cannot be confidently identified should not be connected.

The most important classification is the device's effect on the physical world. A sensor that only reports temperature or pressure can be spoofed to feed false data into decisions, while a controller that opens a valve, switches power, or adjusts settings can directly change physical state. In the language used by NIST and IEC 62443, controllers that act on the process carry a higher risk profile and should sit in a more protected zone with stricter access and integrity requirements.

Ask the vendor the right questions before purchase

Much of a device's security is determined before it is purchased. Regulators and technical bodies now explicitly ask operators to buy products that are secure by design: before a controller joins a city network, its vendor should be able to show unique per-device credentials, a supported path for firmware updates, and a responsible process for receiving vulnerability reports. Ask for these commitments in writing and put them into the contract or service level agreement rather than relying on sales conversations.

Treat the questions as a filter. If a vendor cannot confirm that the product supports authentication, encryption, and event logging, or if it is near end-of-life with no patch commitment, the cheaper device will usually cost more in compensating controls later. For municipal buyers this is also a supply-chain step: verify who maintains the component, whether third-party software is tracked, and what happens when the product line is discontinued.

Harden identity, credentials, and management interfaces

The most common way attackers reach field devices is through default or shared credentials and open management interfaces. Before connection, change every default password to a unique secret, disable blank and shared accounts, and, where the device supports it, issue device certificates and require multi-factor authentication for interactive access. These steps map to the identification, authentication, and use-control requirements of standards such as IEC 62443-4-2.

Management surfaces are often broader than they look. Disable unused ports, radio and USB debug interfaces, and legacy protocols that cannot authenticate. Restrict who can reach the device's web interface or maintenance console to a small set of authorized hosts on a dedicated management path, rather than leaving administration open to the whole city network.

Segment the network and control data flow

Even a well-hardened device is a risk if it shares a flat network with everything else. Field sensors and controllers should sit in a dedicated operational segment, separated from general office networks and, above all, from the public internet, by firewalls whose default rule is to deny. This follows the zones-and-conduits model described in IEC 62443 and the network architecture guidance in NIST SP 800-82.

Define exactly what the device must reach—its gateway, historian, or server—and allow only those flows in each direction. Resist outbound call-home traffic except where it is part of a controlled management or update channel. Where a legacy device cannot encrypt its traffic, keep it inside a tightly constrained segment and mediate that traffic through an application- or protocol-aware gateway, never exposing it directly to the internet.

Enable encryption and logging before the first packet

Enable encryption for every channel the device will use before it sends its first packet. Transport-layer security (TLS), IPsec, or an equivalent protects credentials and measurement data from being read or replayed on a shared medium. Where the field protocol does not support modern encryption, rely on segmentation and gateway mediation rather than assuming the traffic is private.

Logging must also be arranged in advance. Enable cybersecurity event logging—logins, failures, and configuration or firmware changes—and forward the records to a monitoring system or security operations team. Set alarms for the events that should never occur, such as the use of an emergency or break-glass account, so that abnormal activity on a single street-level device is not silently missed.

Gate the connection with change control and a test

The connection itself should be a controlled change, not an administrative shortcut. Before going live, complete or update a risk assessment for the segment, document the intended traffic flows, obtain a formal approval, and define a rollback plan in case the device behaves unexpectedly after connection.

After the first packets flow, verify the new baseline: only expected connections appear in logs, alarms trigger correctly, and the device still accepts updates through the agreed channel. Name a clear owner for ongoing patching and lifecycle review, because a checklist that ends at commissioning leaves the device unmanaged for the rest of its life.

Put it into practice

Pre-Connection Security Checklist (Print-and-Verify)

Print this list and check every line before the device is allowed onto the shared city network. A line is only complete when there is evidence—a log entry, a document, or a signature from the responsible owner. Where an item cannot be met, record the compensating control and who owns it.

Asset record complete: type, make/model, firmware, function (sensor vs controller), owner, physical site, and target segment documented.
Vendor confirmed in writing: unique device credentials, a supported secure update path, and a named security or vulnerability contact.
Default credentials changed to unique strong secrets; blank and shared accounts removed.
Management interfaces restricted to authorized hosts; unused ports, services, and debug protocols disabled.
Latest verified firmware installed; the update mechanism and its source are checked.
Device placed in the correct OT segment, not on the general or internet-facing network.
Firewall and conduit rules in place with deny-by-default allow lists for required traffic only.
Communication encryption (TLS, IPsec, or equivalent) enabled for all traffic to gateways and servers.
Cybersecurity event logging enabled and forwarded to monitoring; relevant alarms defined.
Risk assessment and change-control approval signed before connection.
Rollback and incident-response steps defined in case the device misbehaves.
Post-connection baseline verified: only expected traffic present, and an owner named for ongoing patching.

Questions people ask

Why should a read-only sensor still be protected?

A read-only sensor is still a trusted source of data that operators and automation act on, and it still sits inside the network. An attacker can spoof the sensor to report false readings—say, a lower temperature or pressure—which distorts the decisions made from that data. The same device can also be used as a foothold to probe other systems or as an entry point into the network. So even a measuring-only device needs at least unique identification, changed default credentials, an encrypted channel, and monitoring, even though it cannot change physical state.

What is the difference between a simple VLAN and the zones-and-conduits model?

A VLAN splits a network logically but does not by itself decide who may talk to whom; misconfiguration or routing errors can allow traffic to bypass it. The zones-and-conduits model described in IEC 62443 adds policy on top of segmentation: a zone is a set of assets with the same security requirements, and a conduit is a controlled point where traffic crosses between zones under explicit rules. In practice this means not just VLAN separation but firewalls with allow lists, least-privilege flows, and separate management paths rather than relying on a single network tag.

How do I secure a device that only speaks a legacy protocol with no encryption?

If the protocol has no built-in authentication or encryption—common with older Modbus, Profibus, and similar field buses—do not expose the device directly to a shared or internet-facing network. Keep it in an isolated segment with as few peers as possible, restrict access with strict firewall rules, and pass traffic through a gateway that understands the protocol and can validate commands and addresses. Encrypt traffic from that gateway toward modern servers and monitoring systems. Treat this as a compensating control: the device itself remains spoofable, so also enable logging and alarms for anomalies.

What should I do if the vendor no longer patches the device?

A device without update support cannot be considered secure indefinitely. If you cannot replace it immediately, introduce compensating controls: place it in a separate, tightly restricted segment with no internet egress, minimize its network peers, add encryption at the gateway, and enable stricter logging with alarms for abnormal activity. Record this as a time-limited risk in the risk assessment, name an owner, and schedule replacement before support ends. The longer an unsupported device stays online, the more important it is to limit its access and watch its traffic.

Which security questions should I ask a vendor before buying a controller?

Beyond price and features, ask whether the product supports unique credentials per device, certificates, and multi-factor authentication; a signed, secure firmware-update mechanism; encryption of channels; and cybersecurity event logging. Find out who receives vulnerability reports, the stated support duration, and what happens when the product is discontinued. Ask for written confirmation and put the requirements into the contract. These answers determine how much effort and cost you will face protecting the device after it is connected.

Does this checklist apply to installing just a single sensor?

Yes, the principles scale down but should not disappear. Even one sensor should be recorded in the asset inventory, have its default password changed, use an encrypted channel, be restricted by firewall rules, and generate events for monitoring. For a small deployment you can simplify the process—for example, using a standard template instead of a full risk assessment—but do not skip identification, credential changes, and segmentation. A single device connected quickly can still become the weakest link for the whole network.

Sources and further reading

Sources were checked when this page was generated. Confirm changing dates, rules and prices with the original publisher.

U.S., U.K., Australia, Canada and New Zealand Release Cybersecurity Best Practices for Smart CitiesCISA
Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital ProductsCISA
CISA, UK NCSC, FBI Unveil Principles to Combat Cyber Risks in OTCISA
NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) SecurityNational Institute of Standards and Technology (NIST)
NISTIR 8259 SeriesNational Institute of Standards and Technology (NIST)
IEC 62443-4-2:2019, Security for industrial automation and control systems – Part 4-2International Electrotechnical Commission (IEC)