Sovereignty done right makes you resilient. But sovereignty you don’t operate is the opposite: a risk. You move a workload in-house to be more sovereign. Your jurisdiction, your rules, no outside provider in the loop. More control – which is the whole point.

But the provider you left wasn’t only running the service. They were also keeping it up, patching it, and making sure you could still reach it when something broke. You didn’t see that part, because you never had to.

Bring it in-house and now you feel that you have everything under control – except not everything comes in the box. The fail-over, the redundancy, the reaching-it-when-something-breaks: that’s a whole layer you now have to build yourself. And it’s easy to miss, precisely because the provider made it invisible – or to skip, because building it properly is expensive.

If you leave it out (accidentally), then the thing you now control becomes the thing you can’t reach when you need it. That’s the catch. Operational sovereignty can hurt your resilience.

Where it bites

Take a workload off the public cloud and run it yourself, somewhere you control. You gain jurisdictional sovereignty – your data, your laws – and operational sovereignty: your systems, nobody else in the loop. The jurisdictional part is what you were after. But taking over the operation could quietly hurt you if you’re not careful – or cost you, if you are, because rebuilding what the provider supplied for free isn’t cheap.

Take the hyperscaler’s global failover: the machinery that would have shifted your traffic to another region when one went down. Nobody sold you that as a feature; it was just there. Now that you run it yourself, it’s gone, unless you rebuild it. You gained operational sovereignty and lost resilience in the same move.

Same with patching. The hyperscaler shipped updates the day they were ready, across everything, silently. The system you now run gets patched when your team gets to it. Every gap between “available” and “applied” is a window that used to be closed for you, and now isn’t.

Same shape each time. Taking over the running hands you control – and hands you the resilience the provider was quietly supplying, which doesn’t come along for free.

What actually transferred

It helps to see what changed hands. When you depended on the provider, you were buying more than a service. You were buying the fact that keeping it running was their problem. The failover, the patching, the keeping-it-reachable – none of it was on your plate, because they had quietly taken it on. That was the deal, even if it was never written down as such.

Move the capability in-house and you get the capability. You do not automatically get the arrangement around it. The thing that was silently someone else’s job is now silently yours – and “silently” is the danger, because a responsibility you didn’t know you were taking on is one you won’t staff, fund, or plan for.

Control is the easier half of sovereignty. Staying resilient is the harder half – and it often doesn’t automatically transfer with the software.

The same thing, small enough to see whole

To make this more tangible, a clear example from a home network – small enough to see every part at once.

The goal: reach your own network from outside. A managed mesh VPN like Tailscale makes it trivial: an always-on coordination server, plus a relay when a direct link isn’t possible, working even when your line fails over to a backup. But that server and those relays run on the vendor’s infrastructure, in another jurisdiction. Reliable – not completely sovereign.

Self-host it with Headscale and you get the sovereignty. You also hit the trap. The coordination server has to be reachable from the public internet. Fine at home – until your fiber drops and you fail over to 5G, which typically uses CGNAT: a shared address with no way in. The backup kicks in and your server vanishes from the internet, at exactly the moment you need it. The sovereign setup fails where the managed one would have held.

Match the managed service’s reliability and you’re running the coordinator on a permanently reachable host, patching it, standing up your own relay – rebuilding the arrangement you left. Sovereign and resilient is possible. It just means doing, well, all the work the vendor did invisibly.

Match the ambition to the capacity

None of this is an argument against sovereignty. It’s an argument against sovereignty you can’t operate.

The mistake isn’t wanting control. It’s migrating only the obvious part – the license, the jurisdiction, the box – and forgetting the invisible part the provider was carrying: keeping it patched, reachable, recoverable. Sovereignty has a running cost, not just the initial price, and the running cost is where resilience lives: Take on more than you’re willing to staff and fund, and you’ve bought control at the price of the thing control was meant to protect.

Which means the honest question isn’t “how sovereign can we be?” It’s “how much sovereignty can we actually operate?” Sometimes the answer is a well-run dependency with strong guarantees – residency you can verify, controls you can audit, an exit you’ve tested – that turns out to be more sovereign in practice than a system you own but can’t keep running.

Sovereignty done right makes you resilient. Without resilience, sovereignty is just ownership.

Originally published on LinkedIn