The EU Open Source Strategy’s open-source-first principle is a procurement policy commitment that instructs public administrations across EU member states to prefer open-source software when acquiring IT solutions, provided that open-source options meet functional requirements. For compliance officers, CISOs and IT decision-makers in government and regulated sectors, this principle is not merely a political signal. It intersects directly with enforceable obligations under NIS-2 Article 21, the EU Public Procurement Directive 2014/24/EU, and the structural requirements of genuine digital sovereignty.
What the EU Open Source Strategy actually requires
The open-source-first principle, established in the EU Open Source Strategy 2020–2023 and expected to be reinforced in the June 2026 iteration, does not mandate open-source software in all circumstances. It requires contracting authorities to justify why they are not choosing open-source when a suitable option exists. This inversion of the default presumption is operationally significant: procurement teams can no longer treat proprietary software as the neutral baseline.
The European Commission articulated the core commitment clearly in the 2020 strategy document: “Public administrations should, where possible and appropriate, prefer open-source solutions and consider the use of open-source software when procuring IT solutions.” The June 2026 update extends this by addressing interoperability mandates, mandatory publication of publicly funded code, and obligations to contribute back to upstream communities.
Under Directive 2014/24/EU on public procurement, contracting authorities may define technical specifications in functional terms rather than by reference to a specific product or vendor. This is the legal mechanism that makes open-source-first operationally viable: a specification written around capabilities, open standards and interoperability formats creates a level field on which open-source and proprietary solutions compete. Specifying “must support the OpenDocument Format” or “must expose a REST API documented under an open licence” is permissible; writing a specification that only Microsoft 365 can satisfy is not, unless justified on objective grounds.
Open-source auditability as NIS-2 supply-chain evidence
NIS-2 Article 21(2)(d) requires essential and important entities to implement measures addressing supply-chain security, including the security of relationships with direct suppliers and service providers. Open-source software, when properly managed, provides a uniquely documentable supply-chain posture.
A CISO can produce a software bill of materials (SBOM) for an open-source stack, cross-reference every component against the National Vulnerability Database and public CVE records, and demonstrate that patch decisions were made on the basis of publicly disclosed disclosures. Community-driven CVE disclosure means vulnerabilities are surfaced through a transparent, timestamped process rather than held under a vendor’s non-disclosure agreement. Reproducible builds, supported by projects including Debian and increasingly by enterprise distributions, allow organisations to verify that the binary running in production corresponds to the audited source code.
According to ENISA’s 2023 Threat Landscape report, supply-chain attacks targeting software dependencies increased by 40% year-on-year between 2021 and 2022. ENISA’s open-source security guidance recommends that organisations maintain explicit dependency inventories and assign ownership for tracking upstream security advisories. For regulated entities under NIS-2, this guidance provides a practical framework that aligns the open-source review process with Article 21 documentation requirements.
The key procedural step is to formalise this process: assign a named owner for each critical open-source component, record the review of each CVE advisory, and retain the records in a format that can be presented to a supervisory authority. This transforms routine open-source hygiene into auditable compliance evidence.
Distinguishing genuine sovereignty from superficial openness
Running open-source software does not automatically confer sovereignty. The distinction matters because several widely used “open-source” products are developed, signed and distributed by US-controlled entities, or call home to infrastructure subject to the US CLOUD Act and FISA 702. An organisation that deploys an open-source collaboration suite on an AWS or Azure instance operated by a US-parent company has not removed its data from potential foreign jurisdiction reach, regardless of where the data centre sits physically.
| Criterion | Genuinely sovereign deployment | Superficially open deployment |
|---|---|---|
| Infrastructure jurisdiction | EU-based host, EU-controlled legal entity, no US parent | EU data centre operated by US-controlled cloud provider |
| Telemetry and update channels | All outbound calls to EU-controlled endpoints; updates applied from on-premise or EU-hosted mirror | Telemetry phoning home to US vendor servers; automatic updates from non-EU CDN |
| Key management | Organisation retains encryption key custody; HSM or on-premise KMS | Keys managed by cloud provider under provider’s key management service |
| Support and maintenance chain | Support contract with EU-domiciled entity, no mandatory data sharing with non-EU parent | Support routed through US or non-EU parent company with contractual data access |
Nextcloud, developed by Nextcloud GmbH in Stuttgart, is a concrete example of a platform that can satisfy all four criteria. The source code is published under the AGPL licence, the company is EU-domiciled, and deployments can be operated entirely on-premise or on EU-controlled hosting without mandatory telemetry to Nextcloud GmbH’s infrastructure. What matters is that the deployment is configured and hosted in a way that preserves those properties.
Government migrations as reproducible templates
The Schleswig-Holstein open-source migration programme offers one of Europe’s most documented procurement and change-management references. The state announced in 2021 a migration of approximately 25,000 government workstations from Microsoft Windows and Office to Linux, LibreOffice and Nextcloud. The programme explicitly cited digital sovereignty, reduced licence costs, and avoidance of vendor dependency as the justifying criteria. The procurement process was structured around functional specifications and open standards, which allowed the tender to be defensible under Directive 2014/24/EU without naming specific proprietary products.
The Austrian Federal Ministry for Climate Action, Environment, Energy, Mobility, Innovation and Technology (BMWET) deployed Nextcloud as a document collaboration platform for internal use, providing another public-sector reference for organisations assessing procurement risk. Both cases demonstrate a consistent pattern: functional specifications built around open standards, phased rollout with parallel operation, investment in user training, and migration tooling that preserves file permissions and metadata.
For organisations planning a comparable migration, particularly one replacing Microsoft 365 or Google Workspace, the Schleswig-Holstein experience highlights that change management and interoperability testing consume more project time than the technical migration itself. Retaining permission structures, version history and calendar data during migration requires dedicated tooling and advance mapping of data schemas.
The EU Open Source Maintenance Instrument and dependency risk
The EU Open Source Maintenance Instrument, operating through the European Commission’s Open Source Programme Office and connected to the Next Generation Internet initiative, funds structured security audits of critical open-source components that are widely used but under-resourced. The Log4Shell vulnerability of December 2021 demonstrated that a single unmaintained library embedded in thousands of enterprise deployments can produce systemic public-sector exposure. ENISA’s dependency analysis work specifically addresses this risk by mapping which open-source components underpin multiple member-state digital infrastructures.
For sovereign deployments, the practical implication is that relying on a component covered by the Maintenance Instrument provides a degree of documented assurance: audits are conducted, findings are published, and remediation timelines are tracked. Procurement teams should include in their due-diligence documentation a check of whether critical dependencies fall within the Instrument’s scope, and if not, whether alternative funded audit programmes (such as those run by the Linux Foundation’s Core Infrastructure Initiative) provide equivalent assurance.
The European Commission’s study on the economic impact of open-source software found that open-source contributed between €65 billion and €95 billion to the EU economy in 2018, with a return of approximately four euros for every euro of investment. That figure provides a policy-level argument for maintenance investment, but for individual organisations it also means that the collective maintenance infrastructure supporting major open-source projects is proportionally robust compared to niche proprietary components.
Documenting the procurement decision for legal robustness
A formal procurement file for an open-source sovereign choice must survive potential challenge under EU and national procurement law. The documentation burden is not higher than for proprietary procurement, but it is different. Three elements are essential.
First, the technical specification must be written in functional and standards-based terms, with explicit reference to open standards such as OpenDocument Format, CalDAV, CardDAV and WebDAV where relevant. This is permissible and encouraged under Directive 2014/24/EU and removes the basis for a challenge that the specification was written to exclude competitors.
Second, the total-cost-of-ownership calculation must be documented comprehensively. The TCO should include avoided licence fees over the contract period, migration and integration costs, ongoing maintenance (whether internal or contracted), training, and a quantified estimate of vendor lock-in risk. Lock-in risk can be monetised by estimating the cost of a future forced migration if the proprietary alternative changes terms or is discontinued. The Commission’s impact study and ENISA reference figures provide citable independent benchmarks.
Third, the supply-chain due-diligence record under NIS-2 Article 21(2)(d) should be cross-referenced in the procurement file. Demonstrating that the chosen open-source stack was evaluated against a structured dependency and CVE review process strengthens both the security case and the procurement justification simultaneously.
FAQ
Does the EU Open Source Strategy legally bind public administrations to choose open-source software?
The Strategy sets a political and policy commitment, not a hard legal obligation in itself. However, the open-source-first principle is increasingly embedded in national transpositions and procurement guidelines, and it operates alongside Directive 2014/24/EU, which permits functional technical specifications that open-source products can meet on equal footing with proprietary alternatives.
How does choosing open-source software help satisfy NIS-2 Article 21(2)(d) on supply-chain security?
Open-source code can be inspected, audited and independently verified. A CISO can document a software bill of materials, reference public CVE records, and demonstrate that dependency updates were reviewed, providing auditable evidence that supply-chain risks were actively managed. This is precisely what NIS-2 Article 21(2)(d) requires of essential and important entities.
What makes a Nextcloud deployment sovereign rather than just open-source?
True sovereignty requires that the software runs on infrastructure physically and legally located in the EU, operated by an EU-controlled entity, with all telemetry and update channels confined to EU-controlled servers. Running open-source software on infrastructure operated by a US-parent-owned provider does not remove exposure to the US CLOUD Act, even if the software licence is open.
How should a procurement officer document a total-cost-of-ownership argument for open-source in a formal tender?
The TCO calculation should include: licence fees avoided over the contract period; integration and migration costs; internal or contracted maintenance; training; and a monetised estimate of vendor lock-in risk, such as the projected cost of a future forced migration. ENISA and the European Commission’s impact study provide reference figures that can be cited as independent evidence in the procurement file.
What is the EU Open Source Maintenance Instrument and why does it matter for sovereign infrastructure?
The EU Open Source Maintenance Instrument funds security audits and maintenance of critical but under-resourced open-source components. For sovereign deployments, it provides structured assurance that foundational libraries receive scrutiny, reducing the risk that a neglected dependency becomes a systemic vulnerability across multiple public-sector deployments, as happened with Log4Shell in 2021.