Security

Who Holds the Keys

The Question That Costs Four Months

The pilot worked, the dashboards are convincing and the budget is signed. Then it reaches the security team, and it stops on one question: where do the encryption keys live, and who can read the payload.

For a hospital placing sensors near patients, a landlord whose occupancy data is personal data, or a utility instrumenting something that appears on a critical infrastructure register, this is not a formality. Somebody has to sign a document saying the system is safe. If the key custody question cannot be answered in a sentence, the project sits in review while people who have never met discuss it by email, and that delay kills more deployments than any technical failure.

The awkward part is that the honest answer is often uncomfortable, and nobody discovers this until the review. It is much cheaper to discover it while choosing the architecture.

Three Things Called Encryption

Most confusion here comes from one word covering three different protections. Separating them is what turns a security document into something that survives a careful reader.

Transport encryption protects one hop. TLS between a device and a broker, or the ciphering between a cellular module and the carrier's core, keeps the data safe while it is on that link and hands it over in clear text at the far end. It says nothing whatsoever about what happens next, which is usually where the interesting risk is.

Integrity and authenticity prove that a message came from the device it claims to and was not altered on the way. A message integrity code or a signature does this. It is the property that stops somebody injecting fabricated readings into data you are billing from, and it is separate from confidentiality: a message can be provably genuine and completely readable.

End-to-end confidentiality means the payload is encrypted with a key held only by the device and the final application, so every hop in between carries data it cannot read, including whoever operates the network. This is the strong property, the rare one, and the only one that makes "no third party can read our data" a true statement rather than a hopeful one.

Most deployments have the first two and believe they have the third. The gap only becomes visible when you draw the path and write down which party holds which key at each step, which is an afternoon's work and worth doing before anyone asks.

What the Protocols Actually Give You

The specifics change by technology, and the useful thing is knowing what to check in whichever one you are running.

A cellular device gets link ciphering to the carrier for free and nothing beyond it. Everything past the carrier's core is whatever your application put there, which should be TLS with a client certificate to your own endpoint. A cellular device with no application-layer TLS is a device whose data is readable by the carrier and by every hop after it, and that is a surprisingly common configuration because the link encryption makes it feel handled.

An IP device speaking MQTT or HTTPS should use TLS 1.2 or 1.3 with mutual authentication. Mutual matters: without a per-device credential, anything that can reach the broker can impersonate a sensor. The failure I see most is one shared credential across a fleet, which works fine until you need to revoke one device and discover you have to reprovision all of them.

A low-power radio network does more of this for you. AES is mandatory rather than optional, and the better designs separate a network layer that verifies integrity from an application layer that provides confidentiality, using different keys. That separation is the genuinely interesting property, because it means the party routing your traffic and the party reading it can be cryptographically different people. Whether they actually are is an architecture decision, not a protocol feature, which brings us to the part that matters.

One detail is worth checking on every project regardless of technology: how a device gets its credentials. Credentials negotiated at connection time are fresh per session, can be rotated by reconnecting, and never travel through a provisioning spreadsheet. Credentials burned in at manufacture are simpler and carry real risk, because they can be extracted from a captured unit and, on protocols with a counter, can expose a replay path if that counter resets. Dynamic activation should be the default for anything in production. If a device only works with counter validation disabled, that is a defect to report, not a setting to change.

The Boundary That Actually Decides It

Here is the part that separates a secure deployment from an encrypted one, and it is architectural.

Encryption is exactly as trustworthy as the custody of the keys. On a managed platform, the application keys are typically held by the platform. Your data is encrypted in transit, which is true, and then decrypted on infrastructure you do not control by a company whose security posture, breach history, jurisdiction and corporate longevity you are now taking on trust. "The data is encrypted" is accurate and beside the point when a third party holds the key that opens it.

On infrastructure you host, the root keys, the session keys and the decrypted data never leave your environment. The security team's question then has an answer that fits on one line, and it is an answer about custody rather than about algorithms: the keys were generated here, they are stored here, and nobody outside this organisation is in a position to decrypt anything. No amount of supplier certification substitutes for being able to say that.

Self-hosting is usually argued on cost. The argument that actually matters to a security officer is custody: you cannot be the sole custodian of a key that somebody else generated, stores and can read.

