↓ Skip to main content
  1. Posts/

IoT Security for Smart Cities and Infrastructure

·3914 words·19 mins·
Table of Contents

Smart cities and critical infrastructure now run on a sprawling mesh of IoT and operational technology: smart meters, traffic controllers, building automation, patient monitors, PLCs in water and power plants, cellular routers doing edge processing. The bad news for defenders is that most of that gear was shipped by vendors who treated security as a bill of materials line item, and the utilities and municipalities that bought it typically cannot patch it on any reasonable cadence.

This post is defender-oriented. If you are building the security program for a utility, a hospital, a city IT shop, or a facility that runs anything with a PLC in it, this is the shape of what you are up against and where to push back. Attackers use these same techniques; the framing here is what you look for, not how you break in.

Defensive tradecraft. All examples assume you own or are authorized to assess the systems you are touching. IoT/OT hunting on infrastructure you do not have written authorization for is not “curious poking around;” it is a federal problem.

The shape of what you defend
#

Devices span everything from a $3 temperature sensor with no update mechanism to a $2M industrial CT scanner running an unpatched embedded Windows. The security posture varies as wildly as the price point.

Edge gateways aggregate data from local devices and mediate the trip to the cloud. Historically these ran embedded Linux with SSH open on port 22 and a hardcoded root password. Increasingly they run container runtimes and are managed like microservices, which is progress if the operator manages them.

Network protocols are the interesting part. IoT protocol soup includes Wi-Fi, Bluetooth (Classic + LE + Mesh), Zigbee, Z-Wave, Thread, LoRaWAN, NB-IoT, LTE-M, 5G RedCap, plus application protocols like MQTT, CoAP, OPC-UA, Modbus/TCP, and BACnet. Each has its own idea of what “security” means, and several of them were designed in an era when “on a trusted network” was doing all the heavy lifting.

Cloud platforms provide the storage, the analytics, and (unfortunately) frequently the identity boundary. When a smart camera vendor’s cloud gets popped, the customers’ cameras get popped by extension. Verkada in March 2021 was the wake-up call there.

Applications are the operator-facing part. Modern ones lean on the cloud APIs; older ones are Windows-based SCADA HMIs running Wonderware or GE iFIX on hosts that have not been rebooted since 2019.

IoT lives in sectors that matter
#

  • Smart grids use Advanced Metering Infrastructure (AMI) and Phasor Measurement Units (PMUs) for real-time monitoring and predictive maintenance. IEC 61850 and DNP3 are the protocols to know. Utilities in North America live under NERC CIP compliance.
  • Intelligent transportation systems include smart traffic controllers, connected-vehicle infrastructure (V2X), electronic tolling, and camera-based enforcement. NTCIP is the protocol family in the US.
  • Healthcare runs remote patient monitoring, imaging, infusion pumps, and networked lab equipment. FDA cybersecurity requirements tightened in 2023 when section 524B of the FD&C Act (the enacted form of the PATCH Act) took effect, and from October 1, 2023 the FDA started refusing device submissions without a cybersecurity plan.
  • Smart buildings rely on BACnet, KNX, and Modbus for HVAC, lighting, and access control. BACnet/SC (Secure Connect) added TLS-based transport in 2019, but adoption is patchy.
  • Industrial IoT and Industry 4.0 covers predictive maintenance sensors, asset tracking, and process automation, layered onto the Purdue Enterprise Reference Architecture. NIST SP 800-82r3 (September 2023) is the current baseline guide for ICS/OT security in the US.

IoT protocols and their security defaults
#

  • MQTT is a lightweight publish/subscribe protocol widely used across IoT. MQTT 5.0 (2019 OASIS standard) added enhanced authentication, session expiry, and clearer error semantics. Security still relies on TLS at the transport layer plus broker-level auth. Public MQTT brokers with no auth are still findable on Shodan today; they are typically someone’s smart-home telemetry.
  • CoAP (RFC 7252, 2014) is HTTP-shaped for constrained devices. Uses DTLS for security. Vulnerable to IP spoofing and amplification attacks when exposed to the internet without rate limiting.
  • Zigbee operates on 2.4 GHz IEEE 802.15.4 and uses AES-128-CCM. Weak implementations, especially default network keys and poor rotation, have caused a decade of research talks at DEF CON and Black Hat.
  • Z-Wave is another sub-GHz protocol for home automation. The S2 Security framework (introduced 2016) uses AES-128 with proper key exchange, but older S0-only devices remain vulnerable to well-documented key-recovery attacks.
  • Modbus (particularly Modbus/TCP on port 502) is a serial protocol adapted for TCP that ships with no authentication, no encryption, and no session control. It runs vast amounts of industrial equipment. Modbus/TCP Security (TLS on port 802) was published in 2018, but real-world deployment is rare.
  • BACnet (UDP port 47808) is the dominant building-automation protocol. BACnet/SC added a TLS-secured transport in 2019.

