Case study

A three-year programme across a national infrastructure estate

The first eighteen months of this three-year programme put nothing in the field at all: firmware, software, the AWS environment, the platform and the hardware form factors were built first. A short initial pilot followed, then a proof of concept, then a rollout to approaching a thousand UK critical national infrastructure sites, which report every day.

Sector: Critical national infrastructure
Scale: Approaching a thousand sites
Duration: Three-year programme, 18 months live and still reporting today
Network: 433 MHz, uplink only

The challenge

The challenge: equipment that only indicates where it stands

The estate runs to approaching a thousand sites. At each one, equipment indicates its own state and nothing further. A panel shows a condition, a contact sits open or closed, a gauge reads what it reads, and all of it stays at the site until a person is standing in front of it.

That put physical attendance in front of every question. Knowing the state of a site meant sending someone to look, and the round cost the same whether anything had changed or not. Manned guarding covered part of the estate and scheduled attendance covered the rest.

Between one visit and the next, the state of a site is whatever it was when someone last looked. Across approaching a thousand sites, that gap is the problem the estate set out to close.

Closing it the conventional way would have meant putting reachable, networked equipment on sites where the security posture governs what is allowed through the gate. For a critical national infrastructure operator, the first question asked of a monitoring system is what it adds to the attack surface, and a system that cannot answer it well does not get installed.

The assurance

What it took to be allowed on site

These are secure critical national infrastructure sites and access to them is hard to obtain. Reaching them took extensive due diligence and multiple sign-offs, and that process is the part of a deployment like this one that a shorter engagement never reaches.

Supplier assurance came first. The company was assessed as a supplier before any equipment was assessed as a system, and more than one organisation had to be satisfied before the work could proceed. Sign-off did not rest with a single party.

Approval ran through the client's own IT function, which reviewed the network implications of anything that would connect. The engineering was carried out under a formal software product development lifecycle, and the approvals process behind both was long.

The security review examined the architecture rather than the description of it: what can reach the estate, by what path, and what has to be maintained in the field once installed. How the network answers those questions is set out below.

Onboarding ran as a programme in its own right. The monitoring layer had to fit departments and infrastructure that already existed, so the integration was agreed with the people who run them rather than designed around them.

Access is escorted throughout. Nobody attends a site unaccompanied, then or since, which shapes how the work is planned and how much of it is worth doing on any single visit.

The programme

How the deployment was proven

The estate did not take the architecture on description. Each stage had to hold before the next one was allowed, and the sequence below is the order it actually ran in.

Engineering build

The first eighteen months put nothing in the field. Firmware, software, the AWS environment, the platform and the hardware form factors were built and tested in that period, alongside the assurance and approvals work. This is why the field record starts later than the programme does.

Initial pilot

A first deployment of one to two months put the equipment on real sites. An RF survey established how 433 MHz behaves in the positions the estate actually has, measured on site rather than predicted from a plan, and positions and thresholds were settled at the point of installation because that is where they stay.

Proof of concept

A proof of concept followed the pilot and took the architecture from working on a handful of sites to answering the estate's own requirements: both reporting paths, the integration with existing departments and infrastructure, and what the platform does with the readings once they arrive.

Rollout and live running

The rollout ran progressively to approaching a thousand sites, and there are eighteen months of field data behind it. The estate reports every day. This is the part of a deployment that no pilot demonstrates, and it is the reason the arrangement is treated as settled rather than provisional.

The deployment

What each site reports

Twelve monitored channels report from every site, all carried by one network. The capabilities behind them are the standard range, each available on its own or as part of an estate-wide layer.

Estate-wide monitoring

Every monitored point across every site feeds one live view, with alerts pushed to the people responsible rather than waiting to be found on a dashboard. At this scale that is the difference between holding data and having visibility: the condition of the estate is legible at once, and the estate is interrupted when something needs a response.

Estate operations

Acoustic monitoring

Sound is monitored continuously and reported as an average across each sampling window, so a short spike and a sustained change are distinguishable at the platform without the radio carrying every sample. It is the clearest example on the estate of the tag doing the arithmetic rather than the network.

Real-time sound monitoring

Intrusion detection

The security state of a site is monitored continuously and reported at the moment it changes rather than at the next attendance. On sites that stand unmanned for long stretches, that timing is what keeps a change legible while it is still current.

Perimeter intrusion detection

Enclosure condition

Conditions inside cabinets and enclosures are reported continuously. These are the positions that are hardest to reach and least often visited, which is exactly why their state is worth knowing without attending.

Cabinet and site monitoring

Temperature and humidity

Environmental conditions across technical spaces are read continuously rather than at inspection. Slow drift is the failure mode that a periodic check is least likely to catch, because it looks acceptable at every individual reading.

Environmental monitoring

Heat risk

Equipment and the spaces around it are monitored for heat, which rises well before anything stops working. Catching a rise while it is still a rise is the whole value; catching it afterwards is a maintenance report.

Thermal and heat-risk detection

Pressure

Pressurised systems are read continuously instead of at the interval someone can attend. A system drifting out of range becomes a routed alert rather than a condition discovered at the next scheduled visit.

Real-time pressure monitoring

Water escape

Water where it should not be is reported as it happens rather than found by its consequences. On a site nobody is standing on, the timing is the entire difference between a contained event and an expensive one.

Leak detection

The network

How the network works

