Safeguard
Research•

What are the security risks of smart cities built on 5G and IoT?

Smart cities link many cheap devices over 5G, so one weak sensor can become a way in. See the main risks and the NIST device baseline cities can require.

Safeguard Security Team
4 min read

The main risk in a smart city is scale and mixed ownership: thousands of low-cost sensors, cameras and controllers, bought from many suppliers, all connected over networks that several parties run. A weakness in one device class becomes a city-wide issue, so baseline device requirements and clear ownership matter most.

Why is a smart city different from a company network?

A company can usually say who owns a laptop. A city has traffic signals, water meters, parking sensors and streetlights installed over many years, paid for by different budgets, and maintained by different contractors. Some will stay in the field for a decade.

5G adds fast mobile connectivity and supports far more devices per area, which is useful for exactly these deployments. It also removes the old habit of keeping a device on a private cable that nobody else can reach. Each device needs to defend itself and prove who it is.

What are the main risk areas?

Weak devices. Default passwords, no update path and open management interfaces are the common weak points, and they are exactly what NIST's IoT device baseline targets.

Unclear ownership. When a sensor misbehaves, who patches it: the city, the vendor, the carrier or an integrator? If no one owns it, nobody does.

Flat connectivity. If a camera network can reach the billing system, a camera flaw becomes a billing incident.

Data sprawl. Cameras, license plate readers and mobility data raise privacy questions, and retention rules often lag the deployment.

Long lifespans. Devices outlive support periods. A procurement that ignores updates leaves the city with fixed hardware and a growing list of known flaws.

What baseline can a city ask suppliers for?

NIST IR 8259A defines a core baseline of device cybersecurity capabilities. It lists six: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness. These make a practical procurement checklist, because each one is something a supplier can show.

A constructed example: a city buys parking sensors. The tender asks the supplier to show that each device has a unique identity, that configuration changes can be controlled and logged, that local data is protected, that its management interface needs authentication, that signed updates can be applied remotely, and that the device can report its own state. A bid that cannot answer is a bid with hidden operating costs.

How do you limit the blast radius?

Treat the network as untrusted and segment by function. Traffic signals, water systems, public Wi-Fi and city offices should not share a flat network. NIST SP 800-207 describes zero trust as removing implicit trust based only on network location, which suits this setting: each connection is evaluated, not assumed safe because it arrived on the city network.

Who decides what is acceptable?

This is a governance question as much as a technical one. A city that sets minimum device requirements, a named owner per device class and a shared incident contact list has done most of the hard work. A city that leaves each department to buy and run its own devices will find out about gaps during an outage. Put the baseline in the contract template so that every department inherits it.

How to check or apply this

  1. Build an asset inventory of every connected device class, with owner, supplier, location and support end date.
  2. Add the NIST IR 8259A capabilities to procurement templates as requirements, with evidence requested at bid time.
  3. Segment by function and restrict device-to-system paths to what each device needs.
  4. Require an update path and a named patch owner in every supply contract.
  5. Set data retention and access rules before cameras and sensors go live.
  6. Rehearse a failure: pick one device class and practice isolating it without turning off the service.

Quick check

Does 5G make IoT devices secure?

No. 5G secures the radio and network side to a degree, but a device with a default password or no update path is still weak. Device security is a separate requirement.

Where should a city start?

With the inventory. You cannot protect, patch or retire devices you cannot list.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.