Knowing the protocols is the first move. Knowing that most of them either lack authentication or have optional authentication their operators never turned on is the point.

The threat picture
#

The interesting failures are almost never novel cryptographic attacks. They are unauthenticated management interfaces, default credentials, unsegmented networks, and unmaintained firmware.

Device-level failure modes
#

  • Weak or default credentials remain the single most reliable initial-access vector. The original Mirai botnet loaded a dictionary of 62 vendor default username/password pairs and rode it to one of the largest DDoS events in internet history. In 2026, that same class of failure is still happening; the credentials just belong to different vendor SKUs.
  • Insecure management interfaces on IoT devices, web UIs, cloud APIs, mobile companion apps, are frequently the shortest path in. XSS, SQLi, and command injection in an embedded device’s admin panel are ordinary findings on IoT engagements.
  • Missing or optional update mechanisms. A lot of IoT gear either never receives updates or requires a user to manually download and apply firmware from a vendor portal. Devices remain vulnerable to a decade-old flaw because “the user has not updated.” Some devices exceed vendor support life while still in production use.
  • Unencrypted or weakly encrypted transport. Especially common on legacy industrial gear. Modbus/TCP is not encrypted. Older BACnet is not encrypted. Getting on the wire lets an attacker read or modify the data outright.
  • Physical exposure. Field-deployed sensors, roadside cabinets, and utility RTUs are often in locations an adversary can reach with a screwdriver. JTAG headers, UART ports on the PCB, and off-the-shelf flash-dump tools remove the “we assume physical security” mitigation the vendor was quietly relying on.

Network-level failure modes
#

  • Flat networks. The single most common finding on an OT assessment: the corporate LAN and the plant control network share a broadcast domain. Compromise one workstation and you can talk directly to a PLC.
  • Wireless exposure. Weak Wi-Fi, unsegmented guest networks, and rogue access points. Verkada’s 2021 incident started with admin credentials sitting on an internet-exposed support server, but plenty of camera incidents have started with WPA2 keys posted on a facilities sticker.
  • Missing telemetry. If you cannot see what is on the OT network, you cannot see what is talking to what, and you certainly cannot see when something new starts talking to the PLC.

Named incidents worth knowing
#

  • Mirai (2016). Paras Jha (a Rutgers student at the time), Josiah White, and Dalton Norman pled guilty in December 2017 to authoring the botnet, which took down Krebs on Security (September 20, 2016, at about 620 Gbps), OVH (same week), and Dyn (October 21, 2016; the outage cascaded through Twitter, Reddit, Spotify, Netflix, and CNN, among others). Mirai source was released publicly by the authors, which produced a decade of copycats: Satori (2017, Huawei HG532 zero-day CVE-2017-17215), Reaper/IoTroop (Check Point, October 2017), Mozi (2019, operators arrested in 2021 and the botnet killed outright by a kill switch in August 2023), and currently Aisuru (2024 onward, which pushed DDoS records past 30 Tbps by the end of 2025).
  • Stuxnet (public disclosure 2010). Sergey Ulasen at Belarusian antivirus firm VirusBlokAda documented it publicly. Widely attributed to a joint US/Israeli operation (Operation Olympic Games), the worm used four Windows zero-days, targeted Siemens Step7 / S7 PLCs at the Natanz uranium enrichment facility, and specifically manipulated the centrifuge frequencies while feeding correct data back to the monitoring systems. Still the reference OT attack.
  • Jeep Cherokee (2015). Charlie Miller and Chris Valasek demonstrated remote takeover of a moving Jeep via the Uconnect head unit over Sprint’s cellular network at Black Hat USA / DEF CON 23. Fiat Chrysler recalled 1.4 million vehicles. Auto industry security posture measurably improved after this one.
  • Ripple20 (June 2020). JSOF disclosed 19 vulnerabilities in the Treck TCP/IP stack embedded in an enormous number of IoT and OT devices.
  • URGENT/11 (2019). Armis disclosed 11 vulnerabilities in the VxWorks IPnet stack. Same shape as Ripple20; a supply-chain flaw in a component that shipped inside thousands of products.
  • Log4Shell (December 2021). CVE-2021-44228 was a Java bug, but many of the affected devices were IoT/OT. CISA’s advisory listed web cameras, car navigation systems, parking meters, medical devices, and network gear, plus the VMware vCenter management stations plant operators run. Cleanup was still ongoing in 2023.
  • Verkada (March 2021). Attackers used valid admin credentials found on an internet-exposed support server to reach approximately 150,000 surveillance cameras across Tesla facilities, prisons, schools, and hospitals. Verkada’s follow-up narrowed confirmed data access to 95 customers (Mandiant’s final count was 97), but the reachability figure is the more useful one for threat modeling. The FTC settled with Verkada in 2024 for $2.95 million and a mandated security program.
  • Volt Typhoon (Microsoft disclosure May 24, 2023, ongoing). Chinese state actor targeting US critical infrastructure with almost exclusively living-off-the-land tradecraft. The FBI publicly disrupted a botnet of compromised end-of-life SOHO routers, primarily Cisco RV320/325 and NETGEAR gear, that Volt Typhoon used as C2 infrastructure in January 2024. CISA/NSA/FBI advisory AA24-038A followed in February 2024.
  • CyberAv3ngers on Unitronics PLCs (November 2023). IRGC-linked actors defaced Unitronics Vision-series PLCs at water utilities across the US, including the Municipal Water Authority of Aliquippa, Pennsylvania. Impact was mostly cosmetic (the HMIs showed anti-Israel messaging), but the tradecraft was trivial: a default password (reported as 1111) on the PLC’s PCOM programming port, TCP 20256, exposed to the internet.
  • American Water Works (October 2024). The largest US regulated water and wastewater utility disclosed a cybersecurity incident that took its customer portal offline. Details remain limited; the incident is a reminder that “critical infrastructure” is not only PLCs, it is also the billing systems those utilities cannot operate without.

