The evolution from eIDAS 1to eIDAS 2 brings profound changes for the European digital trust ecosystem — notably, an emphasis on interoperability, user-centric identity, and cross-border service delivery. In the preamble to eIDAS 2 the term “harmonised digital identity” is used to define how identities should be used in a “safe, trustworthy, user-friendly, convenient, accessible and harmonised way, across the Union1”. These changes present strategic opportunities for qualified Trust Service Providers (TSPs) but also demand a re-evaluation of architectural approaches to ensure compliance, scalability, and market relevance.
The evolution from eIDAS 1 to eIDAS 2 marks a fundamental shift in Europe’s digital identity and trust services landscape. At the heart of this transformation is a push for interoperability, user-centricity, and seamless cross-border service deliver. As the EU defines a “harmonised digital identity” experience, Trust Service Providers (TSPs) must reimagine their systems to remain compliant, competitive, and future-ready.
The first blog in a two-part series explores the strategic architectural implications of eIDAS 2 for TSPs.
The Role of Interoperability in eIDAS 2
TSPs have long played a foundational role in enabling secure digital interactions across Europe. Now, with eIDAS 2, the scope of trust services is expanding – along with regulatory expectations and user behaviors.
Three key drivers underpin eIDAS 2:
Increased access to electronic identity for all EU citizens.
Enhanced trust in the digital identity and signing ecosystem.
Growth in usage and volume of qualified services, including signatures and seals.
TSPs are well-positioned to lead — but only if their architectures are designed for interoperability. Without this, services risk fragmentation, escalating cost, and long-term obsolescence.
The Cost of Non-Interoperable Architectures
Many first-generation eIDAS implementations have succeeded within national contexts, but they are now showing strain in broader, cross-broader scenarios. Common pitfalls include:
Complex signature workflows – often with more than 40 steps.
Delayed deployments due to bespoke integrations.
High development and compliance costs for every new integration or protocol variation.
Limited scalability and difficulty adapting to future IdPs or supporting services.
These challenges frequently stem from proprietary lock-in, poor architectural separation of concerns, and ad hoc standard adoption.
As regulatory and technological complexity grows, these legacy models become harder to maintain – and nearly impossible to scale.
Mastering eIDAS 2.0: Stay Compliant, Secure and Future-Ready
WATCH ON-DEMAND NOW
A Progressive Architecture for Qualified Signing
To future-proof trust services, TSPs must evolve from isolated, national architectures toward interoperable, pan-European models.
Baseline: National Remote Signing Model
Traditionally, remote signing infrastructures – such as Denmark’s – rely on:
A Signature Portal (aka Signature Creation Application)
Two core interactions:
Request to create a qualified signing credential (signing key + certificate)
Request to create a qualified signature
Two authorisations:
Signing Credential Creation Data (SCCD) for signing credential generation
Signature Activation Data (SAD) for signature generation
Depending on sector needs, these authorisation servers are placed in different parts of the architecture. Typical deployments include:
Example 1: Alongside a national IdP (common in public sector ecosystems)
Example 2: Alongside the signature portal (convenient for private sector implementation like banking, financial services and insurance but inflexible)
Example 3: Within the TSP environment (most suitable for extensibility)
Interoperable Model
The TSP-centric authorisation model aligns most closely with the vision of eIDAS 2. It supports:
Standardised interfaces to external parties (IdPs, portals) via OIDC, SAML, eIDAS eID Profile, and CSC
Flexible connectivity to multiple identity schemes and portals
Proprietary complexity contained internally, e.g. authorisation mechanisms
This model allows TSPs to integrate efficiently while remaining agile, adaptable, and secure.
Scaling Across Member States
Assume a scenario where TSPs in Denmark, Belgium, and Italy each implement this interoperable model:
All accept CSC-based signing credential and signature requests.
All support identity via standard protocols (OIDC, SAML, eIDAS eID Profile).
All host their own authorisation servers.
This setup enables any Signature Portal across the EU to interact with any TSP – supporting:
Signing credential issuance
Potential signing key certification via cross-border CAs
Importantly, local variation in user authentication and authorisation mechanisms does not hinder interoperability — as long as standard interfaces are respected.
Crucially, the differences in local identity mechanisms don’t prevent interoperability – as long as standard interfaces are respected.
eIDAS 2 challenges the status quo but creates massive opportunity. For TSPs, the mandate is clear: design for interoperability, scalability and regulatory alignment.
In part 2, we’ll dive into the enabling technologies of eIDAS 2 – including EUDI Wallets, new trust service categories, and generalized signing models designed for maximum flexibility.
Stay tuned….
Register For Our French Webinar:
