Naming the risk of a single QTSP dependency honestly
A software vendor wanting to offer qualified electronic signatures (QES) soon faces a basic question: do we build qualification ourselves, or work with a qualified trust service provider (QTSP)? Our answer is clear: do not build it yourself. A QTSP is a regulated provider audited by supervision and meeting strict requirements on technology, organisation, staff and security. These requirements are anchored in the eIDAS Regulation, and meeting them is no side project of a product team.
This answer comes with a risk many vendors dislike mentioning, so we name it explicitly: dependence on a single partner. If your entire QES function rests on one QTSP, availability, pricing, development, identification procedures and location of your function depend on its decisions. If the partner fails, changes its terms or discontinues a procedure, your customers are affected, and they turn to you, not to the partner.
For regulated customers concentration risk is a topic anyway. Financial entities must manage third-party risk under DORA and keep exit strategies for critical providers. NIS-2 also sets requirements on supply chain security. An ISV serving such customers will be asked: what happens if your signature partner fails? Do you have alternatives? What does exit look like? These questions are legitimate, and an honest answer is worth more than a promise.
We therefore state openly what we do not promise. We promise no automatic or seamless switching between several QTSPs at runtime, and we claim no finished multi-partner flow that absorbs an outage unnoticed. What we offer is an API layer decoupling your product from the particularities of a single partner as far as technically and legally possible. Whether and how further partners are connected is a matter of architecture, contracts and supervision that we clarify with you case by case.
The one hard distinction of this article: decoupling is not redundancy. A clean abstraction means your product is not chained to a partner's particularities and you can switch or extend in the long run. Redundancy means a second partner is actually ready, contractually, technically and organisationally. One is a matter of design, the other of contracts, operations and cost. Whoever mixes them promises more than they deliver.
A pragmatic stance follows for ISVs. Treat QTSP dependency like any other supplier dependency: document it, assess the risk, define how to handle it and communicate honestly with customers. For many use cases a single, well-chosen partner suffices, especially when QES is needed only for part of the transactions and AES is available as a fallback level for documents not necessarily qualified. For other, especially critical cases you should discuss a second partner early.
API and QTSP: who carries which role
To classify the risk properly, a clear separation of roles helps. The QTSP provides the qualified trust services: it verifies the signer's identity under applicable requirements, issues a qualified certificate, operates or provides the qualified signature creation device and creates the qualified signature. It is liable for this under the regulation and is supervised. In Germany the Federal Network Agency is responsible as supervisory body for trust services.
The API layer, that is Sign2x, provides no qualified trust services. Sign2x is not a QTSP. We give your product the functions a signing flow needs: create transactions, manage documents and signers, control steps, deliver events, separate tenants and map brands. For SES and AES the flow secures assignment and integrity. For QES it integrates the partner QTSP, such as Sign8, and ensures the result is traceable in the transaction.
A third party is your product, the ISV. You decide which level applies to which document type, what the interface looks like, how users are guided and how results are processed further. You bear responsibility for product design and communication towards your customers. And your customer bears responsibility that the chosen level fits their transaction legally. Four parties, four roles, and each should be named in contracts and documentation.
The division of roles has practical advantages. It forces clarity about who stands behind what and protects against liability blur. If, for instance, a certificate is revoked, that lies with the QTSP. If an interface misleads users, it lies with you. If a webhook does not arrive, it lies with the integration. Whoever knows this assignment resolves disruptions faster and communicates them more honestly. More on the division of roles in the context of AML is in AML-ready signature API for ISVs.
The separation of roles also helps with choosing levels. If you know QES involves a partner, with identification, time and cost, you weigh more consciously where to use it. A decision aid is AES vs QES via API. In many cases AES is the pragmatic choice and QES the exception for transactions with statutory form or special evidentiary need. That reduces dependency structurally, since only part of your transactions need the partner.
What ISVs orchestrate: the partner as a building block in your product
When working with a QTSP partner, some tasks stay with you even though qualification sits externally. The first is configuration: which document types run with QES, which identification procedures are allowed, which texts appear before signing? These decisions belong in a configuration your legal counsel is responsible for, not in scattered code. That way you can trace changes and adjust where needed without changing the application.
The second task is state handling. QES transactions take longer than simple signatures and contain steps outside your control: identification, certificate issuance, signature creation. Your system must understand these intermediate states and make them clear to users. That works with a state model as described in webhook state management for e-signature events: events are received, stored in a history and translated into business states, even when the partner needs time.
The third task is error handling. Partner services are no guarantee of freedom from errors. Identifications fail, connections drop, timeouts occur. Your product needs defined paths: retry, alternative procedure, hint to the user, escalation to support. What matters is that a partner problem does not lead to a silent loss of transactions. Error events belong in your monitoring, and support should know how to help users with typical problems.
The fourth task is documenting the supply chain. The partner is part of your ICT supply chain and belongs in your documentation: name, role, location, data flowing to it, contractual basis, exit arrangements. For regulated customers that is mandatory material. How such evidence is built is shown in DORA Article 30 and the signature audit trail. We stress: it is evidence, not certification, and neither DORA nor NIS-2 knows a seal for signature APIs or partnerships.
The fifth task is monitoring the partner. Check regularly whether the QTSP is still listed as qualified, whether terms, procedures or locations have changed and whether announced changes affect your flow. Member States' trusted lists make the status publicly viewable. Record your check in writing: it serves as evidence of diligence and helps notice changes early. Developments such as the EUDI wallet also change roles, as described in eIDAS 2.0 and the EUDI wallet.
The sixth task concerns communication with customers. Explain in sales material and contracts that QES runs through a partner, who it is and what role it has. That may look like a sales disadvantage but is the opposite: regulated customers expect transparency and distrust vendors who conceal supply chains. A clear, short presentation of roles answers most queries in advance and builds trust that pays off later in shorter audit cycles.
An example makes this tangible. An ISV for HR software offers employment contracts for signature. Fixed terms and certain evidence require written form, which the qualified signature replaces. All other documents, such as privacy notices or side agreements, run with AES. Only a small part of transactions thus touches the partner, and if it fails temporarily, most signatures remain usable. That is not redundancy, but it limits the reach of a disruption considerably and can be communicated honestly.
A second example concerns onboarding at financial service providers. There identification and qualified signature are often coupled, and the partner is visible to the customer. Here it pays to draft contracts so data and evidence are returned on a switch and the flow stays configurable in the product. A later switch then remains a project of clear scope instead of a rebuild. Whoever records this early saves much explanation effort in audits.
Finally, a look at cost. Qualified services are usually billed per transaction, and identification procedures differ markedly in price. Do not count only the unit price but the share of transactions that really need QES, the abandonment rate during identification and the support effort. A cheap price with a high abandonment rate can be more expensive than a higher price with clean user guidance. This calculation belongs in every partner assessment.
Questions for vendors: a list for partner selection
In selecting a QTSP partner, but equally in assessing any signature vendor, concrete questions help. We have grouped them into six groups and recommend recording the answers in writing.
- Status and supervision: is the provider listed as a QTSP, for which services, since when, and which supervisory body is responsible?
- Procedures and levels: which identification procedures and signature levels are productively available, and what is the roadmap for changes, for example with the EUDI wallet?
- Location and ownership: where is data processed, who owns the provider, which subcontractors are involved and which law applies?
- Operations and availability: which availability targets does the provider state, how are disruptions communicated and what does support look like in an emergency?
- Contract and exit: which termination and exit rules apply, how are data and evidence returned and how long do they remain available?
- Integration and data: which events and evidence does the provider deliver, in which format, and how can they be integrated into your state model?
Mind the quality of answers, not just their existence. A vendor quoting availability figures without a measurement basis or dodging ownership questions is also giving you an answer. We also recommend planning a small practical test: one transaction from start to completion with real users, including a failure case. What convinces on paper sometimes shows weaknesses in operation, and vice versa.
Ask us the same questions. We gladly answer and say openly where we cannot give commitments. Sign2x is an API layer for SES, AES and QES, we are not a QTSP, and for QES we work with partners such as Sign8. If you are thinking about second partners or alternative paths, that is worth a conversation in which we clarify feasibility, effort and limits without promising in advance something that later does not hold.
The frame: sovereignty along the whole chain
Sovereignty does not end at the border of your platform. It covers the whole chain, including the partner. Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. That is a clear statement about our part of the chain. For the QTSP partner you should ask the same questions: location, ownership structure, subcontractors, legal framework. Whoever runs only their own platform sovereignly and does not check the partner has a gap in the argument.
Why location alone is not enough is explained in Cloud Act vs data sovereignty, with technical and legal depth in Open Sovereign Cloud for the e-signature API and Cloud Act and Open Sovereign Cloud for e-signature. The stance matters: sovereignty is a property of the chain, and you are only as strong as the weakest link. That does not mean every partner must be perfect but that you know where the limits are and document them.
Hosting on OSC is a statement about operations and jurisdiction of the platform. It is no certification of your product and no replacement for your own risk assessment of the supply chain. Data protection questions also remain with you: the GDPR demands clear responsibilities, data processing agreements and transparency about recipients. With QES flows personal data goes to the partner, and your documentation must map that, including purpose, legal basis and retention.
For ISVs with special requirements who accept no cloud path, the option of operation in your own data centre exists. With QES the partner QTSP remains part of the chain, and depending on the setup connections to the partner must be possible. Which parts can stay local we clarify case by case. We consider blanket commitments unserious here and prefer to tell you early where limits lie.
To close, a proposal for next steps: create a one-page partner overview for your product. It contains the four roles, the partners used with status and location, the data flows, the exit arrangement and the date of the last check. This page answers a large part of the questions in security questionnaires and gives your sales a reliable basis. Technical basics are in the developer hub, terms in the help centre, practical cases under use cases and more articles in the Sign2x blog. For a conversation about your setup reach us via contact, and the Sign2x quiz helps with orientation.
Discuss your partner architecture with us
Related articles: NIS-2 evidence through the audit trail and bulk signature API for enterprises. Guidance on information security at the BSI.
Frequently asked questions
Why should ISVs not build qualification themselves?
A QTSP meets strict, supervised requirements on technology, organisation and security. That is no side project of a product team. ISVs integrate a partner better through an API layer.
Is Sign2x a QTSP?
No. Sign2x is the API layer for SES, AES and QES. For QES we work with partner QTSPs such as Sign8.
Does Sign2x offer automatic switching between several QTSPs?
No, we promise no automatic or seamless switching between several partners at runtime. Decoupling in design is not the same as redundancy in operation. We clarify second partners case by case.
How do I reduce dependency on one partner?
Use QES only where needed, keep configuration and state model partner-independent, document the supply chain and discuss second partners early for critical cases.
Where is Sign2x hosted?
On the Open Sovereign Cloud (OSC) from T-Systems. For the QTSP partner you should assess location, ownership and legal framework separately.
