What a Net Zero Data Backbone Teaches Us About Securing Critical Infrastructure

José Figueiredo, Principal Engineer at Critical Software

The security-relevant decisions in a settlement platform for the UK’s low-carbon schemes turned out to be architectural rather than defensive. Here are four lessons for anyone building systems that must outlive the policy cycle that commissioned them.

‍

Every low-carbon megawatt-hour the UK pays for is measured. Contracts for Difference pay generators the gap between a strike price and the market price for what they produced; the Capacity Market pays for availability; hydrogen and carbon-capture contracts pay against metered output and captured metric tons. The Low Carbon Contracts Company (LCCC), the government-owned counterparty for Contracts for Difference (CfD) and the newer schemes, and the settlement body for the Capacity Market on behalf of its sister company, settles billions of pounds a year on numbers that originate in meters, SCADA systems, and operator-submitted reports it does not own or control.

When we started work on LCCC’s Head End System—the platform that collects, validates, and processes that data—the obvious framing was a data-engineering problem with a security requirement attached. Three years on, I think that framing was backward. The decisions that most shaped the system’s security posture were not the ones in the security section of the design. They were the architectural choices about what the system depended on, how it changed, and where it drew its trust boundaries.

That is worth dwelling on, because most critical-infrastructure security conversations I have are about controls: which IAM, which encryption, which monitoring. Those matter, and I will come to them. But in a system that must outlive the policy cycle that commissioned it, the controls are the easy part. The hard part is making sure the next change—a new scheme, a new regulator, a new meter vendor—does not undo them.

Here are four lessons from the build, in roughly the order we learned them.

1. You Cannot Secure What You Cannot Replace

LCCC’s data landscape is the one most operational technology (OT) security practitioners will recognize: dozens of generator sites, each with its own metering vendor, its own SCADA or data-acquisition historian, its own network topology, and its own opinion about how data should leave the fence. No counterparty can mandate hardware across that estate, and even if it could, the estate would change faster than the mandate.

The tempting response is to pick a platform—one meter manufacturer’s head end, one SCADA vendor’s connector, one cloud’s managed ingestion service—and build on it. It is tempting because it is fast. It is a security problem because every dependency you cannot replace is a dependency whose vulnerabilities, patch cadence, and end-of-life decisions you have to accept on someone else’s terms. When the only way to stop using a compromised or abandoned component is a rebuild, you will not stop using it; you will mitigate around it, indefinitely.

We took the slower route. Meter collection natively speaks DLMS/COSEM over TCP, with data points for each site described as OBIS codes and attribute identifiers in configuration rather than via vendor-specific adapters. SCADA and historian integration is handled through a published Edge API specification that each participant implements on their side of the boundary, so the platform never has to know what lies behind it. Storage is an open-format lakehouse rather than a proprietary warehouse. Services are containerized and orchestrated so that the cloud provider is a commercial choice rather than an architectural fact.

None of that is exotic. What I want to argue is that it belongs in the security case, not just the procurement case. Vendor-agnosticism is the property that lets you respond to a supply-chain advisory by swapping a component rather than by writing a risk acceptance. In critical infrastructure, where the realistic threat is as likely to be an unpatched dependency as a targeted intrusion, that is one of the most valuable controls you can have—and it is invisible in a controls checklist.

2. Configuration Is the Smallest Attack Surface You Can Add

When the Head End System was procured, some of the schemes it would eventually serve did not exist yet. Hydrogen and industrial carbon-capture contracts were still being designed; dispatchable power and power BECCS (Bioenergy with Carbon Capture and Storage) came later. The one certainty was that the rule set would keep growing, and that each addition would arrive with its own collection frequency, validation thresholds, and calculation logic.

The conventional response is a new module per scheme. Each module is new code, new tests, new dependencies, a new penetration-test scope, and a new set of ways to get something wrong. Over a decade, the attack surface grows in step with the policy agenda, and the security team’s job becomes keeping up.

We designed the Scheme Processing Engine so that a scheme is primarily data. Collection cadence, plausibility rules, cleansing, aggregation, and the calculation formula live in a versioned configuration model—we call them smart contracts, though there is nothing distributed about them—that the engine interprets. A new scheme is mostly a new configuration, released under change control like any other production change. Development is reserved for calculation logic that configuration cannot express, and when needed, it is added as an isolated engine behind the same interfaces rather than as a change to the core.

The security argument for this is simple arithmetic. The configuration path is one well-tested interpreter and one well-tested release process, exercised the same way for every scheme. The code path is new every time. If you want a system that stays as secure in year eight as it was at go-live, you want as much of the change as possible to travel down the first path. “Maximize configuration, minimize development” is a cost-of-change principle, but it is also an attack-surface principle, and I would make that argument explicitly to any security reviewer who asks why the rules are not “just in the code.”

