· ~6 min read
Designing a secure smart-city IoT architecture
A layered edge-to-cloud design for city cameras, traffic sensors and street lighting, and the controls that keep one hacked lamp post from reaching the rest.
Goal
For the Security Architecture Design course of my MSc I designed the security architecture of a smart city's IoT infrastructure: public cameras, traffic and environmental sensors, and smart street lighting. The questions were where the data goes, who may see it, what can go wrong, and which controls belong at which layer.
What makes this problem hard is not any single device. It is thousands of cheap, physically exposed devices, on a city network that also carries systems that matter, run by an organisation whose citizens never agreed to be filmed.
The layers
| Layer | What lives there | Main security concern |
|---|---|---|
| Perception | Cameras, radar, inductive loops, air-quality sensors, street lights | Physical tampering, fake nodes, false readings |
| Network | LoRaWAN, NB-IoT, Zigbee, 6LoWPAN, Wi-Fi mesh, 4G/5G, fibre | Interception, man-in-the-middle, lateral movement |
| Edge / fog | Local nodes at junctions that filter, validate and run inference | Keeping raw video local, validating payloads |
| Cloud / data | The city's operations centre, storage, analytics, model training | Access control, encryption at rest, retention |
| Application | Dashboards for the municipality, APIs for third parties, citizen apps | Authorisation, rate limiting, what leaves the city |
How data flows
- Edge pre-processing. Raw sensor and camera streams stop at an edge node. It validates the payload, removes noise and runs light inference, so only small, structured metadata moves on ("15 vehicles waiting at junction A", not the video).
- Brokered transport. The metadata travels over publish/subscribe (MQTT), grouped into topics such as telemetry, commands and service management, so each subsystem receives only what it subscribes to.
- Cloud analytics. Streams from across the city are fused. Stream processing raises alerts on anomalies, and batch processing handles historical analysis and model training.
- Controlled sharing. Results leave only through an API gateway that enforces access policies and rate limits, towards municipal dashboards, third-party services and citizens' phones.
Pushing inference to the edge is the decision everything else rests on. It saves bandwidth, it removes the cloud round trip from time-critical decisions such as adaptive traffic lights, and it is the first privacy control: images that never leave the junction cannot leak from the data centre.
Protocols follow the device
| Subsystem | Needs | Protocols |
|---|---|---|
| Street lighting, environmental sensors | Tiny messages, low power, long range | LoRaWAN, Zigbee / 6LoWPAN, Wi-Fi mesh between lamps, MQTT or CoAP on top |
| Public cameras | High bandwidth, low latency | Wired Ethernet to the edge node, 4G/5G with a VPN back to the city, UDP for live operator video |
What can go wrong
- False data, real consequences. A manipulated traffic sensor reporting phantom congestion makes the automation reroute traffic or retime lights. Taking over the lighting network allows a deliberate blackout. Because subsystems depend on each other, one failure can cascade.
- The device as a door. A vulnerable camera becomes the entry point, and without segmentation the attacker moves laterally to the central servers. Devices with default credentials are recruited into Mirai-style botnets and used for DDoS.
- Physical attacks. Equipment sits in public: cameras get blinded or removed, enclosures opened to pull keys from the hardware, and firmware attacks can brick a device permanently.
- Privacy breaches. Unauthorised access to live camera feeds, or deletion of recorded evidence.
Controls, layer by layer
- Segmentation. Cameras, lighting, sensors and the municipality's own IT live in separate VLANs or SDN segments, with only the flows they need allowed between them. A compromised lamp stays a compromised lamp.
- Device identity. Every legitimate device gets a certificate from the city's PKI, and devices and servers authenticate each other with mutual TLS before any data is accepted. That is what stops a planted fake node from feeding the system.
- Zero trust and least privilege. Role-based access, purpose limitation (camera data used only for the purpose it was collected for), and time-bounded access, so that, for example, police see one camera for the window of one incident and nothing before or after.
- Encryption and integrity. TLS in transit, encryption at rest, and a tamper-evident log of who accessed what.
- Monitoring. Regular telemetry (errors, uptime, temperature, power draw) and availability checks; a node that goes silent may have been tampered with. Anomaly detection flags devices whose behaviour changes, such as a lamp that suddenly draws more power or sends more traffic.
Privacy by design
The design treats personal data as something to avoid collecting, not something to protect after the fact:
- Minimisation at the edge: only anonymous counts and events leave the camera site.
- Masking at the source: faces and number plates blurred on the edge node when video must be sent.
- Privacy-enhancing technologies: differential privacy for statistics shared with third parties, federated learning so models improve without central image collection.
- Governance: a DPIA before any new monitoring technology, data-processing agreements and security checks for vendors, and compliance with the GDPR and, in Greece, Law 4961/2022, which sets obligations for public bodies that deploy IoT devices.
What I learned
Re-reading my own report, I would tighten three claims.
- Hashing number plates is pseudonymisation, not anonymisation. The space of plates is small enough to enumerate, so a plain hash can be reversed by brute force. A keyed hash (HMAC) with a key kept at the edge and rotated regularly is much better, but the result is still personal data under the GDPR.
- A blockchain is not required for tamper evidence. I proposed one for access logs. An append-only log with hash chaining and signed checkpoints, kept on write-once storage, gives the same guarantee with far less machinery. A distributed ledger only earns its cost when several parties that do not trust each other must share the log.
- "End-to-end encryption" needs to be precise. What the design actually needs is mutual TLS between devices, edge and cloud, plus encryption at rest with real key management. End-to-end in the strict sense, where the city's own servers cannot read the data, would conflict with the analytics the design is built for.
An individual design project for the MSc in Cybersecurity & Data Science at the University of Piraeus, based on published research and standards rather than a live deployment.
Want the configs or code from this lab, or have a question? Email me at kostaspapas1023@gmail.com