The same pattern repeats: an unmaintained embedded component, a hardcoded credential, a network segment that should not have been reachable, a botnet stitching millions of overlooked devices together.

Flock, and the part of the smart city that watches you
#

Most of this post is about things attackers do to infrastructure. Flock Safety is the other failure mode: infrastructure that works exactly as designed, and the design is the problem. You cannot talk about smart cities in 2026 without it.

The tech
#

Flock sells solar-powered, LTE-connected license plate reader cameras to police departments, HOAs, and businesses. The camera does more than read plates. Its “Vehicle Fingerprint” model tags make, model, color, and what Flock calls “thousands of unique vehicle characteristics,” so an officer can search for “silver Honda with a roof rack and a dented bumper” without a plate at all. Every read is matched against hot lists and stored, by default for 30 days under most contracts, though Flock said in August 2026 it would cut the default to a week. The same company sells Raven gunshot detection, Condor PTZ cameras, FlockOS as the console tying it together, and since buying Aerodome in October 2024 , drones dispatched to 911 calls.

The feature that matters is the network. Flock’s “National Lookup” let an agency run one plate against cameras owned by thousands of other customers across the country. A camera a town bought to find stolen cars became, by default, a node in a national vehicle-tracking database. By 2025 Flock claimed more than 5,000 communities, and in March 2025 it raised $275 million at a $7.5 billion valuation . Senator Hawley’s office put the network at about 120,000 cameras and 20 billion images a month in September 2026.

What went wrong
#

The abuse cases arrived through public records requests, which is itself the lesson: the audit logs existed, and nobody at the agencies was reading them.

  • In May 2025, 404 Media obtained search logs from Danville, Illinois, showing more than 4,000 nationwide or statewide lookups with reason fields like “immigration” and “ICE+ERO.” Flock had no contract with ICE. Local police were running the searches on its behalf.
  • On May 9, 2025, a Johnson County, Texas deputy searched more than 83,000 cameras nationwide for a woman who had self-managed an abortion. The reason field read “had an abortion, search for female.” The sheriff called it a welfare check. EFF later obtained the affidavit, which called it a death investigation and noted prosecutors had been consulted about charging her.
  • The Illinois Secretary of State audited the state’s Flock customers and found 46 out-of-state agencies had queried Illinois cameras for immigration enforcement, in violation of a 2023 state law, and that Customs and Border Protection had been reaching the network through an undisclosed Flock pilot. 404 Media found CBP could search more than 80,000 cameras through agencies that did not know they were sharing with it.

Flock’s responses came in order: keyword blocks on immigration and reproductive-health search reasons (June 2025), National Lookup disabled for California, Illinois, and Virginia agencies (June 2025), federal pilots paused (August 2025), a one-click toggle to disable all federal sharing (January 2026). The ACLU’s review of the logs found the “documented reason” control had been satisfied with entries like “investigation” and “hehehe.” A required free-text field is not a control.

