De Open Internet Stack is een initiatief van de Europese Commissie om een gedeeld, herbruikbaar palet van open-sourcecomponenten samen te stellen waarmee overheden en gereguleerde organisaties digitale diensten kunnen bouwen zonder afhankelijk te worden van niet-Europese hyperscalers. Het Interoperable Europe Portal, het voormalige Joinup-platform, fungeert daarbij als de praktische catalogus: een doorzoekbare database van gevalideerde bouwstenen voor soevereine IT-inkoop.
Wat is de Open Internet Stack en waarom bestaat het?
Het initiatief vloeit voort uit de Europese Open Source Strategy 2020-2023 en de bredere Digital Decade-doelstellingen. De kern van de gedachte is dat Europese publieke organisaties telkens dezelfde problemen oplossen, maar elk afzonderlijk: een gemeente in München selecteert een samenwerkingstool, een rechtbank in Warschau doet hetzelfde en een toezichthouder in Amsterdam begint opnieuw. De Open Internet Stack wil die redundantie doorbreken door een gedeelde catalogus te bieden die als vertrekpunt dient, niet als eindbestemming.
Het Interoperable Europe Portal combineert drie functies: publicatie van herbruikbare oplossingen, beoordeling van volwassenheid via gestandaardiseerde indicatoren, en een samenwerkingsruimte voor overheden die willen co-financieren of co-ontwikkelen. Artikel 20 van de Commissie-beslissing over ICT-gebruik door EU-instellingen (CADA artikel 20) verankert juridisch dat instellingen actief moeten overwegen of open-sourcealternatieven beschikbaar zijn voordat zij kiezen voor gesloten software.
Meer dan 70% van de Europese overheidsorganisaties gebruikt al open-source software in ten minste één onderdeel van hun IT-infrastructuur (Europese Commissie, Open Source Observatory/OSOR, 2023). Tegelijkertijd beheersen Amazon, Microsoft en Google samen ruim 65% van de Europese publieke cloudmarkt (CERRE/Analysys Mason, 2023). Die twee cijfers illustreren het spanningsveld: open source wordt gebruikt, maar de hostinglaag blijft geconcentreerd bij niet-Europese partijen.
Hoe wordt soevereiniteit beoordeeld in de EU-catalogus?
Opname in het Interoperable Europe Portal is geen garantie van soevereiniteit; het is een startpunt voor beoordeling. Inkopers gebruiken een combinatie van drie toetsingskaders.
SEAL-score en volwassenheidsmodel
De SEAL-methodiek (Solution Evaluation and Assessment Layer) beoordeelt een oplossing op technische documentatie, licentiehelderheid, onderhoudscontinuïteit en interoperabiliteit. Een hoge SEAL-score betekent dat een component stabiel is en breder inzetbaar, maar zegt nog niets over de juridische herkomst van de beheersorganisatie of de hostinglocatie.
CRA-conformiteit en SBOM
De Cyber Resilience Act, die in 2024 definitief is vastgesteld, stelt dwingende eisen aan producten met digitale elementen. Voor open-sourcecomponenten die commercieel worden ingezet, is een Software Bill of Materials (SBOM) vereist: een gestructureerde inventarislijst van alle afhankelijkheden. Inkopers controleren of een component in de catalogus een actuele SBOM beschikbaar stelt en of de beheerder een vulnerability disclosure-beleid hanteert dat aansluit bij de CRA-vereisten. Componenten zonder SBOM zijn formeel niet CRA-conform en vormen daarmee een nalevingsrisico onder NIS-2.
NIS-2 vergroot het aantal verplichte entiteiten in de EU van circa 10.000 onder NIS-1 naar naar schatting meer dan 160.000 (Europese Commissie, NIS-2 impactanalyse, 2022). Dit betekent dat honderdduizenden organisaties voor het eerst systematisch hun leveranciersketen moeten valideren, inclusief de open-sourcecomponenten die zij gebruiken.
Jurisdictiecheck
Een component kan volledig open source zijn en toch juridisch riskant als de beheerorganisatie onder de Amerikaanse CLOUD Act of de Patriot Act valt. Inkopers controleren daarom de rechtspersoon achter de release-autoriteit: staat die in de VS, in de EU, of in een derde land met een adequaatheidsbesluit? Dit is geen automatische afwijzingsgrond, maar vereist expliciete documentatie in het inkoopdossier.
Welke componenten zijn al gevalideerd en waar zitten de lacunes?
Het Interoperable Europe Portal bevat honderden oplossingen, maar de mate van validatie varieert sterk.
| Component | Categorie | Status in catalogus | Bekende lacune |
|---|---|---|---|
| Nextcloud Server v33 | Bestandsbeheer, werkplek | Gepubliceerd, hoge SEAL-score | Geavanceerd S/MIME-sleutelbeheer op schaal |
| Matrix-protocol / Element | Gefedereerde messaging | Gepubliceerd, referentie-implementaties beschikbaar | End-to-end-versleuteling bij grote federaties complex te beheren |
| OpenVPN / WireGuard | Netwerktoegang | Gepubliceerd | Post-quantum-uitbreidingen nog niet standaard |
| Drupal | Contentbeheer | Gepubliceerd, breed ingezet door EU-instellingen | Geen inherente soevereiniteitswaarborg voor hostingkeuze |
| Privé AI (on-premise LLM) | Kunstmatige intelligentie | Beperkt; enkele pilots zichtbaar | Geen gestandaardiseerde catalogusvermelding voor lokale LLM-stacks |
| Veilige e-mail (volledige stack) | Fragmentarisch (Postfix, Dovecot afzonderlijk) | Geen geïntegreerde soevereine e-mailsuite met sleutelbeheer |
Videoconferentie is een bijzonder gevoelig gebied: Jitsi Meet is beschikbaar maar vereist een zorgvuldig geconfigureerde eigen server. Commerciële varianten van open-source videodiensten worden regelmatig gehost op Amerikaanse infrastructuur, waardoor de juridische bescherming die de broncode biedt, teniet wordt gedaan door de hostinglocatie.
Integratie met CADA-soevereiniteitsniveaus en het Cloud Sovereignty Framework
De Open Internet Stack staat niet op zichzelf. Organisaties die een coherente leveranciersbeoordeling willen uitvoeren, combineren de catalogus met twee aanvullende kaders.
Het EUCS-schema van ENISA (European Union Cybersecurity Certification Scheme for Cloud Services) kent drie niveaus: Basis, Substantieel en Hoog. Alleen het niveau Hoog sluit extraterritoriale wettelijke toegang door niet-EU-autoriteiten volledig uit als toelaatbaar risico. CADA artikel 20 richt zich op de softwarekeuze; het EUCS-schema beoordeelt de hostingomgeving. Samen bieden ze een tweelaags toetsingsmodel: eerst de component zelf via de catalogus, dan de hostinginfrastructuur via het EUCS-schema.
Thierry Breton, voormalig Eurocommissaris voor de Interne Markt, verwoordde het zo: “Open source is geen kostenpost maar een strategische troef: wie de broncode beheert, beheert zijn eigen digitale soevereiniteit.” (Europese Commissie, Open Source Strategy 2020-2023). Margrethe Vestager voegde daar bij de presentatie van de CRA aan toe: “De Cyber Resilience Act stelt voor het eerst dwingende eisen aan de beveiliging van producten met digitale elementen gedurende hun volledige levenscyclus, inclusief open-sourcecomponenten die commercieel worden ingezet.” (Europese Commissie, CRA-wetgevingsdossier).
Praktische migratiestappen: van Microsoft 365 naar een soevereine werkplek
Voor een compliance officer die de EU open-sourcecatalogus wil gebruiken als vertrekpunt voor een migratie van Microsoft 365 naar een soevereine werkplek, is een gefaseerde aanpak effectiever dan een big bang.
Stap 1: Breng de risicovolle diensten in kaart
Begin niet met technologie maar met data. Welke categorieën gegevens verwerkt de organisatie, en welke vallen onder GDPR, NIS-2 of sectorspecifieke regelgeving? Teams, SharePoint en Exchange verwerken doorgaans zowel gewone bedrijfsdocumenten als bijzondere persoonsgegevens en mogelijk vertrouwelijke juridische of bestuurlijke stukken. Prioriteer de migratie op basis van gevoeligheidsklasse, niet op basis van gebruikersaantallen.
Stap 2: Raadpleeg de catalogus per functiegebied
Open het Interoperable Europe Portal en zoek per functie: bestandsbeheer, chat, videoconferentie, e-mail, identiteitsbeheer. Noteer voor elke kandidaatoplossing de SEAL-score, de beschikbaarheid van een SBOM, de beheerorganisatie en haar jurisdictie. Nextcloud Server v33 en Matrix/Element dekken de kernfuncties van een werkplek; voor e-mail zijn aanvullende componenten nodig die afzonderlijk beoordeeld moeten worden.
Stap 3: Leg het twee-laags toetsingsmodel aan
Combineer de catalogusbeoordeling met een EUCS-toets voor de hostingomgeving. Als de organisatie kiest voor on-premise of voor een Zwitserse hoster buiten de reikwijdte van de CLOUD Act, documenteer dan expliciet waarom dit niveau van hostingsoevereiniteit is gekozen en hoe het aansluit bij de risicoklasse van de verwerkte gegevens.
Stap 4: Valideer CRA-conformiteit en SBOM
Vraag de leverancier of de beheerder van de gekozen open-sourcecomponent om een actuele SBOM. Controleer of er een gepubliceerd vulnerability disclosure-beleid is en hoe snel kritieke patches worden uitgebracht. Dit is niet alleen een technische controle maar ook een contractuele verplichting onder NIS-2 voor organisaties die als essentiële of belangrijke entiteit worden aangemerkt.
Stap 5: Migreer gefaseerd en documenteer afwijkingen
Start met een pilotgroep van gebruikers die minder afhankelijk zijn van specifieke Microsoft-integraties. Documenteer elke afwijking van de catalogusaanbeveling en elke tijdelijke uitzondering in het verwerkingsregister. Dit creëert een auditspoor dat zowel intern als naar toezichthouders transparantie biedt over de voortgang van de migratie.
Resterende uitdagingen en aandachtspunten
De Open Internet Stack-catalogus lost niet alle problemen op. De kwaliteit van vermeldingen is ongelijkmatig: sommige componenten zijn uitgebreid gedocumenteerd met SBOM en auditrapportages, andere zijn slechts summier beschreven. Organisaties in sterk gereguleerde sectoren, zoals advocatuur, gezondheidszorg of nationale veiligheid, hebben aanvullende sectorspecifieke vereisten die de catalogus niet altijd weerspiegelt.
Post-quantum-beveiliging is een groeiend aandachtspunt dat in de huidige catalogus nog onvoldoende is gedekt. NIST heeft in 2024 de eerste definitieve post-quantum-standaarden gepubliceerd (FIPS 203, 204 en 205), maar de integratie van deze algoritmen in populaire open-sourcecomponenten zoals OpenVPN en Nextcloud is nog in een vroeg stadium. Compliance officers die een tijdshorizon van vijf jaar of meer hanteren, doen er verstandig aan dit als eis op te nemen in hun leveranciersbeoordelingen.
Lokale AI-stacks, waarbij een taalmodel volledig on-premise draait en nooit traint op klantgegevens, zijn in de catalogus nauwelijks vertegenwoordigd. Dit is een reëel gat: organisaties die AI-functies willen toevoegen aan hun soevereine werkplek, moeten momenteel buiten de catalogus zoeken naar oplossingen als Ollama, LocalAI of vergelijkbare projecten, en die zelf beoordelen aan de hand van de SEAL-criteria en CRA-vereisten.
FAQ
Wat is het verschil tussen de Open Internet Stack en het Interoperable Europe Portal?
De Open Internet Stack is het politieke en technische initiatief van de Europese Commissie om herbruikbare open-sourcebouwstenen te definiëren voor soevereine overheidsdiensten. Het Interoperable Europe Portal is het online platform waar die bouwstenen gepubliceerd, beoordeeld en gedeeld worden en fungeert als de praktische catalogus.
Verplicht CADA artikel 20 Europese overheidsorganisaties om open source te gebruiken?
CADA artikel 20 verplicht Europese instellingen om bij de aanschaf van nieuwe software actief te overwegen of open-sourceoplossingen beschikbaar zijn en om hergebruik te bevorderen. Het is geen absolute verplichting tot open source, maar legt de bewijslast bij de organisatie als zij kiest voor een gesloten oplossing.
Wat is een SBOM en waarom is het verplicht onder de CRA?
Een Software Bill of Materials is een gestructureerde inventarislijst van alle componenten, bibliotheken en afhankelijkheden in een softwareproduct. Onder de Cyber Resilience Act moeten fabrikanten en in bepaalde gevallen ook leveranciers van open-sourcesoftware die commercieel wordt ingezet, een SBOM beschikbaar stellen zodat kwetsbaarheden snel opgespoord en gepatcht kunnen worden.
Kan een organisatie Nextcloud en Matrix/Element combineren als volledige M365-vervanging?
Voor de meeste werkplekfuncties wel: Nextcloud Server v33 dekt bestanden, agenda, taken, documenten en interne chat, terwijl Matrix/Element het gestandaardiseerde berichtenprotocol levert voor gefedereerde communicatie. Lacunes zitten met name in geavanceerde e-mailbeveiliging en volledig geïntegreerde videoconferentie; daarvoor zijn aanvullende componenten zoals Jitsi nodig.
Hoe verhoudt de CADA-soevereiniteitsbeoordeling zich tot het EUCS-certificeringsschema van ENISA?
CADA artikel 20 richt zich op de interne besluitvorming bij softwarekeuze, terwijl het EUCS-schema van ENISA een extern, onafhankelijk certificeringsniveau biedt voor cloudaanbieders (Basis, Substantieel, Hoog). Een organisatie gebruikt beide naast elkaar: CADA als inkoopkader voor software en EUCS als toetssteen voor de hostingomgeving.
