A smart city joins traffic signals, cameras, street lighting, parking, water and energy systems, payment kiosks and citizen apps to the same networks and data platforms, so one compromised account or device can now affect services that used to fail on their own. Cities run this estate with municipal IT budgets, long procurement cycles and a heavy reliance on vendors who manage devices remotely, while ransomware crews have shown repeatedly that local government will be hit. This guide covers the smart city threat picture, the regulation that now applies to the devices and the operators, the architecture and supply chain controls that differ from ordinary corporate IT, and how to keep services running when systems fail. It is for city CISOs, smart city leads, OT and IoT engineers and their suppliers.
Key takeaways
- Interconnection is the new risk. The 2023 joint guidance from CISA, NSA, FBI and the Five Eyes cyber centres names the expanded, interconnected attack surface, the ICT supply chain and the automation of infrastructure as the three core smart city risks.
- Ransomware is the incident that actually happens. SamSam hit Atlanta and Newark, and Royal used a city service account to reach Dallas systems for almost four weeks before encrypting, disrupting police and ambulance dispatch.
- Vendors hold the keys. Cameras, signals, sensors and platforms are often managed from a supplier's cloud or support desk, so supplier access, contracts and credentials are core controls, not paperwork.
- Device and operator rules now overlap. The UK PSTI regime, the EU Cyber Resilience Act, NIS2 and the EU AI Act each touch parts of a smart city, from default passwords to real-time facial recognition.
- Plan to run without the network. Manual operation of signals, dispatch and payments, isolated backups and printed response plans decide how long citizens feel an incident.
What a smart city is, and why it is different
The UK NCSC defines a connected place as a community that uses information and communication technologies and IoT devices to collect and analyse data, so it can deliver new services to the built environment and improve quality of life. In practice that means sensors, networks and applications across transport, buildings, utilities, the environment, infrastructure and public services, often owned by different departments and operated by different contractors.
Three properties make it harder to secure than a corporate network:
- Mixed ownership: the city owns some assets, utilities and transport operators own others, and many devices are leased or delivered as a managed service.
- Physical exposure: devices sit on lamp posts, in cabinets and on roadsides where anyone can reach them. The joint guidance asks cities to protect sensors and monitors against theft, tampering, vandalism and environmental damage, not only against network attack.
- Long lifecycles: traffic controllers and water SCADA can run for decades, so new platforms must connect securely to legacy components.
Smart city systems also aggregate location, movement and video data on citizens, and vendors may hold data from several communities at once, so one supplier breach can expose more than one city.
The smart city threat picture
| System | Typical owner or operator | Main threat | Impact if it fails |
|---|---|---|---|
| Corporate IT, identity and email | City IT | Ransomware via stolen or service account credentials, exposed remote access | Payments, permits, courts, 311 and dispatch support systems go down |
| Public safety systems (computer-aided dispatch, radio, 911/999 interfaces) | Police, fire, ambulance, city | Collateral damage from IT ransomware, insider misuse | Delayed or misrouted emergency response |
| Video surveillance and access control | City, police, vendor cloud | Vendor platform compromise, default credentials, exposed web interfaces | Privacy breach, loss of evidence, unauthorised viewing |
| Traffic signals, adaptive control, signs | Highways or transport authority, maintenance contractor | Exposed controllers and vendor remote access | Congestion, safety risk, loss of public trust |
| Smart lighting, environmental and parking sensors | City or managed service provider | Botnet recruitment, weak device credentials, insecure firmware updates | Usually low per device, high when used as a pivot |
| Water, energy and district heating SCADA | Utility or city department | Internet-exposed HMIs, remote access, ransomware spread from IT | Loss of essential services, safety and environmental harm |
| Urban data platform and citizen apps | City digital team, SaaS supplier | API and account abuse, leaked keys, data aggregation | Large-scale personal data exposure |
What the incidents show
- Atlanta and Newark (SamSam, 2018): the US Department of Justice indictment of November 2018 named the City of Atlanta, the City of Newark, the Port of San Diego and the Colorado Department of Transportation among more than 200 victims, with alleged losses above $30 million. The actors researched targets, launched attacks outside business hours and encrypted backups to maximise disruption.
- Dallas (Royal, 2023): the city's after-action findings, as reported by The Record, show the group entered on 7 April 2023 through a city service account, deployed remote management tools, took about 1.17 TB of data and encrypted systems at 2 a.m. on 3 May. The computer-aided dispatch system was disrupted, about 230 servers were affected and the city budgeted $8.5 million for recovery. The report pointed to technical debt from outdated and unsupported systems.
Regulation and policy that applies
No single law covers "smart cities". Obligations come from the operator side (the city or utility as a regulated entity), the product side (connected devices placed on the market) and the data side (personal data and biometric processing). Status below was checked in October 2026.
| Instrument | Applies to | Status | What it means for a smart city |
|---|---|---|---|
| EU NIS2 Directive (EU) 2022/2555 | Public administration at central and regional level; utilities, transport and digital infrastructure; member states may extend it to local government | In force 16 January 2023; transposition deadline 17 October 2024 | Risk management measures, management accountability, staged incident reporting (24 hours, 72 hours, one month). Check whether your national law covers municipalities. See the NIS2 Directive Guide. |
| EU Cyber Resilience Act (Regulation (EU) 2024/2847) | Manufacturers, importers and distributors of products with digital elements sold in the EU | In force 10 December 2024; main obligations apply from 11 December 2027 | Write CRA conformity and support periods into procurement for sensors, cameras and controllers. See the EU Cyber Resilience Act Guide. |
| UK Product Security and Telecommunications Infrastructure (PSTI) regime | Consumer connectable products sold in the UK | In force 29 April 2024 | No universal default passwords, a published way to report vulnerabilities and a stated minimum security update period. Useful baseline to demand even for non-consumer kit. See the UK PSTI Act Guide. |
| EU AI Act, Article 5(1)(h) | Use of real-time remote biometric identification in publicly accessible spaces for law enforcement | Prohibitions apply from 2 February 2025 | Prohibited except for narrow, authorised purposes with prior judicial or independent authorisation. Live facial recognition on city cameras needs legal review before any pilot. See the EU AI Act Prohibited Practices Guide. |
| GDPR and UK GDPR | Any processing of personal data, including video, plate recognition and location | In force | Data protection impact assessments for surveillance, security of processing (Article 32), breach notification. See the GDPR Compliance Guide for Security Teams. |
| NCSC Connected Places Cyber Security Principles (UK) | UK local and national authorities designing, building or running connected places | Guidance, not law | 14 principles in three stages: understand, design, manage. The most practical structure for a UK programme. |
| Joint guidance: Cybersecurity Best Practices for Smart Cities | Communities in the US, UK, Australia, Canada and New Zealand | Published 19 April 2023; guidance | Secure planning and design, proactive supply chain risk management, operational resilience. |
Secure architecture for connected places
The NCSC principles put architecture, exposure, data protection, resilience and monitoring (principles 6 to 10) before day-to-day management, because retrofitting segmentation onto deployed devices is far harder. The joint guidance asks cities to isolate trust-by-default OT networks and secure their interconnections with zero trust principles, requiring authentication and authorisation for each new connection.
- Zone by function and consequence: separate corporate IT, public safety, traffic and transport, building systems, utilities SCADA and low-risk sensor networks. Group critical systems, document the topology and name an accountable owner for each zone. See the Network Segmentation Guide.
- Broker every cross-zone flow: data that leaves an OT zone for the urban data platform should pass through a gateway or data diode style pattern, pushed outward, with no inbound management path from the data platform back into control systems.
- Remove direct internet exposure: controllers, HMIs, camera recorders and building management interfaces should never be reachable from the internet. Scan externally to find the ones that are. See the Edge Device Security Guide.
- Harden the boundary devices: VPN concentrators and remote access gateways are the most attacked component of any municipal estate. The joint guidance calls for hardened remote access and protection of internet-facing services against credential stuffing.
- Design for physical compromise: assume a roadside cabinet will be opened. Use port security or 802.1X on switch ports, disable unused interfaces, protect device keys in secure elements where available, and make sure one stolen device yields no credential that works elsewhere.
- Protect the data layer: minimise collection, pseudonymise movement data, set retention per data set and run a DPIA before any new sensing capability (NCSC principle 8). See the Building Management System Security Guide and the Water and Wastewater Cybersecurity Guide for specialist systems.
Where identity fits: devices, vendors and service accounts
Most smart city incidents start with an identity rather than an exploit: a service account in Dallas, a support credential at a camera vendor, a shared password on a field controller. The joint guidance is explicit about least privilege, tiered administrative access, dedicated hardened privileged access workstations and just-in-time or time-limited privileges, and about multi-factor authentication for remote access and privileged actions that does not fail open or allow insecure re-enrolment.
| Identity type | Smart city example | Priority control |
|---|---|---|
| Device identity | Streetlight node, camera, parking sensor, EV charger | Unique per-device credentials or certificates issued at enrolment, no shared default passwords, revocation when a device is replaced or stolen. See the Device and IoT Identity Guide. |
| Vendor and integrator accounts | Signal maintenance contractor, camera platform support, SCADA integrator | Named accounts, MFA, session brokering and recording, access granted per job and expired after. See the OT Remote Access Guide. |
| Service accounts and API keys | Integration between the data platform, CAD, billing and SaaS tools | Inventory with an owner, least privilege, no interactive logon, rotation, monitoring for use from new hosts. |
| Staff and elected officials | Council staff, public safety users, councillors | Phishing-resistant MFA for administrators and remote access, joiner-mover-leaver processes tied to HR. See the Local Government Identity Security Guide. |
| Citizens | Parking and payments apps, permit portals | Customer identity controls, bot and credential stuffing defences, minimal data collection. |
Procurement and supply chain controls
Most smart city capability is bought, not built. The joint guidance asks cities to set minimum security requirements and the consequences of breaches in contracts, require secure development, vulnerability disclosure and patch management from software suppliers, use software bills of materials, examine how hardware is sourced and how devices protect data, and keep a risk register of dependencies such as cloud services. NCSC principles 4 and 12 cover the same ground for UK authorities.
| Contract clause | What to require | Why |
|---|---|---|
| Credentials | Unique per-device credentials, no hard-coded or universal passwords, customer-controlled admin accounts | Mirrors the PSTI baseline and removes the easiest attack |
| Security update period | A stated end date for security updates, at least matching the planned asset life, with notice of end of support | Prevents unsupported devices staying in service for years |
| Vulnerability handling | Published disclosure policy, notification to the city within an agreed time, SBOM on request | Lets the city assess exposure when a component flaw is announced |
| Remote access | Access only through the city's broker, named individuals, MFA, logging available to the city | Vendor remote access is the most common OT entry path |
| Data | Data location, ownership, segregation from other customers, deletion at contract end, breach notification timelines | Vendors may hold data from several communities |
| Exit and continuity | Export formats, escrow or transition support, ability to operate devices if the vendor cloud is unavailable | Concentrated vendor dependence raises the stakes of a supplier outage |
Assess suppliers at award and renewal. See the Third-Party Risk Management Guide and the IoT Security Guide.
Operational resilience and incident response
The joint guidance is unusually concrete here: maintain contingency plans for manual operation of critical functions, including plans to disconnect systems from each other or from the internet and operate autonomously; keep and test isolated backups for IT records and manual operational capabilities; keep hard-copy incident response plans available when the network is down and exercise them annually; and train staff on isolating compromised IT from OT and on manual procedures.
- Rank services by citizen impact: emergency dispatch, water, traffic safety and payments to vulnerable residents first. Define the maximum tolerable outage for each.
- Write the manual mode: signals that fall back to fixed time plans, paper dispatch cards, offline payment or deferral, manual gate and barrier operation. Test each at least once a year.
- Pre-agree isolation points: know which links to cut between IT and OT, who can authorise it, and what stops working when you do.
- Protect backups from the domain: SamSam encrypted backups, so keep offline or immutable copies with separate credentials and test full restores, not single files.
- Pre-arrange external help: incident response retainer, national CERT contacts, insurer, legal, and the NIS2 or national reporting route where it applies.
See the Ransomware Response and Recovery Guide and the OT Incident Response Guide.
How to implement: a phased programme
- Phase 1, discover (0 to 3 months): build one inventory of connected assets across departments and contractors, including who manages each remotely. Run external exposure scans and fix internet-facing controllers, recorders and HMIs first.
- Phase 2, close the identity gaps (1 to 6 months): phishing-resistant MFA on remote access and admin accounts, inventory and owner for every service account, removal of shared vendor accounts, default credential sweep on devices.
- Phase 3, segment (3 to 12 months): separate public safety, traffic, building, utility and sensor zones from corporate IT. Start in monitor mode with flow logging, confirm required flows with each owner, then enforce zone by zone with a documented rollback (temporary allow rule, owner sign-off).
- Phase 4, procurement baseline (ongoing): adopt the clause set above for every new purchase and renewal, with a security sign-off gate before contract award.
- Phase 5, monitor and exercise (6 to 18 months): central logging for identity, remote access and OT boundary devices; passive OT monitoring for critical zones; a joint IT, OT and public safety exercise each year.
Decision guidance
- Vendor cloud management or city-hosted: vendor cloud platforms patch faster and need less city staff, but concentrate risk in the vendor's support identities. Choose cloud where the vendor can evidence MFA, least privilege for support staff and customer-visible audit logs; keep on-premises management for safety-relevant control systems.
- Private network or public carrier: private LTE or 5G gives more control over device identity; carrier IoT services reduce operational load. Either way, authenticate at the application layer. See the 5G Security Guide.
- Small town or large city: a small authority should buy managed services with strong contract terms and focus on identity, backups and exposure; a large city should run its own OT security function, a security operations capability that covers OT, and a supplier assurance team.
Detection and measurement
Monitor the places attackers have actually entered: identity and remote access first, then the boundaries between zones.
- Identity logs: service account logons from new hosts or interactively, new MFA method registrations, privileged group changes, vendor sessions outside an approved job.
- Remote access tools: new installation or execution of remote monitoring and management software, which Royal used in Dallas.
- Boundary flows: any new connection from IT into OT or sensor zones, and any outbound transfer of unusual volume (Dallas lost about 1.17 TB over almost four weeks).
- Device health: devices going offline in clusters, firmware version drift, configuration changes not linked to a change ticket.
| Metric | What good looks like |
|---|---|
| Connected assets with a named owner and remote access path recorded | Above 95% of the inventory |
| Internet-exposed management interfaces | Zero, with time to remediate a new finding under 72 hours |
| Vendor remote sessions through the broker with MFA and recording | 100% for OT and public safety zones |
| Devices past their published security update end date | Falling each quarter, each one with a replacement plan |
| Critical services with a tested manual mode in the last 12 months | 100% of the top tier |
| Full restore test success for top-tier systems | Completed within the agreed recovery time |
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | ATT&CK techniques addressed |
|---|---|---|---|---|
| Asset inventory across departments and vendors | ID.AM-01, ID.AM-02 | CM-8 | 1, 2 | T0883 Internet Accessible Device (ICS) |
| Least privilege, MFA, service accounts | PR.AA-03, PR.AA-05 | AC-6, IA-2, IA-5 | 5, 6 | T1078 Valid Accounts, T0859 Valid Accounts (ICS) |
| Segmentation and remote access | PR.IR-01 | SC-7, AC-17 | 12, 13 | T1133 External Remote Services, T0822 External Remote Services (ICS), T0886 Remote Services (ICS), T1219 Remote Access Tools |
| Patching and end of life | PR.PS-02 | SI-2 | 7 | T1190 Exploit Public-Facing Application |
| Supply chain and procurement | GV.SC-05, GV.SC-07 | SR-3, SR-5, SR-6 | 15 | T1199 Trusted Relationship |
| Monitoring | DE.CM-01, DE.CM-09 | SI-4 | 8, 13 | T1567 Exfiltration Over Web Service |
| Backups and recovery | RC.RP-01 | CP-2, CP-9 | 11, 17 | T1486 Data Encrypted for Impact |
Common failure patterns
- Departmental islands: highways, police and facilities each buy connected systems with no central inventory, so nobody can answer which devices are exposed when a vulnerability is announced.
- Trusting the vendor's support identity: a cloud platform is only as secure as the vendor's internal admin access, as the Verkada camera breach showed when one leaked support credential opened customer cameras across many organisations.
- Over-privileged service accounts: an integration account with domain-wide rights and no monitoring gave Royal a quiet route through Dallas systems for weeks.
- Backups on the same domain: backups reachable with production credentials are encrypted with everything else, as SamSam victims found.
- Pilots that become production: a sensor or analytics trial is connected with temporary credentials and an open firewall rule, then stays for years without an owner or update plan.
- No manual mode: dispatch, parking and payment services that have never been run without their systems turn a contained IT incident into a public service failure.
Practitioner checklist
- Build a single connected asset inventory with owner, location, firmware, support end date and remote access path.
- Remove every internet-exposed controller, recorder, HMI and management interface, and scan monthly to keep it that way.
- Enforce phishing-resistant MFA on remote access, administrators and vendor accounts, with no fail-open path.
- Give every service account an owner, least privilege and monitoring; remove shared and default device credentials.
- Separate public safety, traffic, building, utility and sensor zones from corporate IT, with brokered one-way data flows.
- Route all vendor access through a broker with named accounts, per-job approval and session recording.
- Put credential, update period, disclosure, SBOM, data and exit clauses into every smart city contract.
- Run a legal and DPIA review before deploying video analytics or any biometric identification.
- Keep isolated, tested backups and printed response plans, and exercise manual operation of top-tier services yearly.
- Confirm whether national NIS2 law covers your authority and set up the 24 hour reporting route.
Standards and references
- CISA, NSA, FBI, NCSC-UK, ACSC, CCCS, NCSC-NZ: Cybersecurity Best Practices for Smart Cities
- NCSC: Connected Places Cyber Security Principles
- European Commission: NIS2 Directive
- European Commission: Cyber Resilience Act
- UK Government: The UK Product Security and Telecommunications Infrastructure (PSTI) Product Security Regime
- EU AI Act: Article 5, Prohibited AI Practices
- NIST: Cybersecurity Framework 2.0
- US Department of Justice: Two Iranian Men Indicted for Deploying Ransomware to Extort Hospitals, Municipalities and Public Institutions
Related NHI Mgmt Group resources: Cybersecurity for Local Government Guide · IoT Security Guide · OT Security Guide · Device and IoT Identity Guide · Public Sector Identity Security Guide