Cities started leaving. NPR counted at least 30 localities cancelling by February 2026, Austin, Evanston, Eugene, and Santa Cruz among them, and in March 2026 Denver replaced its 110 Flock cameras with Axon’s. Two cancellations are worth a defender’s attention for a different reason. Evanston deactivated its cameras and found Flock had reinstalled some; the city sent a cease-and-desist. Cambridge, Massachusetts terminated after Flock technicians installed two cameras during a pause “without the City’s awareness.” If your vendor can put sensors on your streets without your knowledge, the contract is not the control you think it is.

The legal fight#

The Institute for Justice sued Norfolk, Virginia in October 2024 over its citywide camera network on Fourth Amendment grounds. In January 2026 the district court ruled for the city but warned the balance “could conceivably tip the other way” as the network grows; the appeal is before the Fourth Circuit. EFF and the ACLU of Northern California sued San Jose in November 2025 over 474 cameras and about 261,000 warrantless searches . A Washington state court held in November 2025 that Flock images are public records , which means anyone can request them, and several Washington cities switched their cameras off rather than find out what that meant. Virginia capped retention at 21 days in 2025, and Washington’s Driver Privacy Act followed in 2026 with a 21-day cap, a ban on immigration-enforcement use, and no cameras near clinics, schools, churches, courts, or food banks. On September 23, 2026 the Senate Judiciary crime subcommittee held a hearing titled “Always Watching” ; the CEOs of Flock, Axon, Motorola, and Verkada were invited and declined.

The security side
#

Then there is the part that belongs in this post on the merits. In December 2025, 404 Media and researcher Benn Jordan found at least 60 Condor cameras on Shodan with live streams and admin panels open to the internet, no login required. Older Falcon units run Android Things 8.x. Hudson Rock found Flock customer passwords in infostealer logs, and in November 2025 Senators Wyden and Krishnamoorthi asked the FTC to investigate Flock for not requiring MFA on accounts that can query a national vehicle database. Flock’s own May 2025 plan for a people-search product called Nova included data from known breaches until the reporting forced a reversal. Flock published a Bishop Fox penetration test in September 2026 (36 findings, 2 critical, 7 high, all fixed by its account) and became a CVE Numbering Authority the next month. That is the right direction. It is also what a company does after the story breaks, not before.

For a city IT shop, treat an ALPR network as a data-sharing system first and a camera second. The questions are who can query it, what the sharing defaults are, whether anyone reads the audit log, how long reads live, what a public records request returns, whether the vendor’s own accounts have MFA, and whether the vendor can touch hardware on your streets without a ticket. Add “abuse by an authorized user” to the STRIDE list below. It is the threat that showed up.

Building a defense that holds
#

There is a temptation to skip to “penetration testing” as if that were the answer. It is not. On IoT and OT, the useful order is asset visibility first, then segmentation, then identity and credentials, then detection, then a managed vulnerability program, and only then adversary emulation and testing. Skipping steps produces a very expensive report and no security improvement.

1. Asset inventory
#

You cannot defend what you cannot see. On OT specifically, active scanning (running Nmap or Nessus against a plant network) can cause equipment to crash. Use passive discovery tools that watch network traffic and identify assets by protocol fingerprint:

  • Nozomi Networks Guardian, Claroty CTD / xDome, Armis, Dragos Platform for OT-specific asset discovery and monitoring
  • runZero (formerly Rumble) for hybrid IT/OT environments
  • CISA CyberSentry (offered free to critical infrastructure operators in the US, though its funding has been under pressure since 2025)

2. Segmentation and the Purdue Model
#

The Purdue Enterprise Reference Architecture splits industrial networks into levels 0 (physical process) through 5 (enterprise). The security payoff is enforcing traffic direction and protocol allowlisting between levels: level 2 (SCADA) does not talk directly to level 5 (corporate email), and level 3 (site operations) mediates everything in between. Industrial DMZ (Level 3.5) is where data historians and remote-access jump boxes live.

Modern deployments are messier than the reference model; cloud-based analytics blur levels 3, 4, and 5. The point is not the diagram but that you have explicit segmentation policy and enforce it at the firewall.

3. Identity, credentials, and remote access
#

Kill hardcoded credentials. Enforce individual accounts on every management interface a human touches. Require MFA on any remote OT access, preferably phishing-resistant (FIDO2/WebAuthn). If the vendor’s remote-support tunnel is “we open a permanent OpenVPN back to our office,” you have a problem; move that to explicit, ticketed, session-recorded jump-box access.

