A system integrator implements against a defined specification, while a QTSP is part of the regulated trust infrastructure itself. The first helps execute the design, but the second can provide identity and trust services that already carry legal recognition across member states. That difference affects assurance, interoperability and the size of the internal compliance burden.
Why the Roles Diverge in a Digital Identity Programme
A system integrator and a QTSP sit on different sides of the implementation boundary. A system integrator assembles components into a working solution, adapts interfaces, and makes the project operational. A QTSP provides regulated trust services that are already part of the legal and technical trust layer, so the project is not only integrating software, it is also inheriting a trust function with formal obligations and cross-border recognition.
That distinction matters because the integrator is judged mainly on delivery quality, conformance to the target architecture, and the reliability of the implementation. The QTSP is judged on whether its trust service remains legally valid, operationally sound, and suitable for relying parties. In practice, one role consumes the trust service, while the other role vouches for the trust service itself.
The difference also changes how you scope responsibility. With a system integrator, the project team usually owns more of the assurance work around configuration, interoperability testing, and downstream control design. With a QTSP, part of the assurance burden moves into the regulated provider model, so the consuming organisation must validate service fit, contractual terms, operating assumptions, and the conditions under which the trust service can be relied on across jurisdictions.
What Each Party Actually Contributes to the Architecture
A system integrator typically focuses on the composition layer: connecting identity systems, wallets, credential issuers, verification services, onboarding flows, and business applications so the programme works end to end. The value is execution. The integrator turns a specification into a deployable system, but it does not automatically supply the legal trust anchor or the regulated status behind the service.
A QTSP, by contrast, contributes a trust primitive. In digital identity projects that means the service may carry legal recognition, defined assurance properties, and standardised trust semantics that other parties can rely on. The project therefore depends on the QTSP not just as a vendor, but as a participant in the trust infrastructure. That is why selection criteria should include regulatory standing, service scope, evidence of compliance, incident handling, and the limits of what the trust service is authorised to do.
For example, an identity wallet project can be technically delivered by an integrator, but the trustworthiness of the signatures, certificates, or identity assertions used within that project may depend on a QTSP. The integrator can make the workflow usable; the QTSP can make the trust assertion legally and operationally meaningful. Treating those as the same role is where many project assumptions go wrong.
For the regulatory backdrop, see the eIDAS 2.0 , EU Digital Identity Framework, which defines the trust environment that makes the QTSP role materially different from a normal implementation partner.
How the Difference Changes Assurance, Interoperability, and Compliance Burden
Because a QTSP is part of the trusted infrastructure, assurance is not limited to whether the integration works in a test environment. You also need to confirm that the service remains acceptable to the relying party ecosystem, that the trust model is interoperable across the intended jurisdictions, and that the organisation can evidence the compliance conditions attached to the service. That is a different problem from standard integration assurance.
With a system integrator, interoperability is usually about protocols, schemas, APIs, and deployment fit. With a QTSP, interoperability also includes trust semantics, legal recognition, and the operational assumptions behind the trust service. That means the project should test not only technical exchange, but also whether the resulting identity flow preserves the properties the business expects when it crosses organisational or member-state boundaries.
The compliance burden changes as well. A QTSP can reduce the internal work needed to establish certain trust properties, but it does not remove the need for governance. You still need role clarity, risk acceptance decisions, reliance criteria, incident escalation paths, and evidence that the consuming organisation is using the trust service within its intended scope. A system integrator may help build those controls into the solution; the QTSP makes the trust layer itself more formally anchored, which raises the bar on supplier oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | QTSP reliance depends on governed external trust services and supplier obligations. |
| Recommendation — Define service terms, trust boundaries, and assurance requirements for the external trust provider. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | The QTSP is a regulated supplier whose controls and obligations affect the identity solution. |
| Recommendation — Assess the provider’s security responsibilities, evidence, and contractual commitments before reliance. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Digital identity projects often hinge on the assurance level of the identity process being integrated or trusted. |
| Recommendation — Match the identity workflow to the required assurance level and verify the evidence supports it. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Never Trust, Always Verify | The integrator/QTSP split requires verification of trust rather than assuming integration implies trust. |
| Recommendation — Verify trust assertions and service conditions continuously instead of assuming provider status is sufficient. | ||
Practitioner Guidance
What to verify: Check whether the project needs a delivery partner, a regulated trust provider, or both. If a single supplier is being described as both, separate the implementation obligation from the trust obligation before contracting or designing controls.
Decision rule: If the service is supposed to carry legal trust value across borders, treat the QTSP as part of the core trust architecture. If the work is mainly about joining systems, orchestration, or user experience, treat the integrator as the execution layer and validate that it does not inherit trust responsibilities by assumption.
What practitioners underestimate: The hidden risk is not only technical integration failure, it is misplacing accountability. When the trust service and the integration service are conflated, teams often under-specify assurance evidence, overstate interoperability, and discover too late that the compliance burden sits with the consuming organisation.
Practitioner takeaway: In digital identity programmes, the integrator makes the solution work, but the QTSP can make the trust itself legally usable, so procurement, architecture, and assurance must be separated from the start.
Related resources from NHI Mgmt Group
- Guide: Digital Identity, eID and Identity Wallets Guide
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between federated digital identity and a single-purpose government ID system?
- What is the difference between inclusion-focused digital identity and a system built mainly for state control?
- What is the difference between attack surface management and NHI governance?