On 28 August 2026, the first meeting of the EOSC Node Switzerland Build-up Group took place. The presentation provides a detailed view of how Switzerland is moving from the concept of a national EOSC Node to its practical implementation. The material covers not only the architecture of EOSC Node Switzerland, but also the current state of the EOSC Federation, node requirements, the development of federating capabilities, the work of EOSC working groups, interaction with new Horizon Europe infrastructure projects, and preparations for production readiness. For thematic initiatives such as MATSCI-NASU, the presentation is particularly valuable because it shows how governance, technical architecture, scientific use cases and the node enrolment process are combined in practice.

EOSC Federation is moving from prototype to production

The presentation identifies 2026 as a transition year in which the EOSC Federation is expected to move from the build-up phase towards an operational model. The main objectives are grouped into three areas: establishing the operational structure, moving towards production, and expanding the Federation.

At the organisational level, the transition involves moving from the temporary Build-up Group towards the structure defined in the Memorandum of Understanding, while continuing the development of federating capabilities and the EOSC Interoperability Framework. At the operational level, the Federation must address legal, governance, service-management and technical requirements needed for production operation. In parallel, new nodes are being enrolled, resources are being onboarded, and cross-node scientific use cases are being developed.

The second wave of EOSC Federation expansion in 2026 included 14 new candidate nodes. These comprised national nodes from Czechia, Croatia, Latvia, North Macedonia, Sweden, Slovenia, Switzerland and Türkiye; e-infrastructure nodes such as GÉANT, EGI and Scholarly Commons; and thematic nodes including METROFOOD-RI, EBRAINS RI and ENVRI. According to the presentation, this expansion is associated with 36 cross-node use cases, more than 40 new services and platforms, 41 repositories, links to four European Common Data Spaces, seven EuroHPC supercomputing centres and twenty ESFRI research infrastructures.

Support for the enrolment of second-wave nodes is organised in stages. Switzerland is assigned to the third enrolment-support window, scheduled for January–April 2027. Importantly, the presentation states that the sequencing follows the principle of “infrastructure before services and complexity.” In practical terms, this means that a node should first establish the basic federating infrastructure and only then expand its service portfolio and move towards more complex cross-node scenarios.

Five mandatory federating capabilities

One of the most practical elements of the presentation is the list of Mandatory Federating Capabilities that are progressively being adopted by nodes during enrolment and the transition to production.

These are:

Federated AAI, providing single sign-on across EOSC Nodes and policy-compliant access to resources.

EOSC Catalogue, enabling node services and datasets to be exposed through a common resource catalogue using FAIR-aligned metadata.

Helpdesk, integrating node-level user support with the federation-wide support system.

Monitoring, providing continuous service monitoring and feeding information into federation-wide dashboards.

Service Management System, based on a structured service-management framework, with FitSM used as the common approach.

A key point is that these functions do not necessarily have to be implemented independently by every node. Some may be provided by the EOSC EU Node, by other nodes, or through dedicated infrastructure projects. What is mandatory is the functional capability, not the duplication of the same technical stack at every institution.

Figure 1. Mandatory federating capabilities of an EOSC Node during the transition to production: Federated AAI, EOSC Catalogue, Helpdesk, Monitoring and a FitSM-based Service Management System. Source: EOSC Node Switzerland Build-up Group Meeting #01, 28 August 2026, slide 8.

How Switzerland is building its EOSC Node

EOSC Node Switzerland is led by ETH Zurich together with the Swiss National Supercomputing Center CSCS. The build-up is planned for 24 months and builds on the earlier SENPro initiative, through which national needs assessment and two rounds of prototype testing had already been carried out.

The Swiss team defines the challenge primarily as fragmentation: Swiss resources have limited visibility at European level, institutions use different interoperability and onboarding practices, and cross-disciplinary connectivity remains insufficient. At the same time, Switzerland already has strong Open Research Data and FAIR foundations, internationally recognised research infrastructures and broad multidisciplinary expertise.

