When people talk about the Internet of Things, they tend to talk about the things. A sensor reads a temperature. A camera spots a vehicle. A tracker shows a location. A smart meter sends a reading. A dashboard turns it all into something useful. That is the visible part of IoT, and it is also the smallest part.
Underneath that seemingly simple transaction sits connectivity, SIM management, device provisioning, firmware, security, certificates, APIs, monitoring, network selection, resilience, cloud infrastructure, data management, lifecycle planning and, ultimately, the people responsible for keeping the whole thing working. Which makes an iceberg a surprisingly good way to understand modern IoT. The interesting question is not what the device does. It is what has to happen beneath the surface for that device to keep doing it, securely and reliably, for the next five, ten or fifteen years.
What everyone sees: the tip of the iceberg
Above the waterline are the parts normally used to demonstrate, market and justify an IoT project: smart devices, dashboards, cloud services and, increasingly, AI. The devices themselves span sensors, cameras, trackers, smart meters, industrial controllers, EV chargers, digital signage, remote telemetry units and connected vehicles. Because they are physical, they attract a disproportionate amount of attention, yet the device is often one of the easiest parts of the system to understand.
The dashboard is the attractive bit. Maps, graphs, alerts, green and red status dots, remote controls, reports. A customer sees 500 devices as 500 dots on a map and it can look remarkably simple. But those dots do not appear by magic. Each one represents a chain of technologies that has to carry data from a physical device somewhere in the real world into the application displaying it.
AI is adding another visible layer. Instead of simply collecting information, systems increasingly interpret it: a camera identifies a vehicle rather than just producing video; a vibration sensor flags a bearing that may be failing rather than just reporting movement. That makes IoT far more useful, and it makes what happens beneath the waterline far more important, because AI cannot compensate for unreliable source data, intermittent communications, unidentified devices or badly managed infrastructure. Intelligence at the top of the iceberg still depends on engineering underneath it.
The operational layer: what teams actually run
Now we go underwater. This is where a deployment becomes a system, and where many projects discover that connecting the first ten devices was far easier than operating the next ten thousand.
Connectivity is a strategy, not a radio
Every connected device needs a way to communicate: Ethernet, Wi-Fi, 4G, 5G, LTE-M, NB-IoT, LoRaWAN, Wi-Fi HaLow, private cellular, satellite or NTN, or a combination of several. But choosing “4G” is not a connectivity strategy. Which network? What happens when it is not available? Is roaming permitted? Is network steering being used? Does the application need a private APN or inbound connectivity? Is CGNAT acceptable? What happens when the mobile network operator changes something, or when 4G eventually reaches end of life? The radio technology is only the beginning, and newer options such as 5G RedCap and 5G FWA widen the choice rather than simplify it.
SIM and eSIM management
For cellular IoT, another substantial layer sits beneath the modem. Traditional SIMs raised questions of activation, tariffs, roaming and replacement. Multi-network IoT SIMs added options. Dual-SIM hardware added resilience. eUICC and eSIM introduced remote profile management, and SGP.32 is now creating another generation of IoT connectivity architecture. But none of this automatically creates resilience. Putting an eSIM into a device does not make the application reliable. Someone still has to decide which profiles are available, when they should change, how a connectivity failure is detected and what should happen when something goes wrong.
Connectivity technology provides capability. Architecture decides whether that capability actually delivers resilience.
Provisioning and remote management
A prototype can be configured by hand. A fleet of 10,000 devices cannot. Devices may need unique identities, network configuration, APNs, certificates, encryption keys, application settings, firmware versions, security policies and cloud credentials. That raises a question proof-of-concept deployments tend to ignore: how do we turn an unconfigured device in a box into a trusted member of a production system, and just as importantly, how do we remove it again?
Once devices leave the warehouse they do not stop being your infrastructure. A router may be bolted inside a CCTV cabinet 250 miles away, a gateway inside a wind turbine, a controller behind a locked door in a retail store. Physical access suddenly becomes expensive, so remote management becomes part of the commercial model rather than a convenience. Can you remotely check connectivity, view signal, change an APN, restart the modem, switch network, update firmware, modify firewall rules, retrieve logs, roll back a configuration and diagnose the equipment behind the router? The difference between diagnosing something remotely and sending an engineer to site can decide whether a large deployment stays commercially viable.
Updates, telemetry and security
IoT devices are not static appliances. They contain software, and software has vulnerabilities, bugs and dependencies. NIST’s IoT cybersecurity baseline treats secure software updating as a core device capability, alongside device identification, configuration, data protection, interface access control and cybersecurity-state awareness. A serious deployment therefore needs to know what firmware is installed, which devices need updating, whether updates can be applied remotely and authenticated, what happens if one fails halfway through, whether it can be rolled back, and what happens when the manufacturer stops shipping updates. The shiny sensor installed today can become tomorrow’s unsupported Linux computer attached to your network.
Knowing what a device reports is not the same as knowing whether the system is healthy. A temperature sensor might send “7.4 C”, which is useful, but operationally you may also want signal strength, network registration, data consumption, firmware version, connection uptime, packet loss, reconnection frequency, last reboot and authentication failures. At that point you are no longer monitoring the thing being measured; you are monitoring the system doing the measuring, and that distinction matters more as estates grow.
Security runs through almost every layer of the iceberg rather than sitting beside it. The GSMA treats IoT security as an end-to-end problem across endpoints, networks and service ecosystems. Securing the cloud application while leaving a router exposed to the public internet is not security. Encrypting communications while every device shares the same admin password is not security. At sufficient scale, device identity becomes as important as user identity: is this genuinely device 002873, is it authorised, has its certificate expired, has it been replaced, and can an installer reach every customer’s equipment or only their own? This is where certificates, secure elements and SIM-based security matter. The GSMA’s IoT SAFE approach, for example, uses the SIM or eSIM as a hardware root of trust for device-to-cloud authentication, so the SIM becomes part of the security architecture rather than just a subscription.
Incident response, resilience and integration
Something will eventually go wrong. That is engineering, not pessimism. Imagine 500 remote CCTV installations and one stops communicating. Why? It could be a network outage, a SIM problem, an exhausted data allowance, poor signal, a router failure, power loss, antenna damage, a firmware crash, a firewall change, a DNS or VPN failure, or a cyberattack. From the dashboard they all look identical: device offline. The hidden infrastructure is what determines how quickly you can tell which one it actually is.
Resilience can exist at several levels: dual SIMs, a SIM with access to multiple networks, an eSIM holding multiple operator profiles, 5G with Ethernet WAN failover, cellular combined with satellite, local data buffering, edge processing that keeps working while the cloud is unreachable. These are not interchangeable. A dual-network SIM does not protect against a failed modem; a dual-SIM router does not help if both SIMs ride the same underlying network; a second WAN does not help if the site loses power. Proper resilience starts by asking what exactly you are trying to survive, and only then designing the right redundancy. And a brilliant sensor on a brilliant network is not worth much if its data stays trapped in a proprietary dashboard, so APIs and integration into ERP, CRM, billing, analytics and asset systems are another submerged layer, as is the edge itself, which is increasingly part device, part infrastructure and part application platform.
The deep foundations: where sustainable IoT lives
Beneath the operational layer sits the part that rarely makes the sales brochure. Someone has to understand how everything fits together: what happens if a component fails, who owns the data, where credentials are stored, how you migrate network providers, what happens when hardware becomes obsolete and whether another supplier could support the architecture at all. A collection of good products does not automatically make a good system.
Security bolted on afterwards is almost always harder and more expensive, so the better question during design is how this system could be attacked, misconfigured or abused. That single question changes purchasing decisions, network architecture, credential handling, remote-access design, logging and firmware policy. It turns security into an engineering requirement rather than something the IT department is handed shortly before go-live.
IoT also creates ownership questions quickly. Who owns the router, the SIM and the data? Who is responsible for firmware, for monitoring vulnerabilities, for approving configuration changes, and for deciding whether a vulnerability justifies replacing 5,000 deployed devices? Technical capability without defined responsibility leaves gaps, and gaps are where problems live. Compliance stretches those questions across time: depending on application and geography you may face cybersecurity, privacy, radio-equipment, critical-infrastructure and sector rules, and it is not enough for a device to be compliant on the day you buy it. You may need to know it can stay supportable, updateable and secure across its whole life.
That life is the deepest part of the iceberg. A web application might be replaced next year; industrial equipment may stay deployed for ten, fifteen or twenty years. During that time mobile networks change, certificates expire, cloud platforms disappear, manufacturers are acquired, products reach end of life, vulnerabilities surface, contracts lapse and documentation goes missing. What looks like a simple deployment in 2026 could still be sitting in a cabinet in 2036. So every project should ask how it ends: how the device is decommissioned, how credentials are revoked, how the SIM is terminated, how hardware is securely reset and what replaces it. That is not an administrative afterthought. It is part of the architecture.
People: the part we forget
There is one more component beneath the waterline. People. Someone has to install the equipment, understand cellular networks, configure routers, investigate alarms, manage SIM contracts, monitor security, understand the application and keep the documentation current. And someone needs enough grasp of the whole system to spot when a problem in one layer is really being caused by another. That multidisciplinary requirement is one reason IoT is deceptively difficult: it sits across IT, networking, telecoms, electronics, software, cloud, operational technology and cybersecurity. Modern IoT is not really a single technology sector. It is where several sectors meet.
Why the iceberg matters when you buy
The model is a useful way to evaluate products and suppliers. Picture two devices that do exactly the same job. Above the waterline, the cheaper one wins. Below it, the picture changes.
| What you are buying | Device A | Device B |
|---|---|---|
| Price | £90 | £130 |
| Secure remote management | No | Yes |
| Signed firmware updates | No | Yes |
| Detailed telemetry | Limited | Yes |
| Certificate-based authentication | No | Yes |
| Automated provisioning | No | Yes |
| Software support | Uncertain | Ten years |
| API | No | Yes |
Suddenly the £40 difference is not really £40. The cheaper device can create far greater operational cost over its lifetime, which is how IoT procurement based purely on hardware price produces some spectacular false economies. The true unit of purchase is not the device. It is the lifecycle of the connected service.
The same trap catches SIM cards. A SIM at £1.20 a month looks cheaper than one at £1.80, until you ask what the dearer one adds: access to more networks, better monitoring, private addressing, APIs, VPN integration, eSIM profile management, and more useful support on the day 2,000 devices suddenly stop connecting. Price is visible above the waterline; operational value sits beneath it. That does not mean expensive is automatically better. It means the buyer needs to understand what problem each feature actually solves.
IoT is a system, not a product
That is perhaps the most useful lesson from the iceberg. IoT is sold as products: an IoT router, an IoT SIM, an IoT sensor, an IoT platform, an IoT eSIM. But successful deployments are not collections of products. They are systems, and systems depend on the relationships between their parts. The sensor depends on power. The modem depends on coverage. The router depends on its configuration. The SIM depends on network access. The VPN depends on connectivity. The application depends on data. The security system depends on identity. The maintenance team depends on monitoring. The business depends on all of them. The little green dot on the dashboard is simply the final result.
Look below the waterline
The next time someone demonstrates an IoT solution, do not just look at what it does. Ask what keeps it doing it. How is it connected, secured, monitored, updated and remotely managed? What happens when connectivity fails, or when the hardware fails? Who owns the service and who is responsible for security? Can you change suppliers, and how would you migrate it? What happens when one component reaches end of life, and how do you securely remove the device when its useful life is finally over?
Those questions are not the boring part of IoT. They are IoT. The sensor, the dashboard and the AI application are just the bit of the iceberg you can see. Everything underneath is what makes them work.
Sources: NIST IoT cybersecurity baseline (device identification, configuration, data protection, interface access control, secure software update and cybersecurity-state awareness); GSMA IoT security guidelines and the GSMA IoT SAFE specification.
