A source-grounded control guide for remote signature services that use QTSP-managed signing infrastructure, including remote QSCD scope, signer authentication, certificate linking, signature activation, validation, and evidence.
Use it to separate eIDAS remote QSCD requirements from ordinary cloud HSM hosting claims, and to define the records a provider, relying party, or auditor should ask for.
Structured answer sets in this page tree.
Cited legal and guidance references.
For a remote signature to qualify under eIDAS, a qualified trust service provider must manage a on behalf of the signatory, and the signature must meet the other QES conditions. A cloud HSM product or hosting attestation alone does not establish remote QSCD status, qualified service status, signer control, certificate linkage, or a valid QES.
Under the consolidated eIDAS text, a is a QSCD managed by a qualified trust service provider under Article 29a on behalf of a signatory. Article 29 permits generating, managing, and duplicating signature creation data for backup only on behalf of and at the request of the signatory, and only by a providing the qualified remote-device management service.
Start the control record with service classification. If a service only hosts keys in a cloud HSM for internal signing, it may still need strong cryptographic controls, but it is not a qualified remote signature service unless the , remote QSCD, signatory request, qualified certificate, QES, and qualified-service facts are present. The transition that allowed certain existing QTSPs to manage remote QSCDs without separate qualified status ended on 21 May 2026. After that date, the management service needs its own qualified status.
For a server-side remote signature service, ETSI TS 119 431-1 breaks the service into component responsibilities rather than treating the HSM as the whole control. The useful implementation record should show how signing keys are generated, how the signer identity or eID means is linked, how the certificate is linked, how is verified, and how keys are deleted or recovered when applicable.
ETSI TS 119 431-2 covers the service component that creates AdES digital signatures. It is relevant when the remote signing service receives documents or hashes, prepares the data to be signed, obtains the digital signature value from the signature creation device, and builds the final signature.
The evidence should link a particular signer, signing key, certificate, signature session, and explicit authorization to sign. ETSI TS 119 431-1 treats eID means or identity linking as a dedicated component and requires integrity protection for the link between the signer key and the eID means reference or identity.
If authentication is delegated outside the qualified trust service, the record should show the delegation boundary and the assurance basis. The standard recognizes delegated authentication and points to notified eID schemes or the EUDI Wallet at the needed level of assurance as a way to support the required assurance, but the still needs to show how the external party fits the remote-signing requirements.
A remote signature control record is incomplete if it stops at successful signing. eIDAS validation of a qualified electronic signature requires confirming the qualified certificate at signing time, the issuing qualified trust service provider, the signatory data, the QSCD, data integrity, and the advanced-signature requirements.
Operational validation should therefore keep the trusted-list evidence used to establish qualified status, the certificate chain and status evidence, the validation policy, and the signature qualification result. The European Commission eSignature building block and eIDAS Dashboard context are useful because they point implementers to DSS, the Trusted List Browser, notification tooling, and validation tests.
The evidence pack should be organized around the claim being made: qualified remote signature, advanced remote signature, remote seal, or non-qualified server-side signing. Each claim needs different evidence, and a cloud HSM attestation alone does not prove qualified signature status.
For -operated services, ETSI EN 319 401 supports baseline trust-service evidence such as terms and conditions, trustworthy systems, stored data authenticity controls, relevant records for legal proceedings and continuity, change communication, incident handling, and service termination planning.
No. eIDAS focuses on qualified electronic signature creation devices and, for remote qualified signatures, management of the remote qualified signature creation device. A cloud HSM may be part of an implementation, but the eIDAS evidence must prove QTSP service status, remote QSCD qualification, signer control, certificate linkage, and validation results.
Check whether the signing certificate was a qualified certificate issued by a , whether the signature creation data was held in a QSCD, and whether the Article 29a remote device management service had qualified status. The transition for certain existing providers ended on 21 May 2026. Retain the trusted-list and validation evidence for the signing time.
Ask for the qualified service identity, trusted-list status, practice statement or terms, remote QSCD certification evidence, signer authentication and activation controls, certificate status handling, validation report format, incident process, and record retention approach.
Sorena can help turn this remote signature control guide into service classification questions, QTSP evidence requests, validation checks, and implementation records for eIDAS work.
Ask official source questions about remote QSCD scope, QTSP evidence, signer authentication, trusted lists, and validation using the cited sources on this page.
Review your remote signing workflow, cloud HSM assumptions, validation evidence, and QTSP source gaps with Sorena.
"Trust Service Providers"
"audit data records"
"AdES digital signature creation"
"Trusted Lists"
"Trusted List Browser"
"Requirements for the validation"