Why It Is Broader Than Loal Hosting
Written by René Böringer, CEO of Cuculus GmbH
There is a dangerous misconception spreading across the energy industry, which I repeating see and saw during my 20 years in this industry:
“We are sovereign because our systems are hosted locally.”
It sounds reassuring. It ticks a regulatory box. It satisfies internal governance.
But it is often wrong.
Sovereignty in utilities is not about where your software runs. It is about what you can control when things go wrong.
And that difference is where real risk lives.
For decades, the energy system was built around predictability. Large generation assets produced electricity, transmission and distribution grids transported it, and customers consumed it. The operational model was complex, but relatively stable. Planning cycles were long, demand patterns were predictable, and the digital layer was mainly used to support billing, reporting, and asset administration.
That world is disappearing.
Today’s grid is becoming decentralized, dynamic, and highly digital. Rooftop PV, EV charging, battery storage, heat pumps, flexible loads, and distributed generation are changing the behavior of the grid at the edge. Instead of a few large generation points and many passive consumers, utilities increasingly operate a system with millions of active endpoints. This changes the nature of sovereignty fundamentally.
In the old world, sovereignty was mostly about physical infrastructure and energy supply. Who owns the power plants? Who controls the fuel? Who operates the grid?
In the new world, sovereignty is also about the digital operating layer. Who controls the data? Who controls the commands? Who controls the interfaces? Who controls the roadmap? Who controls the backup? Who controls the security keys? Who controls the ability to change the system when regulation, technology, or geopolitics changes?
This is why the topic is becoming so important. A grid operator may own the physical grid, employ its own staff, and host systems in a local data center — and still be deeply dependent on external actors for critical decisions and operations. That dependency may remain invisible during normal operation. It only becomes visible when the utility needs to change something quickly, respond to an incident, introduce a new technology, replace a vendor, or recover from a failure.
The real test of sovereignty is not whether everything works on a sunny day. The real test is whether the organization remains in control under stress.
To discuss sovereignty properly, we need to move away from simplistic definitions. Local hosting can be part of sovereignty, but it is not sovereignty itself. A locally hosted system can still be a black box. It can still have undocumented interfaces. It can still depend entirely on one vendor. It can still be impossible to extend without costly change requests. It can still have backups that the utility cannot restore independently.
A more useful way to think about sovereignty is to divide it into five dimensions: data sovereignty, operational sovereignty, technological sovereignty, security and trust sovereignty, and strategic and economic sovereignty. Only when all five are considered together can a utility understand its real level of control.
Data sovereignty starts with a simple question: can the utility use its own data freely, practically, and quickly?
Many utilities would answer yes because their contracts say that they own the data. But legal ownership is only one part of the story. The more relevant question is practical control. Can the utility extract the data without vendor involvement? Can it access all values stored in the meter? Can it add new datasets when regulation changes? Can it use the data for forecasting, grid planning, AI models, flexibility management, or customer services? Can it provide selected data to partners without months of technical preparation?
This becomes very concrete in smart metering. A meter may already collect additional values that would be useful for low-voltage grid monitoring or forecasting. But if the utility needs to open a change request, negotiate a contract amendment, wait for vendor implementation, and pay additional fees just to access data that already exists, then the utility is not truly sovereign over its data.
The situation becomes even more critical in Metering-as-a-Service models. Outsourcing can be commercially attractive and operationally efficient, but it can also create a hidden dependency. If the service provider controls the data access layer, the utility may become dependent on the provider’s priorities, roadmap, and commercial terms. In such a case, the utility may formally own the data but practically lose the ability to use it with speed and freedom.
True data sovereignty means that the utility can access, understand, export, and reuse its data without unnecessary barriers. It also means that data models are transparent and documented. If internal teams cannot understand how data is structured, or if the meaning of important fields is locked inside vendor knowledge, then future innovation becomes dependent on the vendor.
This is why open standards, documented APIs, and transparent data models are not technical details. They are sovereignty instruments. They determine whether the data can become a strategic asset or remains trapped inside a vendor-controlled environment.
Operational sovereignty is the ability to operate the grid independently and reliably, especially when conditions are not normal.
This is where many organizations discover the difference between having a system and being able to operate it. A utility may run the solution in its own environment, but if only the vendor can troubleshoot incidents, configure important processes, analyze failures, or execute urgent changes, then operational sovereignty is limited.
A simple test is useful: if the vendor is unavailable for 48 hours, can the utility still operate safely? Can it detect incidents? Can it diagnose root causes? Can it execute critical commands? Can it continue meter data collection? Can it maintain billing-relevant processes? Can it communicate with field devices? Can it switch to fallback procedures?
If the answer is unclear, the organization has a dependency problem.
Operational sovereignty is also not automatically created by internal IT. Having an internal IT department does not mean the grid operator is operationally sovereign. If the internal IT team does not understand the specific smart metering or grid operations environment, or if every change must go through slow internal service processes, then the utility may simply replace vendor dependency with internal bottleneck dependency.
In some cases, a well-designed service contract with a capable vendor may create more real sovereignty than a poorly operated internal system. This may sound counterintuitive, but sovereignty is not the same as doing everything alone. Sovereignty means being able to govern the operating model, understand dependencies, define responsibilities, and ensure reliable action when needed.
For grid operators, this matters because the operational environment is becoming faster. EV charging, distributed generation, and flexibility use cases require shorter reaction times. If the organization cannot adapt processes quickly enough, it loses control even if the software is technically installed in its own data center.
Technological sovereignty is about the ability to evolve the system over time.
This is one of the most important dimensions because smart metering and grid modernization projects are not short-term IT projects. They often run for ten years or more. During that period, communication technologies change, regulation changes, cybersecurity expectations change, customer expectations change, and new grid use cases emerge.
A non-sovereign technology setup may look acceptable at the beginning but become a trap later.
One common example is buying the HES from the meter vendor. This can appear logical at first: the meter vendor knows the devices, offers an integrated package, and promises easy rollout. But the risk is that the system may not implement standards in a truly open way. The HES may work very well with that vendor’s meters, but poorly with others. Adding a second meter vendor later may become technically difficult, commercially unattractive, or operationally risky.
Another example is dependency on a single communication technology. If a utility uses only one meter vendor, it may also indirectly limit itself to the communication technologies supported by that vendor. This can become dangerous if the communication technology becomes unavailable, politically restricted, too expensive, or unsuitable for future use cases.
Geopolitical developments have made this risk more visible. Equipment or communication infrastructure that seems acceptable at the time of deployment may later become politically sensitive. A government may restrict certain suppliers or technologies. If the utility has no alternative communication path, no multi-vendor strategy, and no flexible HES, the consequence can be expensive replacement or reduced operational capability.
Technological sovereignty therefore requires more than “the system works.” It requires real interoperability, documented APIs, modular architecture, multi-vendor capability, and the ability to extend the solution with new functions. The utility should be able to integrate new meters, sensors, communication technologies, forecasting tools, grid applications, and partner modules without being fully dependent on one vendor’s roadmap.
Open source can also play a role here. It does not automatically solve every problem, but it can increase transparency and trust. If code or relevant components are inspectable, the utility has more options to understand, validate, and eventually continue development. In critical infrastructure, trust should not be based only on vendor promises. It should be supported by transparency.
Security sovereignty is about who controls trust.
In smart metering and grid operations, trust is not abstract. It is implemented through cryptographic keys, certificates, HSM(Hardware Security Module)s, authentication, authorization, command validation, logging, monitoring, and recovery mechanisms. If these elements are not under clear governance, sovereignty is weak.
One important question is: who controls the cryptographic keys? If a vendor or third party controls the key lifecycle, the utility may be dependent on external processes for one of the most sensitive parts of the system. If HSM choices are restricted by foreign export rules or by vendor limitations, the utility may not be free to choose the security level it considers appropriate. This can directly affect national or regulatory security expectations.
Command integrity is equally important. As smart metering and grid systems move from passive data collection to active control, the ability to verify commands becomes critical. Who issued the command? Was it authorized? Was it modified? Was it executed? Can the entire chain be audited? If these questions cannot be answered clearly, the utility does not fully control the trust layer.
Backup and recovery are another often underestimated part of sovereignty. Many organizations believe they are safe because backups exist. But the real questions are different. Who controls the backup? Is there a secure copy in the hands of the utility? Is the backup protected from the same incident that affects the primary system? Has recovery been tested? How long does restoration take? Which systems can be restored first? Can the utility restore without the same vendor infrastructure that failed?
There have been real incidents where data centers were damaged or became unavailable and organizations discovered too late that their recovery assumptions were wrong. In regions affected by war or physical conflict, data centers and communication infrastructure can become direct targets because they are part of critical infrastructure. For utilities, this is not a remote theoretical scenario. It is part of modern resilience planning.
A sovereign utility must therefore think beyond cybersecurity compliance. It must control the trust chain, understand responsibility boundaries, test recovery procedures, and design redundancy across locations and suppliers.
Strategic sovereignty means that the utility can shape its own future.
This is often decided much earlier than people think. Many sovereignty risks are created in the pre-tender phase, before any vendor is selected and before any implementation starts. Once the tender is published, the possible solution space is already constrained by the requirements, scoring model, architecture assumptions, and commercial structure.
If the tender focuses mainly on price and basic functionality, it may accidentally reward solutions that create long-term dependency. A bidder may offer the cheapest compliant solution while relying on proprietary interfaces, limited APIs, weak multi-vendor support, or a roadmap that the utility cannot influence. On paper, the procurement process was successful. In reality, the utility may have locked itself into a non-sovereign architecture for the next decade.
This is why sovereignty cannot be left only to purchasing departments. Purchasing teams are essential for governance, fairness, and commercial discipline. But they should not define strategic architecture alone. Sovereignty requires input from operations, cybersecurity, regulatory experts, enterprise architecture, long-term grid planning, and executive leadership.
Pre-tender work should answer questions such as: What level of vendor independence do we need? Which standards must be proven, not just claimed? What exit rights are required? What APIs must be documented? How do we evaluate communication technology diversity? What happens if one supplier becomes unavailable? How do we score backup and recovery control? How do we include geopolitical and supply-chain risks? How do we ensure the system can support future flexibility, forecasting, and automation use cases?
The tender should make sovereignty measurable. It should not only ask whether a supplier supports a standard. It should require evidence. It should not only ask whether APIs exist. It should require documentation, scope, and testability. It should not only ask whether backup is available. It should require ownership, restore procedures, and test records.
Strategic sovereignty also includes ecosystem analysis. If there is only one local company capable of supporting a key component, that may look good from a local-content perspective but may create concentration risk. If there is no alternative supplier in the country and international alternatives are not practically usable, then the utility has a dependency that should be recognized explicitly.
Finally, the utility’s technology choices must be checked against the long-term strategy of both the country and the utility. If the national direction points toward flexibility markets, distributed generation, customer participation, or stricter cybersecurity requirements, then the smart metering and grid platform must be ready for that future. Otherwise, the utility buys today’s solution and creates tomorrow’s bottleneck.
Instead of asking whether the software is hosted locally, utilities should ask whether they can still act independently when the environment changes.
Can they access and use all relevant meter and grid data without external delays? Can they operate during vendor outages or degraded connectivity? Can they add a new meter vendor without a major technical dispute? Can they change communication technologies if regulation or geopolitics requires it? Can they inspect, understand, and extend the architecture? Can they control keys, certificates, and command trust? Can they restore from backups that are actually under their control? Can they replace suppliers without rebuilding the full landscape?
These questions are uncomfortable because they expose dependencies that are often hidden behind successful project delivery. But they are necessary. A utility that avoids them may only discover its lack of sovereignty during a crisis, a regulatory change, a cyber incident, or a forced supplier transition.
The more honest question is not: “Do we own the system?” The more honest question is: “Can we control the system’s future?”
Sovereignty is not a product feature. It is not a hosting model. It is not a procurement checkbox.
It is the result of thousands of design decisions across contracts, architecture, operations, data models, interfaces, security processes, supplier structures, and governance. Some of these decisions look small at the time. Later, they determine whether the utility can act independently or must wait for others.
The most dangerous sovereignty risks are often invisible during normal operation. The system runs. The reports are produced. The meters communicate. The invoices are created. Everyone assumes control exists.
But control is only proven when pressure arrives: when a vendor is unavailable, when regulation changes, when a new dataset is needed, when a communications supplier becomes restricted, when a cyber incident occurs, when a data center fails, or when the utility wants to innovate faster than the vendor roadmap allows.
That is why sovereignty must be treated as an end-to-end design principle from the beginning.
Utilities should assess sovereignty earlier, more broadly, and more honestly.
That means looking at the full end-to-end solution: meters, communication technologies, HES, MDM, APIs, data models, cloud or data center setup, key management, backup, recovery, operating model, vendor ecosystem, service contracts, internal capability, and procurement structure.
It also means investing significantly more effort in the pre-tender phase. This is where the real options are created or destroyed. If sovereignty criteria are missing from the tender, they will be difficult to recover later. If price dominates the evaluation, long-term control may be sacrificed before anyone notices.
Sovereignty should therefore be taken out of a purely purchasing-driven process and elevated to a strategic discussion involving operations, IT, cybersecurity, regulation, architecture, and executive management.
Because the future grid will be more digital, more distributed, more automated, and more exposed to external shocks.
In that future, sovereignty will not belong to the utility that simply hosts software locally.
It will belong to the utility that can understand, operate, secure, adapt, and evolve its entire digital grid ecosystem under its own governance.
Control is not given. It is designed.
At Cuculus we have developed a Sovereignty Scoring to get this whole issue into a single number (of course plus some hints how to improve it).