For regulated sectors this is the difference between a compliant deployment and a finding at the next audit. It is also the difference between answering a data subject access request yourself and forwarding it to a supplier.

The Half That Is Not the Device Protocol

A credible posture extends well past the radio, and these are the areas a serious review will probe.

The backhaul is the one that fails reviews. An encrypted payload travelling from a gateway to your server over the internet does not excuse a gateway sitting on a desk port with a public address. Field equipment belongs on a dedicated segment, behind a firewall, with egress restricted to the ingest server, TLS on the connection and an owner for its patching. It also belongs in an asset inventory, because somebody will eventually ask what happens when one is stolen, and "it holds no application keys and its credentials can be revoked from the server" is the answer you want to already be true.

Server hardening is conventional IT work and is treated as such: patched systems, TLS everywhere, role-based access, encrypted backups and a recovery plan that has been tested rather than written. Self-hosting means owning this, which is precisely why the initial build benefits from someone who has done it before and why the handover has to include the runbook.

Data classification decides your obligations and it is done first, not last. Occupancy patterns in an office can be personal data. Consumption per tenant carries billing and privacy implications. Readings from a clinical area carry sector-specific rules. The classification dictates retention, access control and, critically, where the data may physically sit, and hosting in your own jurisdiction is the cleanest way to satisfy a residency requirement rather than arguing about adequacy decisions.

Device lifecycle is a security control that gets treated as logistics. Provisioning must handle credentials without emailing them around. Updating must be possible, because a fleet you cannot patch keeps whatever vulnerability it shipped with for a decade. And decommissioning must revoke credentials, so a sensor that comes off a wall and into a skip cannot rejoin. At scale these are tooling and process, and they are cheapest to build before there are two thousand devices.

Last is monitoring, because you cannot respond to what you cannot see. A well-instrumented platform surfaces devices that suddenly change behaviour, connection attempts from identities that should not exist, counter anomalies that suggest replay, and a device reporting from a location it cannot physically be in.

Six Decisions, Made Deliberately

A posture that survives review comes down to a handful of choices, and the value is in making them on purpose rather than inheriting them.

Give every device its own credential, provisioned securely and revocable alone, and rotate on a schedule rather than never. Host the components that hold keys yourself, so root keys and decrypted data stay on infrastructure you control. Draw the data path and write down, hop by hop, which party can decrypt what, then check that the diagram agrees with the contracts. Secure the backhaul and the servers as first-class IT systems rather than as an appendix to the sensor project. Classify the data and keep it in jurisdiction. And document all of it before the review rather than during it, so the meeting validates a plan instead of discovering there isn't one.

None of this is exotic. Being able to prove it to an auditor is what separates a rollout that proceeds from one that spends a year in a queue.

When This Is Over-Engineering

Not every deployment needs this treatment and pretending otherwise wastes money.

If the sensors measure something genuinely uninteresting to an attacker, the temperature of a warehouse, say, with no personal data and no billing derived from it, the realistic threat is denial rather than disclosure. Integrity and availability matter, confidentiality less so, and a managed platform with sensible defaults is a perfectly reasonable answer.

If the organisation has no capacity to operate a server, self-hosting is not more secure. An unpatched box in a cupboard with the keys on it is worse than a competent supplier's platform, and the honest recommendation in that situation is to pay somebody or to fund the role, not to build something nobody will maintain.

The distinction is not company size. It is whether the data is sensitive, whether the sector is regulated, and whether somebody will own the infrastructure after the project closes.

What I Provide

The deliverable here is usually documentation rather than software, because the software problem is generally the smaller one.

I produce the architecture diagram, the data flow map and the key custody statement in the form security teams actually ask for, which is a short document naming every party in the path and what each can read. Around it goes the design work: how devices are provisioned and rotated, what the network segmentation looks like, where the data sits and under whose jurisdiction, and how a device is decommissioned. Then the hardening itself, the anomaly monitoring, and training for whoever runs it afterwards.

I do not sell hardware, charge recurring fees, or hold anyone's keys. Where a rollout is still ahead, a short architecture review at the design stage tells you exactly what the review board will ask for, which is a great deal cheaper than finding out from them.