Start from the decision
I ask what decision each reading supports, how fast and how reliably. That sets the sample rate, the latency and the availability target, and it stops "collect everything" before it fills the WAN.
IoT and edge
Connecting thousands of devices without losing control of them
Sensors, cameras, controllers and gateways now outnumber laptops on many sites. I design how they connect, how they are trusted, where their data is processed and how the network keeps them apart. This page walks through each layer, from radios such as NB-IoT (narrowband internet of things) and LTE-M (long term evolution for machines) to MQTT (Message Queuing Telemetry Transport) brokers and cloud platforms, with diagrams you can step through.
Overview
Five layers, from the device to the decision
An IoT (internet of things) solution is a chain. A device senses something, a gateway translates it, the site keeps working on its own, a platform stores and acts on it, and an application turns it into a decision. I design every link so it is secure, segmented, resilient and easy to see.
Swipe sideways to see the whole diagram.
Sensors, cameras, PLCs (programmable logic controllers) and meters. Many run on batteries for years, speak one radio or field protocol, and cannot run security software. For each device class I record who owns it, how it is powered, what security it supports and how long the vendor will patch it.
Gateways speak the field protocols, such as Modbus, BACnet (building automation and control networks), BLE (Bluetooth Low Energy) or LoRaWAN (long range wide area network), and publish clean MQTT (Message Queuing Telemetry Transport) northbound. They normalise names and units, hold the device certificates, and filter or batch data, so the network carries one well understood protocol.
On site, a clustered broker and local rules keep alarms and control working when the WAN (wide area network) is down. Data is buffered and sent on later, so an outage loses nothing while the buffer lasts.
The platform holds the device registry, applies rules, stores time series data and sends commands and firmware back down. AWS (Amazon Web Services) IoT Core and Azure IoT Hub are the common choices, or a broker cluster in the data centre.
Dashboards, analytics, maintenance systems, ERP (enterprise resource planning) and MES (manufacturing execution systems) use the data. Each one subscribes to what it needs, instead of polling devices directly.
Scale changes everything
A design for 500 devices breaks at 50,000. I size address pools for ten times today, batch data at gateways so load grows with gateways rather than devices, and keep a fixed set of security groups however many devices join.
Owned by someone
Every device class needs a named owner who patches it, a support end date, and a place in the CMDB (configuration management database). Unowned devices are where breaches start.
From the device up
Inside a device
A device is a sensor or actuator, a microcontroller or small Linux processor, a radio, a power source and, in better ones, a secure element for its keys. I specify what matters to the network: radios and bands, 802.1X and certificate support, the update method, and how long the maker will patch it.
Sensors and actuators
Sensors measure temperature, vibration, current, air quality or presence. Actuators drive valves, relays and locks. Older ones use a 4 to 20 mA loop, a contact closure or Modbus over RS-485 to a controller or gateway, which puts the reading onto IP (internet protocol). Newer ones speak IP, BLE or LoRaWAN directly.
Measured by layer
Device: battery life, uptime and time since the last message. Network: join success, packet loss and radio quality, such as RSSI (received signal strength indicator). Broker: connected clients, message rate and dropped messages. Platform: time from reading to dashboard, and how complete the data is.
Names agreed first
Topic names, device names and asset tags are agreed before the first device goes in, because they are hard to change later. A topic such as site/leeds/line1/press3/temp tells every subscriber where a reading came from.
When a site cannot meet the standard
Some sites have old kit, no 802.1X support or a supplier who will not change. I record an exception with an owner, a risk rating and an end date. Compensating controls go in: a separate segment, MAC (media access control) authentication bypass with profiling, tight firewall rules and extra monitoring, until the site is brought up to standard.
A warehouse, worked through
Take 2,000 battery shelf sensors, 40 cameras and 30 guided vehicles. Sensors go on BLE or LoRaWAN, with few gateways and years of battery. Cameras go on wired PoE+ (Power over Ethernet plus) in their own segment, with switch power budgets checked. Vehicles roam on Wi-Fi tuned for fast roaming, or private 5G where Wi-Fi struggles.
Radios
Choosing the right radio for each device
No single radio fits every device. The choice comes down to three things: how far the signal must go, how the device is powered and how much data it sends. Each family also builds a different shape of network. Pick one to see how it connects.
Swipe sideways to see the whole diagram.
Wi-Fi. A star around access points, on 2.4, 5 and 6 GHz. It carries real bandwidth for cameras, tablets and guided vehicles, but drains batteries. I give IoT its own SSID (network name), with a key per device class rather than one shared password. The design detail is on the wireless page.
Bluetooth Low Energy. Short range, roughly 10 to 100 metres, and a coin cell can last months or years. Tags and beacons need a gateway to reach IP networks, and many enterprise access points include a BLE radio that does the job.
Thread and Zigbee. Both use IEEE (Institute of Electrical and Electronics Engineers) 802.15.4 at 2.4 GHz and 250 kbit/s. Mains powered routers relay for sleepy battery devices, so the mesh heals around a failed node. Thread carries IPv6 (internet protocol version 6) and Matter runs over it. A border router joins the mesh to the IP network. For Matter over Thread, the network must route IPv6 to the border router and carry mDNS (multicast DNS) between the controller and the border router.
LoRaWAN. Sub GHz radio, 868 MHz in the UK and Europe, reaching a few kilometres in towns and further in open country. Data rates are tiny, so it suits a few bytes an hour on a battery that lasts years. Every gateway that hears a device forwards it, and the network server removes the duplicates.
Cellular IoT. NB-IoT (narrowband IoT) reaches deep indoors with very little data, ideal for meters. LTE-M (long term evolution for machines) carries more data and supports movement and voice, which suits trackers and alarms. 5G RedCap (reduced capability) sits above both for wearables and video. A private APN (access point name) keeps device traffic off the internet.
Which radio fits my device?
Radios and links compared
| Link | Band | Typical reach | Data rate | Power | Typical uses |
|---|---|---|---|---|---|
| Wi-Fi 6 and 6E | 2.4, 5 and 6 GHz | Tens of metres per access point | Up to gigabits | Mains, PoE or rechargeable | Cameras, tablets, guided vehicles, displays |
| Bluetooth Low Energy | 2.4 GHz | 10 to 100 m | Up to 2 Mbit/s | Coin cell, months to years | Asset tags, beacons, wearables |
| Zigbee | 2.4 GHz, IEEE 802.15.4 | 10 to 100 m per hop | 250 kbit/s | Years for end devices | Lighting and building sensors |
| Thread, with Matter | 2.4 GHz, IEEE 802.15.4 | 10 to 100 m per hop | 250 kbit/s | Years for sleepy devices | Smart building devices on IPv6 |
| LoRaWAN | 868 MHz in the UK and EU | A few km in towns, more in open country | About 0.25 to 5.5 kbit/s | Up to 10 years | Meters, tank levels, environment |
| NB-IoT | Licensed LTE | Wide area, deep indoors | Tens of kbit/s | Up to 10 years | Static meters and sensors |
| LTE-M | Licensed LTE | Wide area, with movement | Up to about 1 Mbit/s | Years | Trackers, alarms, voice |
| 5G RedCap | Licensed 5G | Wide area | Around 150 Mbit/s down | Rechargeable or mains | Wearables, industrial sensors, video |
| Ethernet and PoE | Copper | Up to 100 m | Up to 10 Gbit/s | Up to 90 W over the cable | Cameras, access points, controllers |
| RS-485 | Copper bus | Up to about 1,200 m | Around 100 kbit/s at full length | Mains | Older plant and building controllers |
Figures are indicative and vary with the environment, the antennas and the settings. Private 5G for whole sites is covered on the wireless page.
MQTT and CoAP
Publish once, deliver to every subscriber
MQTT is the default language of IoT. Devices publish to topics on a broker over TCP (transmission control protocol), and any number of systems subscribe. Nothing connects into the device, which is exactly what a secure design wants. It runs on TCP 1883, or 8883 with TLS (transport layer security), which is the only port I allow. Each message carries a QoS (quality of service) level. How MQTT carries plant data with Sparkplug B and a Unified Namespace is on the operational technology page.
Swipe sideways to see the whole diagram.
QoS 0, at most once. One PUBLISH and no reply. I use it for frequent samples, such as a temperature every few seconds, where the next reading replaces a lost one.
QoS 1, at least once. The broker replies with PUBACK. If the reply is lost, the publisher sends again with the duplicate flag set. I use it for events and commands, and make sure the receiver can handle a duplicate.
QoS 2, exactly once. Four messages make sure the message arrives once and only once. It costs two round trips, so I keep it for the rare case where a duplicate would do harm, such as a count that drives billing.
QoS applies to each hop. A subscriber receives at the lower of the publish level and its own subscription level. Queued delivery to a sleeping subscriber needs a persistent session: clean start off, and in MQTT 5 a session expiry long enough to cover the sleep.
Swipe sideways to see the whole diagram.
The gateway connects and registers a Last Will: a message the broker will publish for it if it vanishes. It then publishes its status as online, marked retained, so any new subscriber gets the current state at once.
When there is nothing to send, the gateway pings the broker within the keep alive period, here 60 seconds. I set keep alive below the shortest idle timeout of any firewall or NAT (network address translation) device in the path.
The gateway loses power. It cannot send a clean disconnect, so as far as TCP is concerned the connection just goes quiet.
If the broker hears nothing for one and a half times the keep alive period, here 90 seconds, it treats the client as gone.
The broker publishes the will on the status topic. The dashboard shows the gateway offline, and because the message is retained, so does every system that subscribes later.
A gateway client in Python
import paho.mqtt.client as mqtt
def on_connect(client, userdata, flags, reason_code, properties):
client.publish("site/leeds/gw1/status", '{"online": true}', qos=1, retain=True)
client.subscribe("site/leeds/gw1/cmd/#", qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id="leeds-gw1", protocol=mqtt.MQTTv5)
client.tls_set(ca_certs="ca.pem", certfile="gw1.crt", keyfile="gw1.key")
client.will_set("site/leeds/gw1/status", '{"online": false}', qos=1, retain=True)
client.on_connect = on_connect
client.connect("broker.example.net", 8883, keepalive=60)
client.loop_forever()Mutual TLS with a device certificate, a retained status, a Last Will and a unique client ID. Two devices sharing a client ID knock each other off the broker in a loop. Eclipse Paho offers the same calls in C for firmware and in Java for back end services.
Topic filter tester
A plus sign matches one level. A hash matches every level below, and must come last.
| Filter | Topic | Match |
|---|---|---|
site/+/line1/# | site/leeds/line1/press3/temp | Yes |
site/+/temp | site/leeds/line1/temp | No: plus is one level |
site/# | site | Yes: hash includes the parent |
# | $SYS/broker/clients | No: topics starting with $ are left out |
CoAP, for the smallest devices
CoAP (Constrained Application Protocol), defined in RFC (Request for Comments) 7252, works like a tiny web: GET, PUT, POST and DELETE on resources, carried over UDP (user datagram protocol) 5683, or 5684 with DTLS (TLS for datagrams). It suits very small devices on lossy links, such as a Thread mesh, and is the basis of LwM2M (Lightweight Machine to Machine) device management.
Swipe sideways to see the whole diagram.
Confirmable (CON). The client resends the request until the server sends an ACK (acknowledgement), matched by message ID. The answer often rides inside the acknowledgement, so one round trip does the job.
Non confirmable (NON). No acknowledgement at all. It is the lightest option, for readings where the next one will follow soon.
Observe (RFC 7641). The client registers once and the server sends a notification each time the value changes. It gives CoAP a simple subscription, without a broker in the middle.
| MQTT | CoAP | |
|---|---|---|
| Model | Publish and subscribe through a broker | Request and response, like a small web |
| Transport | TCP 1883, or 8883 with TLS | UDP 5683, or 5684 with DTLS |
| Reliability | QoS 0, 1 and 2 | Confirmable or non confirmable messages |
| Best for | Many consumers of the same data, events and commands | Very small devices, lossy links, Thread meshes |
| Watch out for | Keep alive against firewall timeouts, duplicate client IDs | NAT timeouts on UDP, payloads larger than one datagram |
Onboarding
Letting a device in only as far as it needs
Most sensors and cameras cannot do 802.1X (port based network access control). So the switch falls back to MAB (MAC authentication bypass), and the policy server, Cisco ISE (Identity Services Engine) in this example, works out what the device is before deciding where it may go. Unknown devices are quarantined, never trusted by default.
Swipe sideways to see the whole diagram.
The sensor is plugged in. The port starts in closed mode, so nothing passes until the device is authorised.
The switch sends EAPOL (EAP over LAN) identity requests. A device with a certificate would answer and use EAP-TLS. Most sensors stay silent, so after a timeout I tune for each port type, the switch moves on.
The switch sends the device's MAC address to ISE in a RADIUS (remote authentication dial in user service) request. A MAC address is easy to copy, so it is only the starting point, never proof of identity on its own.
ISE profiles the device from clues such as its DHCP (dynamic host configuration protocol) fingerprint, LLDP (link layer discovery protocol) and the maker part of its MAC address (the OUI, organisationally unique identifier). It then places the device in an endpoint group: environment sensor.
ISE returns a segment and a security group tag (SGT). The matrix of security group access control lists (SGACLs) then allows the sensor to reach the MQTT broker on TCP 8883, plus DHCP, DNS (domain name system) and NTP (network time protocol), and denies everything else.
A device that matches no profile goes to quarantine: DHCP and DNS only, and an alert to the team. Once it is identified, a change of authorisation (CoA) moves it to its proper group without unplugging it.
One policy matrix, default deny
| From \ to | Broker and gateways | Building systems | Camera recorders | Plant (OT) | Corporate | Internet |
|---|---|---|---|---|---|---|
| Building sensors | TCP 8883 | Deny | Deny | Deny | Deny | Deny |
| Building controllers | TCP 8883 | BACnet, same group | Deny | Deny | Deny | Deny |
| Cameras | Deny | Deny | RTSP (real time streaming protocol) to the recorder | Deny | Deny | Deny |
| IoT gateways | Broker cluster | Field protocols | Deny | Deny | Deny | Cloud on 8883 and 443 |
| Corporate users | Dashboards on 443 | Deny | Viewing client | Deny | n/a | Through the proxy |
Every group may also reach DHCP, DNS and NTP. Tags describe what a device is, not where it sits, so a sensor keeps the same rules on any floor. The policy is enforced on the way out, at the switch nearest the destination.
Swipe sideways to see the whole diagram.
Phase 1, monitor mode. Every device is checked but nothing is blocked. For a few weeks ISE records which devices would have failed, so I can fix profiles and allow lists from real evidence before anything breaks.
Phase 2, low impact. Before authorisation a pre authentication access list lets only DHCP and DNS through. Devices still get an address and boot normally, while everything else waits for a result.
Phase 3, closed mode. Nothing passes until the device is authorised, then only what the policy allows. I move one device class and one site at a time, with a rollback ready.
What breaks when segmentation is too tight
Discovery that relies on broadcast or multicast, such as mDNS (multicast DNS), SSDP (simple service discovery protocol) and BACnet Who-Is, stops across segments. Peer to peer devices go silent, cloud managed devices lose their outbound HTTPS (secure web traffic), and a forgotten NTP rule makes every certificate fail. I capture each class's real flows in monitor mode first.
Wireless devices, same rules
IoT devices on Wi-Fi get the same segments and tags as wired ones. I use a key per device class instead of one shared password, WPA3 (Wi-Fi Protected Access 3) where devices support it, and EAP-TLS for anything with a certificate.
Containing a misbehaving device
IoT segments are quiet, so unexpected traffic stands out. A firewall, the SIEM (security information and event management) or analytics can ask ISE to quarantine the device automatically through pxGrid and a change of authorisation.
Device security
Every device needs its own identity
A shared password across ten thousand devices is one breach waiting to happen. I give each device its own certificate from a PKI (public key infrastructure), issued automatically and renewed before it expires. The same identity then opens three doors: the network, the broker and management.
Swipe sideways to see the whole diagram.
Better devices ship with an IDevID (initial device identifier): a certificate the maker installs in a secure element, defined in IEEE 802.1AR. It proves the make, model and serial number, but it is not the identity I run the network on.
The device sets its clock from NTP before anything else. Without the right time every certificate looks not yet valid, which is the most common reason a new device fails to connect.
The device uses its factory certificate to ask for an operational certificate, an LDevID (locally significant device identifier), through EST (Enrollment over Secure Transport). The issuing CA (certificate authority) serves devices only and sits under an offline root. The private key never leaves the secure element.
The same certificate opens three doors: EAP-TLS to join the network, mutual TLS to the broker, and secure management over SSH (secure shell) or HTTPS. Devices without a factory identity get a one time bootstrap instead, such as AWS fleet provisioning or Azure DPS (Device Provisioning Service).
Certificates renew automatically well before they expire, and I monitor expiry across the fleet. A stolen or retired device is revoked in one place and loses all three doors at once.
UK law sets the floor
Since 29 April 2024 the UK PSTI regime (Product Security and Telecommunications Infrastructure) bans universal default passwords on consumer connectable products, requires a way to report vulnerabilities, and requires the minimum security support period to be published. Its rules come from ETSI (European Telecommunications Standards Institute) EN 303 645.
Standards I design to
ETSI EN 303 645 for the device baseline, NIST (National Institute of Standards and Technology) IR 8259 for what a manufacturer should provide, and IEC (International Electrotechnical Commission) 62443 zones and conduits where devices sit in a plant. Enterprise buyers can ask for the same baseline in their contracts.
On the device itself
A hardware root of trust, secure boot with signed firmware, encrypted key storage, debug ports disabled in production, and only the services the device needs. I check these at procurement, because they cannot be added later.
Common attacks, and the control that stops each
| Attack | What I put in place |
|---|---|
| Default passwords and botnets, such as Mirai | No default credentials, nothing reachable from the internet, outbound allow lists, automatic quarantine. |
| Moving sideways from one device | Default deny between groups, no path to corporate networks, a separate management plane. |
| A rogue device on a spare port | 802.1X or MAB with profiling, unknown devices to quarantine, port security on edge switches. |
| Interception in the middle | Mutual TLS, WPA3 on Wi-Fi, encrypted OPC UA (Open Platform Communications Unified Architecture), no plain Modbus outside its cell. |
| Malicious firmware | Secure boot, signed updates and staged rollouts with automatic stop. |
Firmware
Updating ten thousand devices without bricking one
Over the air updates are how a fleet stays secure for its whole life. They are also the fastest way to break every device at once. I design them with signing, two firmware slots, health checks and a staged rollout that stops itself.
Swipe sideways to see the whole diagram.
The build pipeline signs each firmware image with a key held in an HSM (hardware security module). The device's bootloader checks the signature, so a tampered image never runs.
About 1 percent of devices, chosen across sites and hardware versions, get the update first. Each writes it to its spare slot, keeping the running version untouched, then reboots into the new one.
Each device checks itself before it marks the new version good: it reconnects, reports, and keeps its bandwidth steady. The fleet only moves on if enough canaries pass.
The update then reaches 10 percent, then everyone, through AWS IoT Jobs, Azure Device Update or a controlled HTTPS source. The rollout stops itself if failures pass a threshold, such as 2 percent, and the network policy allows the update path explicitly.
A device that fails its health check boots its old slot again on its own. Nobody needs to visit it, which matters when it sits on a roof or a pipeline.
I also watch bandwidth during a rollout. A new release that reports ten times more often can fill a WAN or a cellular data plan, so a bandwidth limit is part of the health gate. LoRaWAN and NB-IoT devices need much smaller, slower updates, often as differences only.
Cloud platforms
AWS IoT Core and Azure IoT Hub, side by side
Both platforms give a managed broker, a registry, per device identity and a way to hold each device's state. They differ in names and in detail. I connect sites to them privately where I can, with each gateway allowed only its own topics.
Swipe sideways to see the whole diagram.
The building app asks for 21 degrees by writing the desired state into the device's shadow (AWS) or twin (Azure). It does not need the thermostat to be online.
The cloud compares desired with the last reported state, 19 degrees, and publishes the difference on the device's delta topic. A sleepy device receives it the next time it connects.
The thermostat applies the new setpoint and reports its state back. The shadow now shows what the device is really doing, not just what was asked for.
Desired and reported match, so there is no delta. Applications read the shadow instead of waking the device, which saves its battery.
The two platforms compared
| AWS IoT | Azure IoT | |
|---|---|---|
| Gateway and broker | AWS IoT Core | Azure IoT Hub |
| Device identity | X.509 certificates and IoT policies | X.509, symmetric keys or TPM (trusted platform module) |
| Zero touch first boot | Fleet provisioning and just in time provisioning | Device Provisioning Service (DPS) |
| Device state | Device Shadow | Device twin, plus direct methods |
| Edge runtime | AWS IoT Greengrass | Azure IoT Edge, and Azure IoT Operations on Azure Arc |
| Routing data on | Rules engine, SQL (structured query language) on topics | Message routing |
| Fleet updates | AWS IoT Jobs | Device Update for IoT Hub |
| Protocols and ports | MQTT on 8883 with mutual TLS, MQTT over WebSockets on 443, HTTPS | MQTT on 8883, AMQP (Advanced Message Queuing Protocol) on 5671, HTTPS, and WebSockets on 443 |
| Message size limit | 128 KB (kilobytes) | 256 KB per device to cloud message |
Services retire
AWS IoT Analytics reached end of support on 15 December 2025, and AWS IoT Events on 20 May 2026. Microsoft has announced that Azure IoT Central retires on 20 September 2029, pointing customers to IoT Hub, DPS and Azure Device Registry. AWS and Azure publish retirement notices months ahead, so I track them in the service end of life register. I design around the core services and keep an exit plan for the rest.
Private paths to the cloud
Gateways reach the platform through a private endpoint, over Direct Connect, ExpressRoute or an SD-WAN (software defined WAN) cloud on ramp, with private DNS so the endpoint resolves inside the network. Only gateways may reach the cloud, and only on 8883 and 443.
Least privilege topics
Policy variables tie each certificate to its own topics, so a device can publish only as itself. A publish the policy does not allow is not delivered. AWS IoT Core drops the connection, so the device shows as a reconnect loop. My designs log denials in AWSIotLogsV2 and test with a known message after every change.
Edge or cloud
Deciding where the data is processed
Send everything to the cloud and the WAN fills up, alarms wait on a round trip, and an outage stops the site. Process at the edge and the site keeps working on its own. Most of my designs do both. Compare the three cases below.
Swipe sideways to see the whole diagram.
Send everything. 500 sensors at 20 readings a second is 10,000 messages a second over the WAN, most of them unchanged values. The alarm decision waits for a round trip to the cloud, and the bill grows with every message.
Process at the edge. The gateway filters, aggregates and sends only changes and summaries, about 200 a second in this example. Alarms and safety interlocks are decided on site within milliseconds. The cloud does fleet analytics, long term storage and model training.
WAN down. Local rules keep running, so the alarm still works. The gateway buffers data and sends it in order when the link returns, so nothing is lost while the buffer lasts. I size the buffer to the longest outage the business will accept.
Figures are indicative.
| Process at the edge when | Process in the cloud when |
|---|---|
| Latency matters: control loops, safety and local alarms. | You need fleet wide analytics across every site. |
| The WAN is slow, costly or unreliable. | Machine learning models need training on large history. |
| Volume is high but most readings do not change. | Data must be kept for years or joined with business data. |
| Data must stay on site, for privacy or contract reasons. | Demand rises and falls, and elastic scale saves money. |
Buildings
CCTV, doors and building systems, kept apart
CCTV (closed circuit television) cameras, door controllers and building management systems (BMS) are not "more devices on the network". Each is its own security domain, with its own segment, its own head end and a named owner. They share the switches, but never the trust. Building management in the data centre is covered on the data centre facilities page, and the plant side on the operational technology page.
Swipe sideways to see the whole diagram.
CCTV. Cameras sit in their own segment and may reach only the VMS (video management system) and the NVR (network video recorder). Pan, tilt and zoom (PTZ) cameras may need PoE++ (IEEE 802.3bt). Many enterprise cameras support 802.1X with EAP-TLS, and the rest use MAB with profiling.
Access control. Door controllers talk only to their head end server. They hold card data locally, so doors keep working if the network fails, and the switches that feed them sit on UPS (uninterruptible power supply).
Building management. Field devices connect over RS-485 or hard wired inputs to controllers, which speak BACnet/IP or Modbus to a head end. BACnet discovery uses broadcast, so it needs a BBMD (BACnet broadcast management device) or one shared segment. A gateway can expose the data as MQTT for analytics.
CCTV bandwidth and storage
40 cameras at 4 Mbit/s need about 160 Mbit/s into the recorder, and about 51.8 TB (terabytes) of storage to keep 30 days of 24 hour recording.
Storage is cameras × bit rate × seconds recorded ÷ 8. I add headroom for motion, night time noise and RAID (redundant array of independent disks), which can raise the real need by a third or more.
Power over Ethernet budgets
| Standard | At the switch | At the device |
|---|---|---|
| 802.3af, PoE | 15.4 W | 12.95 W |
| 802.3at, PoE+ | 30 W | 25.5 W |
| 802.3bt Type 3 | 60 W | 51 W |
| 802.3bt Type 4 | 90 W | 71.3 W |
I add up the real draw of every device on a switch, leave headroom, and put the closets that feed security and building systems on UPS.
Troubleshooting
"The device doesn't work": a seven step walk
I check IoT faults in a fixed order: power, radio or link, identity, IP address, path, TLS, then the application. Most "network" faults on a device show up first as a TLS error on its serial console. Pick a symptom to see where it usually sits.
Swipe sideways to see the whole diagram.
- Likely causes
- No matching authorisation rule or profile, a segment or VLAN (virtual LAN) that does not exist on this switch, a missing DHCP relay or no route back from the DHCP server.
- Fix
- Fix the profile or rule in ISE, add the segment, then send a change of authorisation.
- Prevent
- Check port templates and pools during onboarding, and keep this order in the runbook.
- Likely causes
- A deny in the policy matrix between the two groups, a missing route or firewall rule at the border, or an MTU (maximum transmission unit) problem where small packets pass and large ones fail.
- Fix
- Correct the matrix cell or the border rule, or fix the link with the wrong MTU.
- Prevent
- An MTU check in every fabric acceptance test, and policy changes tested in monitor mode first.
- Likely causes
- A keep alive longer than a firewall or NAT idle timeout, two devices sharing a client ID, an aggressive reauthentication timer, Wi-Fi roaming, or PoE shedding ports under load.
- Fix
- Set keep alive below the shortest idle timeout, often 60 seconds, and make client IDs unique from serial numbers.
- Prevent
- A duplicate client ID check in the runbook, and IoT segments left out of aggressive reauthentication.
- Likely causes
- New firmware or a new hardware revision changed the DHCP fingerprint or MAC maker code, so the old profile no longer matches and the cameras fall to quarantine.
- Fix
- Update the profiling policy, or load the MAC addresses from the delivery note, then send a change of authorisation.
- Prevent
- Test one device from each new batch on a lab port, and move the camera class to EAP-TLS.
- Likely causes
- No NTP, so the clock reads 1970 and every certificate is not yet valid; an expired certificate or missing intermediate; a cipher the broker has disabled; a hostname mismatch; or an MTU problem on the first large packet.
- Fix
- Allow NTP first, always, then fix the certificate chain or the cipher list.
- Prevent
- Fleet wide certificate expiry monitoring and an MTU check in acceptance.
- Likely causes
- BACnet discovery is broadcast, and the controllers moved into segments that do not flood broadcast.
- Fix
- A BBMD on each subnet, or the controllers and head end in one segment with flooding enabled. In time, BACnet Secure Connect.
- Prevent
- A "needs broadcast or multicast" column for each device class in the onboarding standard.
- Likely causes
- No chain of mains powered routers in range, fire doors or metal ceilings breaking the chain, or the mesh channel overlapping busy Wi-Fi channels.
- Fix
- Add a router or a second border router in the far wing, and move the mesh to a channel between the Wi-Fi channels in use.
- Prevent
- Plan mesh routers like access points, from a survey.
- Likely causes
- The device may connect but not publish to that topic, the rule does not match the topic sent, the rule's action fails, or the message is over the size limit.
- Fix
- Align the policy and rule with the real topic tree, and fix the action's permissions.
- Prevent
- An end to end test client that publishes a known message after every change, and alarms on rule errors.
- Likely causes
- Existing sessions stayed up, but every new device and every port that reauthenticated failed, so IoT ports went dark one by one.
- Fix
- Restore the policy service, then handle the surge of reconnections.
- Prevent
- Two policy nodes per region, dead server detection, critical authorisation that fails ports into a known safe state, and long enough reauthentication timers.
My general method, with worked faults, is on the troubleshooting page. Terms used here are spelled out in the glossary.
Engagement
How I deliver an IoT programme, from first survey to steady state
IoT projects tend to fail on the basics: devices nobody owns, networks that trust anything plugged in, and certificates that expire on a Sunday. I start with the people who own the devices and the risks, find what is already connected, then design onboarding, segments and support before I scale.
Swipe sideways to see the whole diagram.
I start with the outcome, such as lower energy bills, fewer site visits or safer plant, and who will own each kind of device. Facilities, OT and security join from day one, because every sensor is a new door into the network and someone must patch it for years.
Functional requirements say which devices connect, what data they send, where it goes and which commands come back. Non functional ones set numbers for fleet size, message rates, latency for alarms, battery life, how long a site runs offline, and the security baseline every device must meet.
I find out what is already connected, because there is always more than anyone thinks. Passive discovery tools and switch data give a device inventory, protocol maps show who talks to whom, and a radio survey checks coverage. Every device gets an owner, or a plan to remove it.
The design covers how each device type joins the network, the segment and policy it lands in, and how certificates are issued and renewed. It also covers firmware updates, and what runs at the edge and what runs in the cloud. The design authority reviews it, and security signs off the policy matrix.
I pilot one device type at one site, with policy in monitor mode first so nothing breaks. Once the profiles are proven and the logs are clean, I move to low impact and then closed mode, and roll out site by site in waves with a tested rollback.
Support needs to know who owns each device and how to reach its vendor. I set up monitoring for devices that go silent, broker connections, certificate expiry and failed updates, with runbooks for the common faults, so the service desk can fix most issues without an engineer.
A sensor may run for ten years, longer than the cloud service it reports to. I keep a firmware calendar, renew certificates before they expire, watch for platform retirements such as AWS IoT Analytics, and wipe and revoke devices when they leave service.
Functional requirements
What it must do.
- Onboard each device type with the strongest method it supports: 802.1X with certificates first, and MAB with profiling where it cannot.
- Place every device in a segment that allows only the flows it needs, and deny the rest.
- Carry device data to the broker and on to the platform, with commands and updates coming back.
- Keep local alarms and control working on site when the WAN or the cloud is down.
- Update firmware in signed, staged waves, with a way back.
- Quarantine unknown or misbehaving devices, and alert their owner.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Scale
- Thousands of devices per site and tens of thousands across the estate, with room to grow.
- Latency
- Local alarms decided on site in under a second, and dashboards updated within a few seconds.
- Resilience
- A site runs on its own through a WAN outage and buffers data for the agreed time, such as 24 hours.
- Security
- A unique identity per device, mutual TLS, no default passwords, and a baseline aligned to ETSI EN 303 645.
- Battery life
- Battery devices meet their target life, such as five years, with the chosen radio and reporting rate.
- Manageability
- Every device has an owner, a firmware version on record and an alert when it goes silent.
- Compliance
- Consumer products meet the UK PSTI rules, and camera footage follows UK data protection law.
These are typical starting targets. Battery life and message rates depend on the radio and the device, so each one is proven at the pilot site before rollout.
Who I talk to
- Facilities, estates and building managers
- OT and engineering teams who own plant and controllers
- Security, risk and data protection
- Data and analytics teams who use the readings
- Device vendors, installers and integrators
How I find out
- Passive discovery from mirrored switch ports and from ISE in monitor mode
- Walking the site with the people who installed the devices
- Radio surveys for Wi-Fi, BLE and LoRaWAN coverage and interference
- Reading broker and platform logs to see who already connects
- Workshops to agree the segments and the policy matrix
Discovery tools
| Tool or source | What it tells me |
|---|---|
| Cisco Cyber Vision | Passive asset discovery and protocol maps for OT and IoT devices. |
| Claroty or Nozomi Networks Guardian | Device inventory, known vulnerabilities and unusual traffic, with no agents. |
| Microsoft Defender for IoT | Passive discovery and alerts, linked to the wider Microsoft security tools. |
| Cisco ISE in monitor mode | Who and what connects to each port, with profiling, before anything is blocked. |
| Ekahau survey tools | Wi-Fi and BLE coverage, interference and capacity, before and after installs. |
| Broker logs and dashboards | Which client IDs connect, from where, how often they drop and which topics they use. |
I troubleshoot IoT in layers, from the radio or cable up to the message. Most faults sit at the edges: onboarding, certificates, time and firewall timeouts.
My approach
- Define the scope. One device, one model, one site or every site? The pattern points at the cause quickly.
- Check the link. Is the device powered, associated or linked, and does it hold an address?
- Check onboarding. Did 802.1X or MAB pass, which profile matched, and which segment and tag did it get?
- Check the path. Can it reach the broker or gateway through the policy and the firewalls?
- Check the session. Does TLS complete, is the clock right, and does the broker accept the client ID and topics?
- Fix and prevent. Fix the cause, then add a profile, alert or test so the next batch is caught first.
Faults I see most
- Wrong clocks, so valid certificates look expired or not yet valid
- Two devices sharing a client ID and knocking each other off the broker
- Firewall idle timeouts shorter than the MQTT keep alive
- A new firmware or model that no longer matches the profiling policy
- Broadcast or multicast discovery that stops at a routed boundary
- Mesh networks with too few mains powered routers
Layer by layer
| Layer | What I check |
|---|---|
| 1 · Physical | Power and PoE budget, cabling, radio signal and interference. |
| 2 · Data link | 802.1X and MAB results with show authentication sessions, VLANs and wireless association. |
| 3 · Network | Addressing, routes and policy, with group tag counters from show cts role-based counters. |
| 4 · Transport | TCP 8883 and UDP 5683 through firewalls, idle timeouts, and TLS checked with openssl s_client. |
| 5 to 7 · Application | Client IDs, topics and access rules on the broker, checked with mosquitto_sub and the broker logs. |
My general method, with worked faults, is on the troubleshooting page.
An IoT fleet is a service in its own right. I set it up so the right team gets the right alert, and every device has someone to call.
Ownership
Every device type has a business owner, a technical owner and a vendor contact on record.
Monitoring
Alerts for devices that go silent, broker connection storms, failed updates and certificates near expiry.
Runbooks
Short guides for onboarding, replacing a device, quarantine and release, and common radio faults.
Spares
Spares enrolled in advance and kept on site, and a swap process that revokes the old certificate.
Change control
Firmware waves and policy changes go through change, with a pilot group first.
Problem management
Repeat faults by model or site are traced to a cause and fixed at the source.
Devices stay in the field for years, so I plan their whole life from the day they are bought.
- Buy. Security goes into procurement: unique passwords, a published update period and a way to report flaws.
- Enrol. Each device gets its own identity and certificate as it joins, never a shared secret.
- Update. Signed firmware in staged waves, on a calendar agreed with each owner.
- Renew. Certificates renew automatically well before expiry, with an alert if renewal fails.
- Watch. Vendor support periods and cloud platform retirements are tracked, with time to move.
- Retire. Devices are wiped, their certificates revoked and their records closed when they leave service.
Projects
Where I have built it
My IoT work has grown out of plant, building and data centre programmes, where devices, gateways and brokers have to sit safely alongside business networks.
MQTT and edge gateway architecture
Designed MQTT broker architecture and edge gateways for smart building and industrial use cases, with topics structured as a Unified Namespace (UNS) and OT to IT (information technology) segmentation.
Secure data paths for Dyson
Supported IT and OT convergence across Dyson's global manufacturing sites: industrial network segmentation, OT security controls and secure MQTT data paths from production lines to MES and cloud data platforms.
Telemetry under SCADA
Supported OT and IT convergence across manufacturing sites. That covered OPC DA and OPC UA links from PLC (programmable logic controller) layers. Modbus TCP and MQTT telemetry ran under SCADA (supervisory control and data acquisition) and HMI (human machine interface) platforms, zoned to feed MES and MOM (manufacturing operations management) systems.
Building automation and sensors
LAN, WAN and cloud for multi site real estate and construction, with BACnet/IP building automation and IoT sensor networks.
Buildings, CCTV and AV
I have completed the Hikvision CCTV Expert course, and Kramer Academy courses in AV (audio visual) over IP and control system design. I have also trained in Honeywell and Control4 building automation, BMS, HVAC (heating, ventilation and air conditioning), and power and electrical systems.
The building and CCTV work above is backed by my BMS, HVAC, Honeywell, Control4, Hikvision and Kramer training. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.