Every tag on the estate transmits and never receives. Readings travel one way, over 433 MHz radio, to a gateway at the site. There is no downlink to the tags, so there is no pairing, no remote configuration and no over-the-air update path, and nothing on the estate can be reached over the air by anyone.

Reporting runs on two paths at once. Any discernible state change is transmitted immediately, and that is the path an alert takes. Underneath it, each site sends a full status set every three minutes by design. The scheduled cycle is the health heartbeat rather than the response path, and it is what makes silence legible: a report that was expected and did not arrive is itself an event.

The acoustic tag shows the design in miniature. It samples every 30 seconds and transmits the average across the window, so the tag does the arithmetic and the radio carries the result. Sampling rate and transmission rate are separate decisions, and keeping them separate is what allows a channel to be monitored closely without the radio talking constantly.

The platform behind it is a purpose-built AWS environment on a zero-trust architecture. The gateway's outbound connection is the single route off site, which is the point the estate controls and inspects. Nothing joins the networks the estate runs on, and the monitoring layer never meets the systems it reports on.

The ZARC network Secure data platforms

What the estate has now

Manned guarding and physical attendance were replaced by continuous monitoring and real-time alerts. The estate stopped sending people to find out what a site was doing and started being told, which changed what attendance is for: a visit now follows a reading instead of producing one.

The estate has real-time intelligence on the condition and security of every site, continuously, and is told the moment something changes. Intrusion detection and environmental conditions arrive through the same layer and on the same terms, so a change of state is an interruption rather than a discovery made later.

No unit has failed anywhere in the deployment to date, across every form factor deployed, and those units are still running in the field today. The losses have been of cellular SIM connectivity, which is a known characteristic of cellular rather than of the equipment, and Ethernet and solar variants are in development in response. That is the record of this deployment, not a general claim about how equipment behaves elsewhere.

The reporting volume follows directly from the interval, and the arithmetic is worth setting out so it can be checked. A site sending a full status set every three minutes sends 20 an hour, 480 a day and 175,200 a year. Multiply that by an estate of close to a thousand sites, then by the twelve monitored channels at each one, and the annual figures below follow.

Each site reports a full status set every three minutes by design, and reports immediately whenever a monitored state changes. Scheduled reporting alone accounts for over 170 million status reports a year across an estate approaching a thousand sites, and at twelve monitored channels per site that is more than two billion individual sensor readings a year. Every event report sits on top of that, so the true figure is higher.

Those are annual rates rather than totals to date, and the rollout was progressive, so there is no cumulative figure to quote. The point of the rate is not its size but what sustaining it requires: a radio carrying no acknowledgement traffic, and a platform built to take that volume as a matter of routine.

The conclusion

What remote means on an estate like this

Remote monitoring here means unattended. The equipment at each site indicates its state where it stands, and always did; what changed is that the indication now arrives on a dashboard instead of waiting for someone to come and read it. Equipment that only ever signalled locally has been digitalised, and the estate is told rather than sending someone to ask.

The architecture is what made that permissible. What satisfied the security review is the same property the estate now depends on operationally, and eighteen months of field data have not required it to be revisited.

Estates with a comparable security posture face the same question in the same order: what does this add to the attack surface, and who signed it off. The answers here are on the record, and the deployment behind them is running now. The estate holds a continuous record of how this equipment behaves in the field, and that record is the precondition for any future analysis of it.

FAQ

Frequently asked questions

How long has the system been running?

The programme runs to three years in total. The first eighteen months were engineering, with nothing in the field: firmware, software, the AWS environment, the platform and the hardware form factors. A short initial pilot of one to two months followed, then a proof of concept, then a progressive rollout to approaching a thousand sites. There are eighteen months of field data to date and the estate reports every day.

What assurance process did the monitoring system have to pass?

These are secure critical national infrastructure sites and access to them is hard to obtain. It took extensive due diligence and multiple sign-offs: supplier assurance, a security review of the architecture, IT and network approval through the client's own IT function, a formal software product development lifecycle for the engineering, and a long approvals process behind all of it. More than one organisation had to sign off. Access to sites is escorted throughout and no one attends unaccompanied.

Why is the telemetry uplink only?

Because a tag that cannot receive has nothing to be reached through. Readings travel one way, over 433 MHz radio, to a gateway at the site. There is no inbound radio path, no pairing, no remote configuration and no over-the-air update mechanism, so there are no credentials to capture and nothing to patch in the field.

How do the two reporting paths work?

Any discernible state change is transmitted immediately, and that is the path an alert takes. Underneath it, each site sends a full status set on a fixed schedule as a health heartbeat. The scheduled cycle is not the response path; its value is that a report which was expected and did not arrive is itself an event the platform can raise.

How often does each site report?

Every three minutes, by design, for the full status set, on top of immediate reporting whenever a monitored state changes. At that interval a single site sends 20 scheduled reports an hour and 175,200 a year, which across an estate approaching a thousand sites is over 170 million scheduled status reports a year before any event reporting is counted.

Why is the operator not named?

The nature of the estate means the client and its sites are not identified, and no sector detail, site reference or location is published. What can be described is the architecture, the assurance process it passed and the scale and duration of the deployment, which is what makes the case study useful to anyone assessing a similar system.

Does this approach apply to other estates?

It applies wherever equipment indicates only on site, sites are unmanned or hard to reach, and the security posture governs what may be installed. The requirement it suits is monitoring rather than control: the architecture is the wrong choice wherever equipment has to be commanded remotely rather than observed.