Building National Signing Services Under eIDAS 2.0: 6 Priorities for TSPs

eIDAS 2.0 changes the context for remote signing in Europe. The management of remote qualified electronic signature and seal creation devices is now defined as a qualified trust service in its own right. The transitional period that allowed qualified trust service providers to manage these remote devices without obtaining qualified status for the management service ended on 21 May 2026.

For TSPs building or evaluating national signing services, this puts greater emphasis on the operating model around remote signing, not simply the technology used to create a qualified signature.

The challenge is how to provide a shared trust service across ministries, agencies, municipalities and private-sector services without creating unnecessary duplication or operational complexity.

At this scale, signing depends on controls around identity, credential management, user authorisation, signing and sealing policies, timestamps, evidence and verification. If every application implements these controls independently, assurance can vary and the compliance burden increases.

A stronger model is to provide signing and sealing through a common, governed trust architecture while allowing individual services to retain their own workflows and user experience.

1. Build One Reusable Signing Foundation

A national signing architecture should separate business workflows from the trusted signing service.

Portals, case-management systems, document platforms and other digital services should be able to request a signature or seal without each application having to manage cryptographic keys, credential activation or signing evidence itself.

The shared service can provide common controls for credential activation, signing policies, timestamps, audit records and evidence. A modular architecture also allows existing identity providers, certificate authorities, timestamp services, portals and workflow systems to remain in place.

Individual services can control their user journeys and business processes, while the signing service provides the high-assurance functions that need to remain consistent. New agencies or applications can then connect to the same trust foundation rather than creating another signing environment.

2. Treat Remote QSCD Management As A Distinct Trust Service

Under eIDAS 2.0, the management of remote qualified signature creation devices is explicitly defined as a qualified trust service. Equivalent requirements apply to remote qualified electronic seal creation devices.

For TSPs providing qualified remote signing, this makes the boundary around remote device management particularly important.

The operating model must clearly establish how signature creation data is generated or managed on behalf of the signatory, how the remote qualified signature creation device is operated, and how the conditions associated with qualified signing are maintained.

The wider signing process must also establish how the user is authenticated, how the correct credential and document are selected, how the signing transaction is authorised, and how that authorisation is connected to the resulting signature.

For organisational seals, the same control model should define which authorised person, system or process can activate the sealing credential.

These responsibilities should sit within a clearly defined trust-service environment rather than being distributed across the applications requesting signatures. Clear boundaries make it easier to assign responsibilities, apply controls consistently and prepare the service for conformity assessment and supervision.

3. Centralise Policy, Credentials & Evidence

A shared signing service needs a common policy and evidence model before multiple organisations begin connecting to it.

The TSP should define which identity and authentication methods are accepted, which credentials can be used, which signature or seal levels apply, and how requirements such as timestamps, revocation, retention and verification are handled.

Those policies should be enforced through the shared service rather than recreated inside every integration.

The same principle applies to evidence. A signing transaction should produce a consistent and auditable record of the service involved, the credential used, the authentication and authorisation process, the applicable policy, the document or transaction being approved, and the result.

Credential management also requires clear ownership. Key generation, certificate binding, suspension, revocation, renewal, backup and destruction need governed and auditable processes rather than application-specific procedures.

Operational monitoring should provide visibility into failed signing attempts, policy denials, unavailable dependencies, performance issues and unusual transaction patterns without exposing keys or collecting unnecessary personal data.

Together, these controls reduce the number of places where security and compliance decisions need to be implemented and maintained.

4. Standardise The Integration Model

A national service may need to connect to a wide range of portals, identity schemes, EUDI Wallets, identity providers, certificate infrastructures and document platforms.

A repeatable integration model is therefore essential.

Stable REST interfaces, Cloud Signature Consortium APIs, OAuth 2.0 and OpenAPI documentation can give connected services a common way to interact with the signing platform. Interfaces should cover relevant processes around credential discovery and management, authorisation, signature activation, error handling and evidence retrieval.

This reduces the amount of custom security logic required for each project and gives agencies a clearer path from technical integration to production onboarding.

Standards-based interfaces also reduce coupling between the signing service and individual identity, certificate or timestamp providers. They do not remove the work involved in changing a critical trust-service dependency, but they make it less likely that such a change requires redesigning every connected application.

The objective should be a stable signing interface even as the wider identity and trust-service environment evolves.

5. Add the EUDI Wallet Without Creating Another Signing Stack

The EUDI Wallet introduces an important new channel for digital identity and user interaction. It should not require TSPs to create a separate signing architecture alongside their existing services.

For a reusable national architecture, wallet-enabled signing should connect to the same shared signing and trust-service foundation rather than introduce a separate signing stack.

The wallet may participate in identity, authorisation and the signature-creation journey, while remote qualified signature creation and device management can remain provided through the established trust-service architecture.

The signing service can therefore continue to provide common controls around credential activation, document processing, signature or seal creation, timestamps and evidence. Wallet interactions should use clearly defined interfaces that establish the source of information, the attributes or authentication being relied upon, and the user's approval of the relevant transaction.

This allows wallet-enabled journeys to coexist with national eID, federated identity, enterprise authentication and other channels without automatically creating separate credentials, key stores or evidence processes for each one.

It also creates a practical migration path. TSPs can introduce wallet-enabled journeys as requirements and adoption develop while retaining the same governed signing foundation underneath.

6. Design The Operating Model For Resilience & Compliance

The architecture is only part of a national signing service. TSPs also need to define how the service will be operated.

That includes where signing components and HSMs run, who controls privileged access, where audit records and personal data are stored, how incidents are handled, and how responsibilities are divided between public authorities, the TSP and technology suppliers.

On-premises, managed and hybrid deployments can all support this model. Infrastructure and operational responsibility may differ, but the trust-service controls and integration model should remain consistent.

A national platform should also account for peak transaction volumes, unavailable dependencies, infrastructure failures and regional outages. Disaster recovery must preserve key custody, transaction integrity and audit evidence. Patching, platform upgrades, certificate renewal and other lifecycle activities should be treated as routine operating processes with defined ownership.

As more services depend on the same signing infrastructure, operational resilience becomes part of the trust architecture itself.

Make Onboarding A Configuration Exercise, Not A New Security Project

A national signing service succeeds when adding another ministry, municipality or digital service does not require rebuilding the signing security model.

Identity journeys may differ. Business workflows may differ. The underlying trust controls should remain consistent.

That requires a clear separation between applications and trust services, qualified management of remote qualified signature and seal creation devices where required, centrally governed policies and evidence, standardised interfaces and an operating model designed for resilience.

Cryptomathic Signer provides modular components for document preparation and visualisation, signing and sealing, credential management, authorisation and remote qualified signature and seal creation. These components can be integrated with existing identity providers, certificate authorities, timestamp services, portals and workflow systems rather than requiring the TSP to replace the wider digital-service environment.

For TSPs and governments, the objective is straightforward: make each new service an onboarding and configuration exercise rather than another bespoke signing and security implementation.

Explore how Cryptomathic supports reusable national signing services, or review Cryptomathic Signer for the underlying remote signing and sealing platform. To discuss a target architecture, migration path or deployment model, speak with a Cryptomathic specialist.