Why

Data sovereignty

Data spaces

International standards

We

Become a member

Members

Donate

Board

Head Office

IDSA ambassadors

Contact

Make

Working groups

Task forces

Hubs & competence centers

Open source

Projects

Communities

Offers

Reference Architecture

Dataspace Protocol

IDSA Rulebook

Certification

Data Space Connector Report

Use

Data Space User Group

Data Spaces Radar

Professional qualifications

Training catalog

Knowledge Base

Publications

Most important documents

Papers

Magazine

Legacy

Events

Upcoming events

Calendar

Archive

Event support

News

Blog

Newsroom

Infohub

Newsletter

August 13, 2026

EDC-V: The open foundation for scalable data space participation

The Eclipse Dataspace Components (EDC) project has been the open-source backbone of data space connectors since its creation. EDC implementations are already running in production across multiple data space ecosystems. They handle the technical mechanics of data exchange: policy enforcement, contract negotiation, and the Dataspace Protocol (DSP) interactions that enable sovereign, governed data sharing between participants.

But the original EDC architecture was designed for a model in which each participant deploys their own connector instance. This works well when the participant is a large enterprise with a DevOps team and the budget to maintain infrastructure. It does not scale to hundreds of thousands of SMEs.

EDC-V, the Eclipse Dataspace Components Virtual connector project, addresses this directly.

What EDC-V is

EDC-V is a multi-tenant extension of the EDC open-source project, maintained under the Eclipse Foundation and available under the Apache 2.0 licence. It is designed to allow a single operator, such as a cloud or managed service provider, to run data space connector infrastructure on behalf of many participants simultaneously.

In practical terms, EDC-V is the infrastructure layer that makes Connector-as-a-Service possible. A CSP or MSP deploys one EDC-V instance and can onboard many participant companies into a data space through that single deployment. Each participant gets an isolated, secure tenant within the shared infrastructure. They can manage their own assets, policies, and contracts through a participant-facing interface, without having access to any other participant’s data or configuration.

How the architecture works

EDC-V organizes access around a set of defined roles. The Operator role covers infrastructure setup and configuration. The Admin role is reserved for initial setup and emergency access. The Provisioning System role handles the automated creation and management of participant tenants. The Participant role represents each individual company in the data space.

All administration through EDC-V uses OAuth 2.0-based authentication. When a new company is onboarded, the provisioning system creates a participant context, generates identity credentials, and registers the participant with the relevant data space trust infrastructure. This process is designed to be automated and fast.

The participant-facing Administration APIs allow each company to manage its own data offerings, access policies, contracts, and verifiable credentials. Strict isolation between participant contexts is enforced by the architecture. A participant can only access its own data; the provisioning system cannot manipulate participant-owned data; and the admin role is not used for day-to-day operations.

This separation between operational roles and participant access is what makes multi-tenant deployment viable for production use.

Benefits for cloud and managed service providers

Without EDC-V, a CSP that wanted to offer data space connectivity services would need to deploy and manage a separate connector instance for each customer. At small scale, this is manageable. At the scale required for meaningful supply chain adoption, it becomes operationally and commercially unviable.

EDC-V turns data space connectivity into something that can be offered as a standard managed service. The provider deploys and operates the shared infrastructure. Customers are onboarded through an automated provisioning process. Compliance and certification are managed at the infrastructure level, not at the individual customer level. The result is a service that a CSP can deliver at scale, with predictable operational costs, through existing customer relationships.

This is the model that CSPs and MSPs already apply successfully in other domains. EDC-V brings the same operating model to data space participation.

The current status

The EDC-V architecture has been defined and developed. Infrastructure readiness for deployment at scale is targeted for summer 2026. The Catena-X Neptune release, which will formally support EDC-V-based solutions, is planned for September 2026. Managed service providers are expected to have their first solutions ready for commercial deployment and SME onboarding before the end of 2026.

The source code is available at https://github.com/Metaform/edc-v.

An open foundation for multiple data spaces

EDC-V is designed to serve multiple data space ecosystems, not just automotive. The architecture is domain-agnostic. A CSP that deploys EDC-V to serve Catena-X participants can, through the same infrastructure, extend services to participants in other data spaces that adopt compatible governance and trust frameworks.

This is consistent with the Data Space Adoption Forum’s broader objective: to build a shared, open foundation that multiple ecosystems can adopt. EDC-V is that foundation. It is the technical layer on which the managed service model depends.

For cloud and managed service providers, this means that investing in EDC-V-based capabilities is a position in the infrastructure layer of a growing family of data spaces.

Stay updated with us