One-way telemetry is an architectural decision, not a compromise

Ask most engineers to specify a remote sensor and the design will come back able to receive as well as transmit. Not because the application called for it, but because that is what a connected device has meant for twenty years. The assumption is inherited from two places: the internet, where every endpoint is addressable by definition, and consumer connected products, where a device you cannot command from a phone is considered faulty.

The assumption survives mainly because it is never written down. No requirements document says the sensor must be capable of receiving. It arrives bundled in the radio module, the protocol stack and the reference design, and by the time anyone thinks to question it the architecture is already fixed and the power budget has been built around it.

It is worth asking the question directly. In a sensor whose entire job is to report the state of one thing, what does the receive path actually do? It does not perform the measurement. It does not send the reading. Its functions are remote configuration, firmware updates in the field, querying a device on demand, and handling confirmations that a message arrived. Every one of those is a convenience for whoever operates the fleet. Not one of them is a function of the measurement itself.

That distinction matters because the receive path is not free. It is paid for continuously, in energy, for as long as the device is deployed, and it is paid for permanently in exposure. Both costs fall on the sensor. The benefits fall on the operator. When the sensor is fixed to a pipe in an unvisited plant room for the next decade, that is a poor trade.

Once the question is asked properly, the architecture that follows is not a stripped-down version of a connected device. It is a different class of device, and it behaves differently in ways that matter more than the feature list suggests.

The energy arithmetic is the part most people find counter-intuitive, because the instinct is that transmitting must be the expensive part. Transmitting requires power amplification; listening seems passive. In a battery-powered sensor that reports occasionally, the opposite is usually true.

A transmitter is only energised while it is actually sending. For a small reading - a temperature, a state change, a level - that is a very short burst, and the radio is completely off either side of it. Even at a comparatively high transmit power, the total energy is small because the duration is tiny and the events are infrequent.

A receiver has the opposite problem. It has to be powered up during any period in which a message might arrive, and it has no way of knowing when that will be. There are only two options and both cost energy. Either the receiver listens continuously, which is ruinous on a battery, or it wakes on a schedule and listens for a window, which means the radio is repeatedly energised while nothing at all happens. Those windows have to be frequent enough that the device responds usefully, and each one has a fixed overhead before it can hear anything. Multiply a short listening window by a schedule that repeats through every day of a ten-year deployment and the total dwarfs the handful of milliseconds a day spent transmitting readings.

This is why receive-capable battery sensors tend to arrive with a compromise buried somewhere in the specification. Either the listening schedule is stretched until remote configuration takes hours to reach the device, which erodes the benefit that justified the receiver in the first place, or the battery is large, or the stated life is shorter than anyone would like, or the device quietly assumes it will be mains powered after all.

Remove the receiver and the arithmetic changes character entirely. The radio is off except during the microseconds it is talking, and the remaining draw is the sensing element and a low-power timer. Multi-year battery life stops being an optimisation problem to be solved and becomes a straightforward consequence of the design. Nothing has to be traded away to reach it, which is the definition of a good architectural decision rather than a clever one.

There is a second-order effect worth noting. Because the energy budget is dominated by predictable, scheduled transmissions rather than by a listening duty cycle that varies with network conditions, battery consumption becomes far easier to model honestly. A device whose power draw depends on how much traffic it happens to hear is difficult to forecast; a device that only ever talks on a fixed cycle is not.

Every conventional connected sensor brings a set of liabilities onto the site along with its capability, and they persist for the whole life of the device. Credentials have to exist somewhere so the device can be authenticated. An interface has to exist so it can be configured. Firmware has to be updatable, which means an update mechanism has to be present and trusted. Network membership has to be granted so the traffic can route. Each of those is useful. Each is also permanent, and each has to be defended by someone, for years, across every unit in the estate.

A device that cannot receive has none of them. There is no inbound radio path, so there is nothing to send to. There is no pairing process to subvert and no remote configuration interface to find. There is no over-the-air update mechanism, so there is no update mechanism to abuse. There are no credentials, because nothing ever needs to authenticate to the device. It holds no IP address and joins no network, so there is nothing to scan, nothing to enumerate and nothing to appear in an asset inventory as an unpatched endpoint. Its behaviour is fixed at manufacture and cannot be degraded in the field, by an attacker or by accident.

The useful way to test this is to imagine the most capable adversary you can and give them the easiest possible conditions. Put a signals intelligence team on the ground beside the unit. Give them unlimited time, professional receiving equipment and full knowledge of the frequency. Let them listen to everything it emits for as long as they like.

There is nothing to log into. No port, no pairing sequence, no management interface, no credentials to capture and replay, no firmware image to pull down and pick apart for a way back in. The reward for the entire exercise is the current temperature of a plant room, or the fact that a door is shut.

