sovereignty cloud NIS2

Sovereign cloud for IoT platforms

When and how to run an IoT platform on sovereign or national cloud. What changes in architecture, cost, and compliance, and what stays exactly the same.

Poya Shad 2 min read

Sovereign cloud appears in public-sector requirements more often every year. For IoT platforms it raises a practical question: what actually changes when you move a sensor platform to a national or European provider, and what stays the same?

When it genuinely matters

Sovereignty is a legal question before it is a technical one. It matters when the data is subject to secrecy or privacy regulation, when foreign legislation could compel a provider to disclose data, or when continuity requirements rule out dependence on a provider governed outside the EU.

For a municipality’s sensor platform, all three often apply. Energy consumption in public buildings, alarm data, and water network telemetry are operationally sensitive. NIS2 and Sweden’s Cybersäkerhetslag sharpen the continuity requirement. Under the US CLOUD Act, data held by an American provider can be reachable by American authorities regardless of where the data centre sits. An EU region of a US hyperscaler does not remove that exposure. A Swedish provider such as Safespring or Elastx, under Swedish jurisdiction, does.

What changes in the architecture

Less than vendors suggest. A well-built IoT platform is a set of standard components: message ingestion, a time-series store, a relational database, object storage, and an application layer. All of these exist on sovereign providers and on-premises.

Three things do change:

  • Managed services. Hyperscaler platforms offer managed equivalents for everything, and each one adopted is a dependency. On a sovereign provider, you run more of the stack yourself, in containers or on virtual machines.
  • Cost shape. Egress fees and per-service pricing largely disappear. Capacity planning becomes more explicit. For steady sensor workloads, total cost is usually comparable or lower.
  • Operational responsibility. Patching, backups, and monitoring sit with your team or your operating partner. This is work, and it is also the audit trail NIS2 asks for.

What stays the same

The data model, the integrations, the dashboards, and the device management are identical. Sensors do not care where the platform runs. A LoRaWAN network server or an MQTT broker behaves the same on any infrastructure.

This is the point worth holding on to: if moving to sovereign infrastructure requires a rewrite, the platform was built around one provider’s services. That is an architecture finding, and it exists regardless of where you host.

Keep the decision reversible

The strongest position is a platform that can move. Infrastructure defined as code, data in open formats, and containers on standard compute make hosting a decision you can revisit. Start where the requirements point today. Keep the ability to move tomorrow, when the requirements or the providers change.

For the compliance side of this question, our guide to NIS2 for IoT platforms covers what the law requires of a sensor estate. For the ownership side, see what vendor-neutral actually means.

Poya Shad
written by
Poya Shad

Founder of Zero46. Builds sovereign IoT platforms for cities and utilities.

// talk to us

Building something that has to survive production?

Book a 30-minute call and tell us what you're working on. If it fits, we follow with a two-hour working session: architecture sketch, honest scope, no invoice.

Book 30 min