Kim Loohuis recently shared something that caught my attention: Europa wil digitaal onafhankelijk zijn, maar blijft steken in fragmentatie. Terwijl Amerikaanse techreuzen als AWS en Microsoft een geintegreerd platform bieden, heeft Europa een losse verzameling leveranciers. En de quote die blijft hangen is van Kevin Brown: "Een lijst van leveranciers is geen platform."

That short observation captures a big European dilemma. We talk a lot about digitale soevereiniteit, but day-to-day procurement and architecture still look like a catalog. You can buy "European" components, but you cannot easily assemble them into something that behaves like a coherent platform with consistent identity, security, APIs, operations, and accountability.

In this post-turned-article, I want to expand on Kim’s point, because the real question is not just whether an organization should choose Teams or Nextcloud. As Kim Loohuis put it: de vraag is niet "Teams of Nextcloud", maar: wie durft de standaarden te bepalen waaraan alle Europese diensten zich moeten houden?

A catalog is not a platform

Kim Loohuis’s framing is sharp because it separates two things that are often mixed up:

A supplier list (many providers, many offerings)
A platform (an integrated experience with shared rules)

A platform is not one vendor. It is a set of architectural promises that make services composable and predictable. When AWS sells you compute, identity, networking, logging, policy, key management, and monitoring, those parts are designed to work together. That integration is not just convenient. It reduces risk, reduces operational overhead, and makes adoption faster.

Europe’s "loose collection of suppliers" can be innovative, competitive, and aligned with European values, but it becomes painful when every component has different identity models, inconsistent auditability, divergent SLAs, and incompatible management tooling.

"Een lijst van leveranciers is geen platform."

If Europe wants sovereignty to be more than a slogan, it needs to compete on platform outcomes, not just on the nationality of vendors.

What "digital sovereignty" actually requires

Digital sovereignty is sometimes interpreted as "keep data in the EU" or "use EU vendors." Those can be parts of the picture, but they do not guarantee control.

Practical sovereignty looks more like this:

Portability by design: ability to move workloads and data without a re-architecture every time.
Interoperability by default: shared standards so services can plug together.
Operational independence: the ability to run, secure, and maintain systems without depending on a single foreign control plane.
Legal and governance clarity: clear rules about who can compel access, who holds keys, and what happens during disputes.
Resilience against market events: what happens if a provider gets acquired, reprices, or changes strategy.

Kim Loohuis highlights a vulnerability that is often ignored: even a well-intended European solution can become fragile if it can be bought.

The acquisition problem: sovereignty without protection is brittle

Kim references Bert Hubert’s warning: without structural protection against overnames (like Solvinity being acquired by Kyndryl), every "European" solution remains vulnerable.

This is not a moral judgment about acquisitions. It is an architectural risk.

If a critical supplier is acquired, several things can change quickly:

Decision-making moves outside the ecosystem
Product roadmaps shift toward global priorities
Support models and pricing change
Compliance posture and data processing chains evolve
The service may become strategically deprioritized

Sovereignty is therefore not just technical. It is also economic and political. If Europe wants independent digital infrastructure, it needs mechanisms that reduce the probability that key building blocks are absorbed or hollowed out.

What could that look like in practice?

Public procurement that favors open standards and exit plans, not just lowest price
Strategic funding for critical infrastructure, tied to governance requirements
Golden-share or mission-lock models for essential providers (carefully designed)
Preference for open-source plus European operational control, where feasible

None of these are simple. But ignoring the acquisition dynamic means building on sand.

Bright spots: Nextcloud and LibreOffice are signals, not the end state

Kim Loohuis mentions concrete examples that matter: an Austrian ministry choosing Nextcloud, and Schleswig-Holstein choosing LibreOffice. These are important because they show that institutions are willing to pick alternatives that increase control and reduce dependency.

But Kim also names the limitation: without a common architecture, these are "eilanden van soevereiniteit".

That phrase is useful because it explains why many pilots do not scale.

One ministry modernizes collaboration tooling.
Another moves file sharing.
A region standardizes on an office suite.

Yet each initiative solves a local problem, not the systemic one: how to make these choices interoperable across agencies, borders, and vendors while maintaining security and manageability.

A single island can be sovereign, but islands still need shipping lanes, maps, and rules of navigation.

The real debate: standards, not tools

I agree with Kim Loohuis that "Teams or Nextcloud" is a distracting binary. Tools come and go. Standards are what enable ecosystems.

So what standards would actually turn a European catalog into a European platform?

Identity and access standards (the backbone)

If users and services cannot authenticate and authorize consistently, everything else becomes custom integration.

What to standardize:

Federation (SAML, OIDC)
Fine-grained authorization (policy-as-code approaches)
Lifecycle (provisioning and deprovisioning, SCIM)
Audit trails (who did what, when)

Data portability and APIs (exit without drama)

Sovereignty includes the ability to leave.

What to standardize:

Data export formats for common domains (documents, email, calendars, files)
Baseline API expectations (versioning, rate limits, auth)
Reference migration patterns and tooling

Security baselines and certification (trust at scale)

A platform needs shared minimum guarantees.

What to standardize:

Logging and observability requirements
Encryption requirements (at rest, in transit, key ownership)
Vulnerability disclosure and patch SLAs
Incident reporting rules

Operational interoperability (the missing piece)

Even if interfaces work, operations often do not.

What to standardize:

Backup and restore requirements
Disaster recovery metrics (RPO, RTO)
Monitoring and alerting integrations
Support and escalation models

Who gets to set the standards?

Kim’s closing question is the uncomfortable one: who dares to define the standards that all European services must meet?

There are risks in standard-setting:

Too rigid, and innovation slows.
Too vague, and nothing changes.
Too political, and outcomes are compromised.

But the absence of standards is also a decision. It defaults Europe into dependency on the most integrated foreign platforms.

A workable approach is layered:

Define a small set of mandatory baseline standards (identity, security, portability).
Create reference architectures for common public-sector use cases.
Offer conformance testing and certification that is transparent and repeatable.
Encourage multiple implementations so no single vendor becomes the new bottleneck.

This is where open-source can help, not as ideology, but as a practical accelerator. Open interfaces plus reference implementations reduce integration cost and lock-in.

What organizations can do now

Even without a continent-wide blueprint, individual organizations can make choices that align with Kim Loohuis’s message.

Procure outcomes, not brands: require interoperability, exportability, and documented exit plans.
Demand standards support: OIDC, SAML, SCIM, robust APIs, and auditability should be non-negotiable.
Architect for substitution: design so components can be swapped without rewriting everything.
Assess acquisition risk: ask what happens if the vendor is bought, changes jurisdiction, or sunsets a product.
Join coalitions: shared requirements across agencies create leverage and consistency.

Closing thought

Kim Loohuis’s post resonated because it cuts through the noise. Europe does not need another spreadsheet of "approved suppliers." It needs a shared platform logic: standards, governance, and architectural coherence that make sovereign choices scalable.

If Europe can align on the rules of the road, the market can still be diverse. In fact, standards are what make diversity usable.

This blog post expands on a viral LinkedIn post by Kim Loohuis, Tech & Business Content Writer | Journalist bridging complexity and clarity. View the original LinkedIn post ->