Digital sovereignty.
A misuse of terms,
or marketing bullshit?

PERSPECTIVE 01

A flag on a server rack does not answer many questions.

Picture the scene. A cloud floats across a presentation slide. A flag appears. Someone says "sovereign", and the room is apparently supposed to feel safer. I usually feel the urge to ask who holds the keys, who can deploy an update, and how we leave. Admittedly, this makes me less fun at product launches.

My position is straightforward: much of what gets sold as digital sovereignty is a misuse of terms, dressed up as commercial reassurance. Sometimes, marketing bullshit is the most economical description. A serious concern about dependency becomes an adjective attached to a product, with remarkably little explanation of what the customer actually controls.

I would rather talk about technological independence and freedom. They lead me towards useful questions: can we understand this system, operate it, change it, repair it and move away from it? That is a conversation worth having, preferably before the renewal invoice arrives.

PERSPECTIVE 02

The policy question is real. The sales shortcut is the problem.

Digital sovereignty does have a meaning in public policy. The European Commission describes tech sovereignty in terms of Europe's ability to act independently and control important technologies, data and infrastructure. Strategic dependencies deserve scrutiny. Dismissing the discussion would be as lazy as putting a flag on every slide.

My objection begins when that policy ambition becomes an unexplained product promise. A state, an organisation and a software package do not exercise the same powers. A subscription gives a company neither the authority of a state nor freedom from global dependencies. The word needs a scope and a verifiable claim.

If a supplier means local hosting, say local hosting. If it means a particular legal structure, say which one. If it means control of encryption keys or an independently operable deployment, demonstrate it. A precise, limited commitment is much more useful to me than a magnificent adjective doing the work of an architecture document.

Further reading: European Commission: tech sovereignty.

PERSPECTIVE 03

Your infrastructure has a longer family tree than the brochure.

Follow a service down through its application, libraries, runtime, operating system, firmware and hardware. Then look sideways at the build system, package repositories, identity provider, DNS, certificate authorities, monitoring and support arrangements. Even a modest deployment can depend on people and organisations spread across the world. The server's postal address is only one entry in that map.

International collaboration helps make modern computing possible. The useful task is to identify which dependencies are critical, who controls them, how they can fail and what alternatives exist. An inventory beats a fantasy of self-sufficiency.

Independence is therefore something to build in degrees. We can reduce a dangerous concentration, replace a proprietary interface or retain the ability to operate during a supplier outage. Declaring the whole stack sovereign after changing the invoice address is a rather ambitious shortcut.

PERSPECTIVE 04

Location matters. So do the keys, contracts and people.

Where data is processed matters. Applicable law, contractual commitments, administrative access and the organisations operating a service deserve careful examination. Geography cannot carry the whole argument while technical details hide behind the curtain.

Take encryption. Useful questions include who generates the keys, where they are stored, who can recover them and whether administrators can access data during processing. The phrase "encrypted in Europe" answers very few of those questions on its own. A nearby open-source deployment still needs patching and access controls.

There are substantive assurance schemes. ANSSI's SecNumCloud qualification addresses technical, operational and legal requirements for cloud services. Its defined scope is a useful distinction from a self-awarded badge. A qualification, a hosting location and a marketing slogan are three different things to assess.

Further reading: ANSSI: cloud security and qualification.

PERSPECTIVE 05

Freedom should survive contact with the terminal.

The free software movement offers a useful foundation: the freedoms to run a program, study and change it, redistribute copies, and share modified versions. Source access is central to studying and modifying the program. They concern freedom, not a promise that engineering has no cost.

Those rights need an operational counterpart. Can your team build the published source? Are dependencies identified? Are configuration formats documented? Can another maintainer understand the release process? A repository full of code is valuable, but it does not magically provide a working build environment, an upgrade path or someone to answer the pager.

My preferred test is to imagine the original supplier becoming unavailable. Could a capable team keep the service running and maintain it without asking permission from a vanished control panel? Keeping a realistic route forward still requires skills and money. Freedom that exists only in a licence while the necessary machinery remains inaccessible is difficult to exercise.

Further reading: GNU: the free software definition.

PERSPECTIVE 06

The most convincing feature might be a working exit.

Even an excellent supplier relationship deserves an exit plan. Staff change, products disappear, prices move and strategies evolve. Technological independence means retaining choices when those changes happen. Nobody buys a building because they plan to evacuate it every Tuesday, but checking the exits remains a sensible habit.

Ask for a complete export in documented formats. Include the configuration, identities, policy, history and metadata needed to make the data useful elsewhere. Measure how long extraction takes, what it costs and what cannot be transferred. An opaque export archive is hardly a migration plan.

Then rehearse a restore or migration into an environment your team controls. Record the manual steps, missing features and remaining dependencies. This is where interoperability becomes observable. Two providers running behind the same mandatory identity service may still share a critical point of failure. Count the dependencies that matter, rather than the logos on the diagram.

PERSPECTIVE 07

Security deserves evidence, even when the branding is excellent.

Independence and security support each other, but neither guarantees the other. A system can be easy to move and badly protected. Another can have strong security controls while being expensive to leave. Treating both questions separately makes the final decision clearer. A national colour palette cannot review a pull request, however carefully you arrange the gradients.

For security software, I want to see which behaviour was tested, on which version, in which environment and with what result. Did the policy reach the enforcement layer? Was an expiry observed? Was recovery exercised? Signed artifacts help verify origin and integrity; they do not, by themselves, prove that every promised behaviour works.

This is also why honest limits matter. A report that states what it observed, what it did not exercise and which dependencies remain gives operators something they can act on. Confidence grows from repeatable checks and clear responsibilities. A reassuring badge cannot supply missing facts.

PERSPECTIVE 08

For SysWarden, this starts with choices I can explain.

SysWarden began with a practical desire: bring my Data-Shield IPv4 blocklists into Linux kernel filtering. I wanted a tool I could understand and operate. I did not begin with a plan to defeat CrowdSec or every other security project. Technological freedom includes choosing a different approach without pretending that everyone else's work should disappear.

As the project grows, the responsibility grows with it. Public source, documented installation paths, explicit configuration, reviewable changes and evidence about enforcement all contribute to operator control. They require continual work. The same standard should apply to my project as to any product I question in this article.

Working with BunkerWeb fits that philosophy. Two French open-source projects can connect application-facing protection and host-level analysis while keeping their responsibilities clear. Their origin is part of their story; the integration earns its value through useful behaviour. Independence leaves room for cooperation, shared knowledge and deliberately chosen dependencies.

PERSPECTIVE 09

Open source needs a maintenance budget, too.

There is a slightly awkward detail in every discussion about independence: somebody has to do the work. Reviewing patches, maintaining documentation, reproducing failures and preparing releases takes sustained effort. Removing a licence fee from a spreadsheet does not remove maintenance costs from the world. They usually land on a person.

The European Commission links open source with interoperability and reduced lock-in. Making that ambition durable also means supporting the people who build and maintain the components. Funding, useful contributions, paid support and responsible upstream participation can all strengthen the ecosystem we depend on.

For SysWarden, financial support helps make room for testing, maintenance and documentation alongside future development. If the project is useful to you, supporting it through PayPal is one concrete contribution. Bug reports, careful reviews and documentation improvements matter too. Freedom becomes more credible when the people maintaining it can afford to continue.

Further reading: European Commission: open-source strategy.

PERSPECTIVE 10

Less ceremony. More control.

So, is digital sovereignty a misuse of terms or marketing bullshit? In much of the product language I encounter, I think it is. The underlying questions about power, dependence and continuity deserve better than an elastic label. I prefer technological independence and freedom because I can connect them to rights, architecture, skills and practical tests.

Next time it appears in a proposal, ask what you can inspect, operate, change, recover and leave. Ask for the limits as well as the promises. A supplier with good answers should welcome the discussion. And if the entire demonstration still consists of a flag on a cloud, perhaps ask for the architecture diagram before ordering the matching mug.