IoT Security: The Question That Stalls the Rollout
The Question That Stalls the Rollout
The pilot worked. The sensors report, the dashboards look good, and the budget is approved. Then the project lands on the desk of your IT security team, and the rollout stops dead on a single question: where do the encryption keys live, and who can read the data?
For a hospital putting sensors near patient areas, a property manager whose occupancy sensors generate personal data under GDPR, or a utility monitoring critical infrastructure, this is not a formality. Someone has to sign their name to a document stating the system is secure. If you cannot answer the key-custody question clearly, the project sits in review for months, exactly the kind of delay that kills otherwise-successful deployments.
The good news is that modern IoT protocols take security seriously and their guarantees are strong. The catch is that "it is encrypted" is the beginning of the answer, not the end. What earns sign-off is understanding what is protected, between which two points, and, above all, who holds the keys.
"Is it encrypted?" is the wrong question. Almost everything is encrypted in transit these days. The questions that matter are who holds the root keys, who can decrypt the application data, and where that data physically resides.
Encryption Is Not One Thing
Three different protections get called "encryption" in an IoT architecture, and conflating them is what produces a security document that does not survive a careful reader.
Transport encryption protects a link. TLS between a device and an MQTT broker, or the LTE ciphering between a cellular module and the carrier's core network, secures the data while it is on that hop and hands it over in the clear at the other end. It says nothing about what happens next.
Integrity and authenticity prove a message came from the device it claims to come from and was not altered in flight. This is what a message integrity code or a signature does, and it is the property that stops an attacker injecting fabricated readings into your billing data.
End-to-end confidentiality means the payload is encrypted with a key that only the device and the final application hold, so every intermediate hop, including whoever operates the network, carries data it cannot read. This is the strongest property and the rarest one, because it requires deliberate architecture rather than a checkbox.
Most deployments have the first two and believe they have the third. The distinction only becomes visible when you write down which party holds which key.
How the Layers Work in Practice
The specifics vary by technology, and the useful thing is to know what to look for in whichever one you are running.
On a cellular device, LTE ciphering protects the radio link to the carrier. Beyond that, security is whatever your application puts on top: TLS with a client certificate to your own broker or cloud endpoint is the normal answer, and the certificate has to be provisioned into the device somehow, which is the part that gets neglected. A cellular device with no application-layer TLS is a device whose data the carrier and every hop after it can read.
On an IP device speaking MQTT or HTTPS, TLS 1.2 or 1.3 with mutual authentication is the baseline. Mutual, not just server-side: without a client certificate or a per-device credential, anything that reaches the broker can pretend to be one of your sensors. Shared credentials across a fleet are the single most common failure here, because revoking one device then means reprovisioning all of them.
On a low-power radio network such as LoRaWAN, the protocol does more of this for you. AES-128 is mandatory rather than optional, and the specification separates a network layer that verifies integrity from an application layer that provides confidentiality, with different keys for each. That separation is the interesting property: the entity routing your traffic and the entity reading your data can be cryptographically distinct. Whether they actually are depends on your architecture, which is where the enterprise decisions begin.
Within such a network, one detail is worth checking on every project: how a device gets its session keys. Keys negotiated dynamically through a join handshake are fresh on every session, can be rotated by rejoining, and never travel in a provisioning spreadsheet. Keys hard-coded at manufacture are simpler and carry real risk, because they can be extracted from a captured device, and because a device that reboots and loses its frame counter can be pushed into reusing a keystream, which opens the door to replay attacks. Dynamic activation should be the default for anything in production, and static keys a last resort confined to an isolated environment. If a device only works with counter validation turned off, that is a misconfiguration to fix, not a setting to bypass.
The Real Security Boundary: Who Holds the Keys
Here is the part that determines whether your deployment is genuinely secure or merely encrypted, and it is an architectural decision, not a protocol feature.
The encryption is only as trustworthy as the custody of the keys. On a managed platform, your application keys are typically held by the platform provider. The data is encrypted in transit, yes, but it is decrypted on infrastructure you do not control, by a company whose security posture, breach history, jurisdiction and longevity you must now take on faith. "Your data is encrypted" is true and beside the point if a third party holds the key that decrypts it.
On self-hosted infrastructure, the root keys, the session keys and the decrypted application data never leave your environment. You can answer your security team's question with a sentence: the keys are generated and stored on our server, in our datacenter, and no external party can decrypt our data. That sentence is what passes a security review.
This is the ownership argument that runs through the rest of IoT architecture, applied to the angle a CISO cares about most. Self-hosting is not only about avoiding per-device fees. It is about being the sole custodian of your encryption keys. For regulated sectors, that distinction is the difference between a compliant deployment and a finding in the next audit.
Security Beyond the Radio Link
A complete security posture extends well past the device protocol. These are the areas an enterprise review will probe, and the ones a credible architecture must address.
Backhaul. The encrypted payload travels from a gateway or edge router to your server over the internet or a cellular link. That backhaul needs its own protection: field equipment on a dedicated VLAN behind a firewall, traffic restricted to the ingest server, and TLS on the connection. The device link being encrypted does not excuse an exposed backhaul, and a gateway on a desk port with a public IP is the finding that stops a rollout.
Server and infrastructure hardening. The ingest server, database and dashboards are conventional IT systems and must be secured as such: patched operating systems, TLS everywhere, role-based access control, encrypted backups, and a documented disaster-recovery plan. A self-hosted stack means you own this responsibility, which is precisely why the initial setup benefits from someone who has done it before.
Data classification and residency. What your sensors collect determines your obligations. Occupancy patterns in an office can constitute personal data under GDPR. Energy or water consumption per tenant has billing and privacy implications. Environmental readings near patients carry healthcare sensitivity. Classifying the data dictates retention policy, access control and, critically, where it may physically reside. Self-hosting on infrastructure in your own jurisdiction is the cleanest way to satisfy data-residency requirements.
Firmware and device lifecycle. Devices in the field occasionally need updates, and an update path is a security control, not a convenience: a fleet you cannot patch is a fleet that keeps whatever vulnerability it shipped with. Provisioning has to manage root keys and certificates securely rather than emailing them around in a spreadsheet, and decommissioning must revoke credentials so a discarded sensor cannot rejoin. At scale this is process and tooling, not an afterthought.
Monitoring for anomalies. A well-instrumented platform surfaces the signs of trouble: devices that suddenly change behaviour, unexpected join or connection attempts, counter anomalies that hint at replay attempts, a device reporting from an implausible location. You cannot respond to what you cannot see.
A Security Posture That Passes Review
For an organization deploying IoT in a regulated or data-sensitive setting, a defensible posture comes down to a handful of decisions made deliberately rather than by default:
- Give every device its own credential, provisioned securely and revocable on its own, and rotate on a schedule rather than never.
- Self-host the parts that hold keys so root keys, session keys and decrypted data never leave infrastructure you control.
- Write down which party can decrypt what, hop by hop, and check the diagram matches the contracts. This is where a managed platform's role becomes visible.
- Secure the backhaul and the servers as first-class IT systems: VLAN segmentation, TLS, RBAC, patching, encrypted backups.
- Classify your data and keep it in-jurisdiction to satisfy GDPR and sector-specific rules.
- Document all of it, the architecture, the data flow and the key-custody model, before the security review, so the review validates a plan rather than discovering the absence of one.
None of this is exotic. But getting it right, and being able to prove it to an auditor or a security officer, is the difference between a rollout that proceeds and one that stalls in review.
What I Provide
IoT security is where the protocols' guarantees meet your organization's compliance obligations, and where a clear architecture is worth more than any single product. This is consulting work by nature: you need the design and the documentation to pass review, then the knowledge transfer to operate the system securely on your own.
The design work starts with the key-custody model: how devices are provisioned and activated, which components hold which keys, and a self-hosted deployment where none of them leave your infrastructure. Around it comes hardening (VLAN segmentation, TLS, role-based access control, encrypted backups), data-residency and privacy review, and device lifecycle management: secure provisioning, credential rotation and decommissioning at scale. For the review itself, I produce the architecture diagrams, data-flow maps and key-custody statement that IT security teams ask for, set up anomaly monitoring, and train your staff to maintain the posture on their own.
I do not sell hardware or charge recurring fees, and I never hold your keys. The engagement is a one-time cost: I help you design and deploy a system that is secure by architecture rather than by trusting someone else's platform, and that you can prove is secure when the question comes.
If a full rollout is still ahead, a short security architecture review, a key-custody model and a documented data flow for your proposed deployment, tells you exactly what your security team will need to see before they sign.
Working on something like this?
If this article touches on what you are building, tell me about it. The first conversation is free, and you will get an honest read on the right approach for your situation.
Book a free consultationCurious what the finished thing looks like? Open the live demo dashboard