The architecture of EOSC-CH is organised into three major components.

The Resource Hub is intended to provide catalogues for datasets, services, infrastructures and training resources, together with registry services supporting onboarding.

The Resource Platform provides federated access to compute, storage and other services through federated AAI and accounting.

The Federating Capabilities layer includes AAI, catalogue and registry services, onboarding, metadata and PID alignment, monitoring and service-management foundations.

An important architectural principle is that EOSC-CH reuses and extends EOSC EU Node components in order to maintain compatibility and avoid unnecessary duplication. Switzerland is therefore not attempting to create a parallel national EOSC platform from scratch. Instead, it aims to connect national research capabilities to the wider Federation through reusable and interoperable components.

Figure 2. Main building blocks of EOSC Node Switzerland: Resource Hub, Resource Platform and Federating Capabilities. The architecture is designed to reuse and extend EOSC EU Node components rather than duplicate common infrastructure. Source: EOSC Node Switzerland Build-up Group Meeting #01, 28 August 2026, slide 17.

From catalogues to real research use cases

EOSC Node Switzerland already has a substantial portfolio of resources that can be prepared for federation. The presentation identifies more than 15 services at TRL 7–9.

In life sciences and bioinformatics, examples include SIB, SWISS-MODEL, Expasy and BioMedIT. In the humanities and social sciences, the portfolio includes DaSCH, FORS/SWISSUbase and university repositories. In materials and physical sciences, it includes PSI, Materials Cloud and muon facilities. Environmental and climate resources include the World Glacier Monitoring Service, ICOS-CH and Eawag Datalakes. The computing and AAI backbone includes services such as Switch Cloud and Switch eduID.

Crucially, these resources are not treated as an end in themselves. The Swiss team has defined six scientific use cases that are intended to test the practical value of the node.

The first focuses on federated training material through glittr.org, ELIXIR TeSS, mTeSS-X and PaNOSC. The second combines ancient DNA, archaeology and astronomy using Galaxy. The third addresses Trusted Research Environments for federated analysis of sensitive health, social-science and linguistic data. The fifth focuses on drug discovery and biodiversity using SIB, SWISS-MODEL, SIBiLS and ExpasyGPT. The sixth demonstrates reproducible cross-node workflows using a compute-to-data model orchestrated with REANA.

For MATSCI-NASU, the fourth use case is particularly relevant: “Materials science, data to publication.” It covers a complete path from muon experiments to FAIR publication in Materials Cloud, aligned with PaNOSC. This is an important example of how a thematic EOSC Node should be designed around an end-to-end scientific process rather than around an isolated repository, catalogue or computing platform.

Figure 3. Six scientific use cases of EOSC Node Switzerland. Of particular relevance to MATSCI-NASU are “Materials science, data to publication” and “Reproducible cross-node workflows.” Source: EOSC Node Switzerland Build-up Group Meeting #01, 28 August 2026, slide 19.

For MATSCI-NASU, this approach closely resembles the logic of reproducible materials-science workflows in which computational or experimental steps are linked to metadata preparation, FAIR curation and publication. A DFT → MLIP → MD chain, for example, can be considered not merely as a local computational workflow but as a potential federation use case if the compute environment, datasets, metadata, repository and external EOSC resources are connected into one reproducible route.

Stepwise implementation instead of a one-off “node launch”

The Swiss roadmap is divided into three phases.

During Phase 1, M1–M7, the focus is on initial alignment and coordination. Governance structures are established, architecture is defined, and an international sounding board is set up.

During Phase 2, M8–M18, implementation and testing become the main activities. The prototype Resource Hub and Resource Platform are expected to become operational, onboarding pathways are implemented, and testing is carried out with partner nodes.

During Phase 3, M19–M24, attention shifts towards federation readiness: hardening components, cross-node coordination, development of a business model and preparation of the final readiness package.

A formal checkpoint is planned for M12. At that point, remaining milestones can be reassessed based on actual progress, Federation alignment and external dependencies.