That is the part worth dwelling on. In a conventional deployment, the sensor is valuable to an attacker not for its data but as a foothold - a poorly maintained device on the network that can be compromised and used to reach something that matters. That entire class of attack requires the device to be reachable and to be on a network. A transmit-only sensor is neither. It cannot be turned into a foothold because there is nowhere for it to be a foothold on, and the monitoring layer therefore adds no new route into the estate it was installed to watch over.

For an operator who has to answer formally for what has been added to their network, this changes the nature of the conversation. The honest answer is that nothing has been added to it.

An argument like this is only worth reading if it is honest about its limits, so here they are. One-way transmission does not make a radio link invulnerable, and anyone who tells you otherwise is selling rather than engineering.

Someone standing next to the sensor with the right equipment has three options. They can jam the band and prevent readings from getting out. They can physically remove, shield or destroy the tag. And they can transmit their own signal on the same frequency to attempt to introduce a reading that did not come from the sensor. None of those is prevented by the absence of a receiver, and all three should be assumed possible by anyone assessing the architecture properly.

What matters is what each of those achieves. Jamming and physical removal both produce the same outcome: the sensor stops reporting. Spoofing a reading produces a false alarm. What none of them produces is access - no credential, no lateral movement, no persistence, no route to any other system. The attacker has degraded the monitoring or created a nuisance. They have not got in, because there is no in.

There is also a structural defence against the first two that comes free with the architecture, and it is the point most people miss. When a sensor reports on a schedule, absence is itself information. A reading that does not arrive when it was due is an event, and the platform treats it as one. Jam the band and the silence is reported. Remove the tag and the silence is reported. An attack whose effect is to stop a sensor talking is an attack that announces itself, because the system was expecting to hear from that sensor and did not.

Compare that with the failure mode of a compromised receive-capable device, which is considerably worse. A device that has been taken over can continue reporting entirely plausible values while under someone else's control. It looks healthy on the dashboard. Nothing is missing, nothing raises an alert, and the operator has no reason to look. Silence is a loud failure. Confident, plausible, false data is a quiet one, and quiet failures are the ones that cause damage.

Spoofing deserves its own note, because it is the objection a good security architect will raise. Introducing a false reading is possible in principle. It is also low value: the result is an alarm about a piece of equipment, investigated by someone who then finds nothing wrong. It does not scale, it does not persist, it requires physical proximity to the site, and it is visible in correlation, because a single sensor reporting something the rest of the estate contradicts is a pattern operators learn to read quickly.

The costs are real and they are not hidden in the small print, so it is better to state them plainly than to be caught out by them later.

A one-way sensor cannot be reconfigured from a desk. Thresholds, reporting behaviour and what the device measures are decided before it is fitted, not adjusted afterwards over the air. Firmware cannot be updated remotely; a change means physical access to the unit. The device cannot be queried on demand, so an operator gets what it sends when it sends it, rather than being able to ask it a question. And remote diagnostics are limited to what the device itself reports, which in practice means its own health telemetry rather than an interactive session with it.

Those constraints impose a discipline that is genuinely demanding, and it lands earlier in the project than most people expect. The site survey matters more, because coverage cannot be fixed later by adjusting a parameter. The sensor schedule matters more, because positions, measurements and thresholds have to be right before anything is fixed to a wall. Commissioning matters more, because a mistake discovered afterwards is a site visit rather than an email. An architecture that removes the ability to correct decisions remotely obliges everyone to make better decisions in the first place, which is a cost, and also - for estates where nobody wants to revisit a plant room for a decade - much of the point.

There are applications where this is simply the wrong choice, and pretending otherwise would be dishonest. If a device has to be told to do something - open a valve, reset a controller, change a setpoint, silence an alarm at the panel - then it has to be able to receive, and no argument about power budgets or attack surface changes that. If large payloads have to move, a small scheduled one-way message is the wrong vehicle. If behaviour genuinely needs to change frequently and unpredictably across a fleet, remote configuration earns its cost. And where a device is mains powered and sits inside a well-managed network with a real patching regime, the power argument disappears and the security argument becomes a matter of judgement rather than a structural advantage.

What connects every one of those exceptions is control. The moment the requirement is to act on equipment rather than to observe it, the receiver has a job to do and its costs are worth paying.

Monitoring is not control. The requirement is to know the state of a thing and to be told when it changes. For that requirement, and specifically at estate scale where hundreds or thousands of battery-powered devices sit in positions nobody wants to visit, a receiver is a component that consumes the majority of the power budget, carries the entire remote attack surface, and performs no part of the actual task. Leaving it out is not a compromise made reluctantly. It is the decision the requirement points to, once the requirement is stated honestly.