10.09.2026

Author: Peter Amrhyn

FAQ: 5 questions before you change your trust service provider

Which factors decide whether the transition stays invisible to your customers?

In a previous article, we examined the cost of discontinuity in digital trust services and what happens to businesses when the trust chain underpinning their identification and signature processes breaks down. The question that follows is the one product owners and integration teams ask first: what does such a migration actually involve?

First, approach it as a new rollout. Keys, certificates, and configurations will not move from the old provider to the new one because, in a qualified environment, they cannot be moved. That might sound like more work than it usually turns out to be, as long as you plan the project accordingly.

Second, explore the five most common questions customers ask us when they migrate to Swisscom Trust Services.

Does the existing identification process carry over to the new provider?

When changing the trust service provider, there are two possibilities:

The identification process is replaced by a new procedure from the incoming provider's portfolio
The existing process is taken over, subject to the necessary audit and compliance checks.

Of course, carrying an existing procedure over is never automatic. The exact steps depend on whether the method sits within the new provider's certified scope and whether it can be evidenced to the auditors and supervisory bodies involved. Clarify this at the start of the project, because identification comes first in every onboarding and signing journey.

Do my existing frontend and integration carry over to the new provider?

If your frontend is already built and operated by your own teams via API, the change is largely a matter of pointing that integration at a different backend. If the outgoing provider delivered the frontend, it will most likely need to be replaced.

Existing SLA and support arrangements fall into the same category. They cannot simply be transferred or assumed by a new provider, including Swisscom Trust Services, and must be arranged anew as part of the new setup.

What does the new TSP actually transfer: data, keys, or certificates?

In principle, none of these elements are transferred. The setup is rolled out again under the new Trust Service Provider (TSP), and new certificates are issued by the new issuer, i.e., the Certificate Authority (CA).

One exception may apply in the case of a Registration Authority (RA) delegation. In that scenario, newly performed identifications can be accepted, but a new RA agreement must be in place.

From a procurement perspective, the lack of transfer can seem wasteful. This logic ties directly to how and why qualified services are effective. A certificate's integrity rests on the issuer's control over the full key lifecycle, and a provider that can inherit another provider's keys would not be offering a qualified service.

Will my clients experience a service interruption?

This is part of the migration plan, and the recommended approach aims to avoid a hard cutover as much as possible.

Both environments run in parallel for a defined period. New processes and new customers are moved to the new system first, while existing customers and flows continue on the current setup. Once everything has been validated, a controlled switch takes place.

That switch may also change the user interface or design. From a technical user perspective, though, the transition should ideally be imperceptible and not interrupt service.

This seamless user experience is guaranteed through parallel operation. The length of that window is customizable and negotiable, as is the selection of validation criteria for the complete switch.

Does an existing integration history between the new and previous trust service providers make the transition easier?

Yes. An existing integration history can make the transition easier because parts of the technical setup, interfaces, and implementation requirements may already be known.

For example, Swisscom Trust Services previously integrated Verimi's IPSP/IdP into our platform. Although the platform has since evolved from RAX to MAB, this prior experience means the technical setup is not entirely new to us and can reduce discovery and implementation effort.

It does not remove the formal requirements of a provider change, but it can make the migration more efficient and predictable.

Plan the change before it becomes urgent

Provider changes that go unnoticed by end users are those planned as projects. Each one is unique, with several interconnected elements: identification methods, frontend ownership, SLA dependencies. Include the parallel-operation window in that planning too, and set it before an external deadline forces the decision.

The right target setup can also make the transition significantly easier. Swisscom Trust Services supports different migration scenarios without forcing customers into one fixed architecture. Depending on your existing setup, you can combine:

One-Shot Signing for streamlined signature journeys without complex long-term certificate handling
On-demand certificates, issued when they are needed
Modular integration options that allow individual components to be introduced step by step
A broad choice of identity providers and identification methods
Different combinations of identification and approval methods, depending on the required level of assurance and user journey

This flexibility can help organizations retain parts of their existing processes while replacing only the components that need to change — reducing integration effort and making parallel operation easier to manage.

As a qualified trust service provider certified under both eIDAS and ZertES, Swisscom Trust Services supports organizations through this transition across EU and Swiss legal frameworks.

Trust Service Provider Transition Made Easy

If you are evaluating a new trust service provider, Swisscom can help you understand your options. In a free initial consultation, our experts review your current setup, discuss migration scenarios, and outline next steps for a secure, efficient transition.

Book a consultation

Customer success stories

Customer success stories

FAQ: 5 questions before you change your trust service provider

Which factors decide whether the transition stays invisible to your customers?

Does the existing identification process carry over to the new provider?

Do my existing frontend and integration carry over to the new provider?

What does the new TSP actually transfer: data, keys, or certificates?

Will my clients experience a service interruption?

Does an existing integration history between the new and previous trust service providers make the transition easier?

Plan the change before it becomes urgent

Latest Blog Articles

FAQ: 5 questions before you change...

The cost of discontinuity in digital...

AMLR – Can a regulation actually...

A Boost for QES-Based Identification...