This approach is important because it treats node development as a process of increasing maturity rather than as a single technical deployment event.

Figure 4. Twenty-four-month roadmap for EOSC Node Switzerland: Initial Alignment and Coordination, Implementation and Testing, and Iteration and Federation Readiness, with a formal checkpoint at month 12. Source: EOSC Node Switzerland Build-up Group Meeting #01, 28 August 2026, slide 20.

EOSC Mesh and the emergence of a multi-hub architecture

A substantial part of the presentation is devoted to EOSC Mesh, coordinated by the EGI Foundation. Its objective goes beyond the enrolment of individual nodes. EOSC Mesh is exploring a model in which groups of EOSC Nodes jointly provide federating capabilities.

The project plans to establish a hub composed of seven EOSC Nodes that collaboratively deliver a catalogue of federating capabilities through a common governance structure and a FitSM-compliant federated Service Management System.

The presentation identifies several advantages of this multi-hub model. Failures in one hub can be isolated without affecting the entire Federation. New hubs can be added without redesigning the whole system. Management remains decentralised, and individual hubs can be adapted to the requirements of specific technical, thematic or geographic communities.

EOSC Mesh is expected to provide approximately 25 federating capabilities. Core capabilities include AAI, accounting, helpdesk and monitoring. Generic capabilities include notebooks, data transfer, Galaxy, REANA and sensitive-data processing. Thematic capabilities may include specialised catalogues, knowledge bases and community services.

This represents an important architectural evolution. Federating capabilities do not have to be concentrated in one central node. They can be provided collaboratively by several autonomous nodes.

Figure 5. EOSC Mesh multi-hub architecture. Groups of autonomous EOSC Nodes can jointly provide federating capabilities through a shared FitSM-compliant service-management framework while preserving decentralised governance. Source: EOSC Node Switzerland Build-up Group Meeting #01, 28 August 2026, slide 39.

For initiatives such as the future Federation of EOSC Nodes of the National Academy of Sciences of Ukraine, this model is particularly relevant. It shows that shared services do not imply centralised ownership or hierarchical control. Several thematic or infrastructure nodes can jointly operate common federation functions while remaining autonomous in their own scientific resources, user communities and access policies.

EOSC4ALL: Node-as-a-Service and lower entry barriers

Another important project discussed in the presentation is EOSC4ALL, coordinated by GÉANT. Its strategic goal is described as “low-barrier EOSC Node deployment.”

The project aims to make the deployment of an EOSC Node simpler, faster and more accessible for eligible organisations. A central concept is a reusable Node-as-a-Service model based on the GÉANT Digital Research Environment.

The initial service portfolio includes an EOSC AAI platform, OCRE cloud access, eduVPN, perfSONAR, the GÉANT Data Transfer Node Testing Facility and security training. EOSC4ALL is also expected to develop federated File Sync & Share capabilities and operational-readiness patterns.

This reinforces a broader trend within EOSC: future nodes should increasingly be able to rely on reusable federation-ready components rather than developing every function independently.

AAI is more than login

The EOSC AAI Working Group section of the presentation demonstrates that federated identity management involves much more than user authentication.

The working group addresses eduGAIN, MyAccessID, OpenID Connect, OAuth2, token handling, common claims, groups, roles, assurance levels and authorisation patterns. It also covers onboarding, security alignment, support processes and documentation.

The expected outcome is described as a pragmatic, phased and reusable AAI framework that allows EOSC Nodes to join the Federation, provide a consistent single sign-on experience and support cross-node workflows without requiring every node to adopt the same local AAI implementation.

This is especially important for national and thematic nodes that already operate local identity-management systems. The objective is therefore interoperability, not technological uniformity.

The catalogue as part of semantic interoperability

The Federated EOSC Node Resource Catalogue Working Group is working on catalogue-data exchange, controlled vocabularies, service classifications, research-domain descriptions, access and order types, and the resource data model.

The presentation shows that the challenge is not simply technical aggregation. Different nodes may use different terms for functionally similar services. AAI, computing or storage services, for example, may be classified differently in EOSC EU Node, EOSC Finland and EOSC Italy.

