IoT Security for Councils and Utilities

Australian councils and utilities now run thousands of connected devices that never existed a decade ago — smart water meters, traffic and pedestrian sensors, environmental monitors, smart streetlights, connected CCTV and building management controllers. Each delivers genuine operational value. Each also expands the attack surface, often without IT ever being consulted. The result is a sprawl of devices that are hard to see, harder to patch and rarely designed with security in mind.

The good news is that securing this estate does not require ripping it out. It requires visibility, sensible network design and disciplined procurement — applied consistently and owned by someone accountable.

Why IoT is a different security problem

Traditional IT security assumes you can install an agent, push a patch and enforce policy centrally. IoT breaks most of those assumptions. These devices are typically embedded systems with constrained memory, long lifecycles measured in years, and firmware that the vendor — not you — controls. Many ship with hardcoded or default credentials, expose unauthenticated management interfaces, and run network services you cannot disable.

Three characteristics make the council and utility context especially difficult:

• Physical exposure. Field devices sit in pits, on poles and in unstaffed substations. An attacker with physical access can extract credentials, attach to a maintenance port or simply swap a device.
• Shadow procurement. Operational teams buy connected equipment to solve a specific problem — flood monitoring, parking, irrigation — and the device joins the network before security is aware it exists.
• Convergence with critical systems. A compromised sensor on a flat network can be a pivot point toward SCADA, billing or the corporate environment. The device itself may be trivial; what it can reach is not.

There is also a scale problem. A council might run a handful of corporate servers but tens of thousands of sensors and meters. Manual processes that work for servers — individual review, hands-on configuration, per-device patching — simply do not scale to that many endpoints. Security for IoT has to be designed around automation, grouping and policy applied by device class, because no team can manage each unit individually.

Start with discovery you can trust

You cannot protect what you cannot see, and most organisations underestimate their device count by a wide margin. Begin with passive discovery — analysing network traffic and DHCP, ARP and DNS records to identify devices by their behaviour. Avoid aggressive active scanning against operational networks; fragile embedded devices and OT controllers have been known to fault or reboot when probed.

Cross-reference the technical picture against procurement records, vendor support contracts and any existing asset registers. The gaps between those sources are where the risk hides. Build a single register that records, for every device, its function, location, network zone, firmware version, owner, support status and criticality. Treat it as living documentation reviewed on a schedule, not a project that finishes.

Segment first, segment hard

If you do one thing, segment the network. IoT and operational devices should never share a flat network with corporate IT or critical control systems. Place them in dedicated VLANs or security zones, and allow traffic between zones only through controlled conduits — explicit, documented rules that permit the specific flows a device needs and deny everything else.

This is the same logic behind disciplined robot and automation integration, where physical actuators must be isolated from general traffic. Segmentation does not prevent a device being compromised, but it sharply limits what a compromise can reach, turning a potential enterprise-wide incident into a contained one. For councils running both corporate and operational technology, this is the foundation everything else sits on.

Manage credentials, firmware and access

Default credentials remain one of the most reliable ways into IoT estates. Change every default password before a device goes live, store credentials in a managed vault, and disable unused accounts and services. Where a device supports certificate-based authentication, use it.

Firmware is harder. Establish, per device class, who is responsible for updates, how you are notified of security releases, and how updates are tested and applied without disrupting operations. For devices that can no longer receive updates, compensate with tighter segmentation, monitoring and, where justified, a replacement plan. Restrict management access to a defined administrative network or jump host, and never expose device management interfaces to the public internet.

Monitor what the device cannot protect itself

Because most IoT devices cannot run security agents, monitoring shifts to the network. Baseline normal traffic for each device class, then alert on deviations — a sensor suddenly talking to an external IP, a camera initiating outbound connections, unexpected protocol use. Feed device logs, where available, and network telemetry into your central logging so events are correlated rather than lost.

This network-centric monitoring is also your early warning that a device has been physically tampered with or swapped, since the replacement rarely behaves identically to the original.

Where devices support it, pull their logs into the same place. Many will offer little, but even a record of authentication attempts, configuration changes and reboots adds context that turns an ambiguous network alert into an actionable one. The goal is a single picture in which an unusual flow from a water meter and a failed login on its management console are visibly part of the same event, rather than two unrelated lines in two separate systems no one is watching.

Plan for the device lifecycle

IoT devices outlive the assumptions made when they were bought. A smart meter installed today may still be in the field in a decade, long after its firmware stops receiving updates and its protocols are considered weak. Security has to account for the whole lifecycle, not just deployment day.

That means tracking, per device class, when vendor support ends and what happens after. An unsupported but still-functional device is not automatically a crisis, but it must be a conscious decision: either accept the risk with documented compensating controls, tighten its isolation further, or schedule replacement. The failure mode to avoid is the silent one — thousands of end-of-life devices quietly accumulating in the field because no one tracked their support status and no one owned the decision. Decommissioning matters too: a device removed from service should have its network access revoked and its credentials invalidated, not simply unplugged and forgotten while its accounts linger in the management system.

Build security into procurement

The cheapest control is the one you negotiate before purchase. Bake security requirements into procurement and vendor contracts: support for credential changes, a defined firmware update commitment, secure-by-default configuration, logging capability, and clear end-of-life dates. Require vendors to disclose known vulnerabilities and remediation timelines. For councils, aligning these clauses with broader government and council cybersecurity obligations and cyber due diligence on suppliers prevents the next wave of insecure devices entering the estate.

Where the Essential Eight fits

The Essential Eight remains the right baseline for the IT systems that manage IoT and OT fleets — the servers, management consoles and engineering workstations. Apply patching, multi-factor authentication, application control and admin privilege restriction there rigorously. For the embedded devices themselves, where those controls cannot run, lean on segmentation, monitoring and procurement discipline as your compensating layer. The two approaches are complementary, not interchangeable.

Make it someone’s job

The recurring failure in council and utility IoT security is ownership. Devices are bought by one team, networked by another and forgotten by everyone. Assign clear accountability for the IoT estate, integrate it into your risk register, and review it at the same cadence as the rest of your security programme. Many councils and utilities find that a Virtual CISO arrangement provides the senior oversight to drive this without the cost of a full-time hire.

For utilities and councils operating systems that meet the definition of critical infrastructure, this ownership also carries regulatory weight. Obligations under the Security of Critical Infrastructure regime can require a documented risk-management programme covering exactly these assets, and an unmanaged IoT estate is difficult to reconcile with that. Treating connected devices as in-scope from the outset, rather than discovering them during an audit, is far less painful. For councils more broadly, the same discipline supports the expectations set out for local government cybersecurity and the practical guidance in our guide to cybersecurity for Australian councils.

CISO Advisory works with Australian councils, utilities and enterprises to bring connected-device estates under control — from discovery and segmentation through to procurement and ongoing assurance. If you are not confident you can list every connected device on your network, that is the place to start. Call 07 2112 8502 or get in touch via our contact page to talk it through.