4. Detection
#

For IT-side IoT (smart cameras, building automation, smart TVs in offices), use your existing SIEM and NDR. For OT specifically, the vendors named above ship purpose-built detection: baseline modeling of normal PLC traffic, detection when a workstation starts issuing Modbus write commands to a controller it never spoke to before, integration with MITRE ATT&CK for ICS (a separate matrix within ATT&CK, released in January 2020 and now versioned alongside Enterprise).

5. Vulnerability management (for real this time)
#

Track vendor security bulletins, CISA advisories (particularly the CISA ICS-CERT advisories), and the CISA Known Exploited Vulnerabilities (KEV) catalog. For OT, patching windows are measured in months and quarterly maintenance windows, not days. Compensating controls (segmentation, protocol filtering, virtual patching at the firewall) do most of the work between patch windows.

6. Adversary emulation
#

Only after the above. Then, bring in a team that specifically has OT experience. Dragos and Mandiant sell this, and critical infrastructure operators can get it through DOE’s CyTRICS program, which runs through Idaho National Lab and the other national labs. Test against realistic scenarios: initial access via a phished engineer’s laptop, lateral movement into the DMZ, discovery of the plant historian, and if authorized, a controlled test of PLC command capability in a lab environment (never in production).

Threat modeling with STRIDE, still useful
#

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) predates modern IoT by two decades and is still one of the fastest ways to structure a threat model for a new deployment. For each asset and data flow:

  • Spoofing: can something impersonate a device, a user, or a controller?
  • Tampering: can data in transit or at rest be modified undetected?
  • Repudiation: can an actor take an action without a durable audit trail?
  • Information disclosure: can an unauthorized party read data?
  • Denial of service: can an adversary knock the system offline, and what does “offline” cost?
  • Elevation of privilege: can a low-privilege actor gain higher privileges?

For OT specifically, add safety to the list. “The PLC controls a physical process that can hurt people if it misbehaves” is a threat category that IT threat models often skip entirely.

The regulatory picture is finally moving
#

For years, IoT security was a market failure: vendors had no incentive to bake in security, buyers had no way to compare products on it. That is changing.

  • US IoT Cybersecurity Improvement Act (2020) required federal agencies to only procure IoT devices meeting NIST-defined baselines (NIST SP 800-213 and the 8259 series). Federal procurement is a large lever.
  • US Cyber Trust Mark (FCC, established as voluntary in 2024) is the consumer-facing IoT security label modeled loosely on Energy Star. As of mid-2026 the program was still standing itself up: the original lead administrator, UL Solutions, withdrew in December 2025, and the FCC named the ioXt Alliance as its replacement in April 2026.
  • UK PSTI Act (Product Security and Telecommunications Infrastructure Act) came into force April 29, 2024. Bans universal default passwords on consumer IoT, requires vendors to publish security update timelines.
  • EU Cyber Resilience Act (CRA) entered into force December 10, 2024. Reporting obligations apply from September 11, 2026; full compliance is required by December 11, 2027. It mandates baseline security requirements and vulnerability disclosure for all “products with digital elements” sold in the EU, effectively a market-wide security floor.
  • EU RED Delegated Regulation 2022/30 (Radio Equipment Directive cybersecurity requirements) applies from August 1, 2025 (pushed back from the original August 1, 2024 date) and mandates cybersecurity essentials for internet-connected radio products.

Effectively every major consumer IoT vendor now has to meet at least one of these baselines to sell in Western markets. That is not going to fix everything, but it is moving vendor incentives.

The short version
#

If you defend infrastructure that runs on IoT or OT, start with asset visibility (passively, if OT), enforce segmentation, kill hardcoded and default credentials, deploy detection tuned for OT protocols, and treat vulnerability management as an ongoing negotiation between security and safety. The interesting attacks are still, overwhelmingly, the boring ones: default creds, missed patches, and a flat network.

Regulatory pressure is forcing vendors to ship better defaults. That will help future buyers more than current ones, but the existing deployed base is going to be around for a decade or more, so the defender’s job is not going anywhere soon.

Further reading
#

UncleSp1d3r
Author
UncleSp1d3r
As a computer security professional, I’m passionate about building secure systems and exploring new technologies to enhance threat detection and response capabilities. My experience with Rails development has enabled me to create efficient and scalable web applications. At the same time, my passion for learning Rust has allowed me to develop more secure and high-performance software. I’m also interested in Nim and love creating custom security tools.