"Digital sovereignty" is a phrase that attracts a great deal of posturing. Underneath it sits a legitimate engineering question with concrete answers, and here at AxisOps we'd rather talk about that one.
The question, stated usefully¶
The question is not "is it built here". That's industrial policy, a different argument for a different room.
The engineering question is: which capabilities that we depend on could be withdrawn or compelled by a party outside our control, and what is our position if that happens?
Ask it that way and flag-planting becomes dependency analysis, which engineers can sit down and do on a Tuesday afternoon.
The layers, by difficulty¶
Data location. The easiest, the most discussed and nowhere near enough on its own. Data in a local region is still subject to the operator's home jurisdiction in various circumstances. Necessary; not sufficient.
Operator access. Who can read it. This is where confidential computing makes a real contribution, though it moves the trust to the silicon vendor rather than removing it, and silicon vendors are concentrated in a handful of jurisdictions.
Software supply. If a licence can be revoked or an update withheld, your software is a dependency on a continuing commercial relationship. A licence that can't be revoked, over source that can be forked, is a different risk class even if you never fork a line of it.
Silicon. The hardest layer, with no near-term answer. Leading-edge fabrication is concentrated in very few places and the supply chain underneath it is more concentrated still. RISC-V addresses the specification layer, which matters, and does nothing whatever about fabrication.
Operational capability. The layer everybody ignores. The right to run something is worthless without people who can run it. A sovereign stack nobody can operate is a worse position than a dependency you've written down.
Why open source does real work here¶
Not for ideological reasons; think of it as who holds the keys to the garage. A proprietary dependency is a relationship with a company that can change its terms, get acquired, leave the market or find itself on the wrong end of an export control. Recovering from any of that needs their cooperation.
An open-source dependency can be forked. You may never do it, but the capability changes both your negotiating position and your worst case, without a nation-state-scale programme.
What a graded answer makes possible¶
The useful version of sovereignty is the ability to survive a withdrawal. Independence does not come into it. That is achievable for one organisation, and the effects are larger than the phrase suggests.
Take a hospital trust. Today a change in a software vendor's licensing, or a dispute between two governments, is an event it can only absorb. With the stack declared, the data in documented formats and the ability to run it on hardware in the building, the same event becomes a procurement decision taken at a time of its own choosing. What becomes cheap is continuing to work during an argument you are not a party to.
Scale that up and it changes what a mid-sized country can plan. The sovereign posture most are reaching for is a hyperscaler region with a local flag on it, because the alternative looks like building everything. The achievable middle is an estate where the critical services are declared, the formats are open, the software is forkable, and the operational knowledge sits with people on the payroll: an engineering programme with a budget rather than a decade-long industrial fantasy.
The benefit to engineering itself is the one we feel most directly. A stack rebuildable from source and configuration can be stood up again after a disaster, moved between providers and handed to a new team intact. The toil that disappears is archaeology: the week spent discovering how production was assembled because the people who assembled it have moved on and the console is the only record.
Vendors blur the definition at the point where it becomes inconvenient. A hyperscaler region inside your borders, operated by a local subsidiary with local staff and a reassuring certification, is marketed as sovereign. Test it with one question: if the parent company were ordered by its home government to withdraw the service, could the region keep running? If the answer needs the parent's control plane, identity service, software updates or key management, you have a datacentre location rather than sovereignty. The dependency is the control plane, and it has never been in your jurisdiction.
The two are priced similarly and sold interchangeably. A sovereign deployment means software licensed in a way that survives the relationship ending, operational knowledge held locally and somebody who can rebuild it from the artefacts on hand. That is harder to buy and easier to verify: ask for the rebuild to be demonstrated. Nobody demonstrates it, which tells you how often it has been tested.
What concentrates power sits a layer above the datacentre. Identity above all: an estate where every employee signs in through one provider's directory has handed that provider the ability to stop the organisation working, and no amount of local hosting touches it. Then the egress charges that make leaving expensive at the moment you need to, and the certificate and DNS dependencies nobody listed. Each was a sensible decision, and collectively they are a sovereign commitment no minister ever signed.
The open side is better placed on this question than on almost any other: the whole stack for a serious estate can be assembled from components nobody can revoke. What is scarce is operational capability, a training and staffing problem, and it is the layer that gets cut first. The real risk is that nobody is left who can run it, not that the open version loses on merit.
Here at AxisOps this is the position we build from: infrastructure the customer owns, can inspect and can rebuild without us in the room. We would rather hand over something you could fork than something you have to keep paying for.
The limits¶
Full independence isn't achievable for any organisation, and it's achievable for very few countries. Anyone promising it to you is selling something.
What you can have is a graded answer: know your dependencies, know which are replaceable and on what timescale, reduce the ones where the recovery story is "we'd be stuck" and accept the rest as a decision rather than an oversight.
It's the same discipline as knowing your dependency graph for availability. Same graph, read for a different failure mode.