There is a corollary worth stating. A configuration that can change what the system pays out is itself a sensitive asset. We treat a smart-contract change with the same maker–checker approval, immutable audit record, and environment separation as a payment instruction. Moving logic out of code does not move it out of scope; it moves it into a place where the controls are uniform.

3. The Trust Boundary Is Where the Data Arrives, Not Where it Is Stored

Most of the security effort in a data platform goes into protecting data at rest and in transit, and rightly so. But in a settlement system, the more consequential question is whether the data was right when it arrived. A reading that is wrong by a factor of ten—because a meter was misconfigured, a historian tag was remapped, or someone upstream had an incentive—is a financial integrity failure, and no amount of encryption will catch it.

We therefore treat ingestion as a trust boundary in its own right. Every source is authenticated and every transfer encrypted, but that is the floor. Above it sit three layers that have nothing to do with confidentiality and everything to do with integrity.

First, structural validation at the point of entry: each submission interface is defined by a JSON schema shared with the adjacent systems, and anything that does not conform is rejected before it touches storage. Second, plausibility rules and anomaly detection on the production data itself—flat-lining meters, impossible step changes, readings outside the contracted capacity, gaps that correlate with communications faults. Third, automatic re-collection where the fault is retrievable, and routing to a human where it is not.

The design choice I think generalizes is that none of these checks silently alter data. Raw readings are landed as received and never edited; validated and processed data are written as new, versioned layers alongside them. If a verifier or an auditor asks why a settlement figure is what it is, the answer is a lineage from the raw reading through each rule that touched it, not a reconstructed narrative. For critical infrastructure, where the plausible adversary includes a participant with a commercial interest in the number, tamper evidence on the data path matters at least as much as access control on the perimeter.

This also changes what “operational technology security” means in practice. The generator’s SCADA is outside our boundary; we cannot harden it and should not try. What we can do is refuse to let its output become a settlement figure without passing through a verification layer that assumes it might be wrong. That is a more honest security model than pretending the boundary extends to equipment we do not control.

4. Secure by Design Means the Evidence Is a Living Artifact

The controls themselves are what you would expect from a system built under the UK government’s Secure by Design principles and operated in an ISO 27001-certified environment: centralized identity with MFA and role-based, least-privilege access; API gateways in front of every service, with no direct database exposure; encryption in transit and at rest with keys held in cloud key vaults; private networking; static and dynamic analysis and software-composition scanning in the CI/CD pipeline; independent penetration testing; centralized security logging and alerting. I will not spend words on each, because the list is not the lesson.

The lesson is what happened to the evidence. On most projects I have seen, security evidence is produced for a gate—a design review, a go-live approval, an annual audit—and then goes stale the week after. The threat model describes the system as it was; the pen-test report covers the release before last; the access review was accurate until the last reorganization. The controls may still be in place, but nobody can demonstrate it without a scramble.

We set out to make security evidence a by-product of change rather than a separate activity. The threat model is revisited at every significant architectural change, not annually. Scanning and composition analysis run on every build, so the dependency inventory is always current. Access is recertified on a cycle by the role owners who actually know who should have it. Audit logging is append-only and part of the platform, not an add-on. The result is that when a regulator, an auditor, or a new scheme owner asks “show me,” the answer is a report from the system as it runs today.

This is less a tooling point than an organizational one. It requires that someone is accountable for the security posture across the life of the service, not just at delivery, and that the engineering process makes keeping the evidence current cheaper than letting it rot. Shift-left is usually described as a way to find vulnerabilities earlier. In a long-lived critical system, its more important effect is that the assurance never has to be rebuilt from scratch.

The Question that Matters

Since the Head End System went live, LCCC has added schemes that were not in the original scope—industrial carbon capture, dispatchable power, power BECCS—largely through configuration, and is now extending the same platform into settlement calculation itself rather than procuring a parallel system. I take that as the real security result. Not that the system passed its tests, though it did, but that each of those changes arrived without a redesign, without a new vendor dependency, and without the assurance evidence having to be rebuilt.

If I could change one thing about how critical infrastructure security is reviewed, it would be the question being asked. ”Is this system secure?” is answerable, and the answer is usually a snapshot. The question that predicts whether it will still be secure in five years is different: how cheaply and how safely can it absorb the next scheme, the next regulator, the next vendor change? Architecture answers that question. Controls do not.

The engineers who get this right tend not to be the ones with the longest security checklist. They are the ones who treated replaceability, configuration, and data-path integrity as security properties from the first design session, and then made sure the evidence kept up.

‍