The catalogue therefore becomes part of the semantic interoperability layer of the Federation. A functional EOSC catalogue requires a common minimum data model, controlled vocabularies and mappings between different classification systems.

Cybersecurity as an operational governance function

The EOSC Federation Cybersecurity Working Group is tasked with defining generally applicable cybersecurity policies, supporting their implementation across nodes and contributing to the development of a computer security incident response capability.

EOSC Node Switzerland has already organised a dedicated cybersecurity workshop focused on policy requirements and on evaluating the current security status of individual services.

This illustrates a move away from treating cybersecurity as a general compliance statement. In operational terms, it requires security policies, risk assessment, vulnerability management, threat reporting and incident response.

Governance and the operational structure of the Federation

The presentation also provides a useful view of the emerging governance and operational structure of EOSC Federation.

The Node Coordinators Committee addresses coordination between nodes, while the Node Operations Committee coordinates technical implementation. Under these structures, working groups are organised around three broad areas.

Operations-related groups address architecture and federating policies, federated AAI, resource catalogues, helpdesk and service monitoring.

Capabilities-oriented groups cover File Sync & Share, Virtual Research Environments, Federated Compute and Storage, Training and Competencies, and Scientific Repositories.

Governance-oriented groups include Legal & Governance, Cybersecurity and the Federation Handbook.

This separation is important because strategic coordination, operational implementation and specialised capability development require different responsibilities and expertise.

Figure 6. Coordination and operational structure of the EOSC Federation in 2026, showing the relationship between the Node Operations Committee, Node Coordinators Committee and specialised working groups covering Operations, Capabilities and Governance. Source: EOSC Node Switzerland Build-up Group Meeting #01, 28 August 2026, slide 55.

From Project Charter to Work Packages: the “missing implementation layer”

The final part of the presentation is particularly valuable for teams preparing their own EOSC Nodes.

The Swiss team assessed the alignment between its Project Charter and the existing Work Packages. The overall conclusion was that the strategic vision was aligned, the technical architecture was aligned and EOSC Federation requirements were broadly covered. However, three important gaps remained: deliverables were not sufficiently mapped, governance and sustainability were underdeveloped, and operational ownership was unclear.

The Project Charter already defines fifteen deliverables, milestones, six federation use cases, governance and sustainability objectives and federation-readiness targets. However, many of these elements were not yet clearly reflected in the existing Work Packages.

The presentation identifies this as a missing implementation layer. Moving from strategy to execution requires each Charter commitment to be linked to a concrete activity, deliverable, milestone, responsible organisation or person, and acceptance criterion.

In this model, the Project Charter is the reference framework, while the Work Packages must be updated to implement it.

Why the Swiss experience matters for MATSCI-NASU

The Swiss experience provides several direct lessons for MATSCI-NASU.

First, it confirms the value of a use-case-driven approach. A thematic EOSC Node should demonstrate a complete scientific pathway rather than simply list available resources. The Swiss materials-science scenario, from experiment to FAIR publication, is particularly close to the MATSCI-NASU approach.

Second, the presentation shows that use cases and technical node development can proceed in parallel. There is no need to wait until every infrastructure component is complete before testing cross-node workflows.

Third, reuse of existing federating capabilities should be the default option. Before developing local AAI, monitoring, VRE or other common services, a node should evaluate what can already be obtained from the EOSC EU Node, EOSC Mesh, EOSC4ALL, EGI, GÉANT or other established providers.

Finally, the Swiss case demonstrates that the most difficult step is often not defining the overall architecture, but creating a clear operational model: who owns each service, which deliverables must be produced, how readiness is assessed, and how the node remains sustainable beyond project funding.

In this sense, EOSC Node Switzerland provides a valuable example of how a node moves from concept to practical participation in the EOSC Federation: through phased development, reuse of shared components, scientifically meaningful use cases, explicit operational responsibilities and preparation for production readiness.