This report asks one simple question: which remote-signing risks still exist even when current ETSI controls are in place?
Core point: a signature can pass technical checks, but there can still be a dispute about whether the signer approved that exact content.
This document does not solve those risks. It shows where they remain and what evidence is missing when disputes happen.
The focus is whether [=Sole control=] and signer [=Intent=] are [=Verifier-checkable=] rather than only [=Assurance-only=].
Scope:
qualified remote signatures where signing is triggered through a service run by a [=TSP=] (typically a [=QTSP=] in this context) under [=eIDAS=] [[EIDAS910]] [[EIDAS2024_1183]].
Threat qualification rule:
A scenario is included only when it can still happen even if current [=ETSI=] controls are in place.
Attacker classes in scope:
Method:
Each scenario is presented in one consistent format: THREAT, MITIGATION, and RESIDUAL.
The goal is simple: show which controls are already in force, what an independent party can verify today, and what still remains disputed.
[=eIDAS=] Article 25 says an electronic signature cannot be denied legal effect only because it is electronic [[EIDAS910]].
[=eIDAS=] Article 26(c) and Annex II require signature-creation data to be controlled and protected so others cannot validly trigger signing events [[EIDAS910]].
Regulation (EU) 2024/1183 updates [=eIDAS=] and sets the legal framework for remote qualified-signature components and related transition rules [[EIDAS910]] [[EIDAS2024_1183]].
Implementing Regulation (EU) 2025/1567 points to [=ETSI=] standards as the technical baseline used in this report [[EIDAS2025_1567]] [[ETSI119431_1]] [[ETSI319401]].
That Implementing Regulation enters into force in 2025 but applies from 19 August 2027 [[EIDAS2025_1567]].
When [=EU=] law pins a specific standard version, that pinned version is the legal reference for conformance checks [[EIDAS2025_1567]].
In Annex terms, Implementing Regulation (EU) 2025/1567 references ETSI EN 319 401 V3.1.1 for that legal conformance context [[EIDAS2025_1567]].
Trusted-list technical specifications are defined by Implementing Decision (EU) 2015/1505, as amended by Implementing Decision (EU) 2025/2164 [[TL2015_1505]] [[EIDAS2025_2164]].
[=ETSI=] [=TS=] 119 432 defines the remote-signing [=API=] model, but it does not itself define the full client authentication method [[ETSI119432]].
In the [=ETSI=] [=ESI=] series, [=TS=] 119 431-2 addresses components supporting [=AdES=] creation [[ETSI119431_2]].
[=ETSI=] [=EN=] 319 102-1 and [=TS=] 119 102-2 define signature validation procedures and validation-report structures used for evidence capture and replay [[ETSI319102_1]] [[ETSI119102_2]].
These controls reduce risk, but they do not automatically make every signer-intent claim independently replayable in a dispute.
Assets:
Main boundary split:
This split is the main reason residual dispute risk remains.
This report keeps four residual scenarios that can still exist under the current [=ETSI=] baseline.
Format per scenario: THREAT, MITIGATION (controls in force), and RESIDUAL (what still cannot be independently proven).
THREAT: A compromised signer-side frontend keeps a valid authenticated session and, after displaying content A, sends a different [=DTBSR=] (content B) in the signing request.
MITIGATION: [=ETSI=] requires controlled signature activation, [=SAD=] protection/binding controls, service-side access and security controls, and a remote-signing [=API=] message model for payload handling [[ETSI319401]] [[ETSI119431_1]] [[ETSI119432]].
RESIDUAL: Unless verifier-visible evidence includes a trusted-path binding between signer view and submitted [=DTBSR=], third parties may still lack independent proof that the signer approved the same content that was finally signed.
THREAT: A privileged insider (or misuse of privileged credentials) manipulates authorization state, service policy, or signing requests and causes a valid signature to be created, even when signing keys remain within the [=QSCD=] boundary and are not exported [[EIDAS910]].
MITIGATION: [=ETSI=] requires role separation, privileged-access control, monitoring, and audit/retention controls for trust-service operation and remote-signing service components [[ETSI319401]] [[ETSI119431_1]] [[ETSI119431_2]].
RESIDUAL: In a dispute, external reviewers may still lack an independently replayable event-level record proving that this exact activation path was free from privileged misuse.
THREAT: For one validation decision, the baseline can yield a valid status result while associated validation-report evidence elements remain optional in the report model; therefore a complete decision-time evidence snapshot is not guaranteed to exist for every case [[ETSI119102_2]] [[ETSI319102_1]].
MITIGATION: [=eIDAS=] and trusted-list acts define legal validation conditions and trust-list context, and [=ETSI=] EN 319 102-1 / TS 119 102-2 define validation and report structures that can include validation data used [[EIDAS910]] [[TL2015_1505]] [[EIDAS2025_2164]] [[ETSI319102_1]] [[ETSI119102_2]].
RESIDUAL: If decision-time validation inputs are not immutably retained and disclosed, whether by design gaps or privileged tampering, external replay cannot reconstruct the original decision path.
THREAT: Critical activation evidence remains internal, so third-party dispute replay is incomplete.
MITIGATION: Logging and governance obligations [[ETSI319401]] [[ETSI119431_1]] [[ETSI119431_2]].
RESIDUAL: External parties may still be unable to verify the full activation/evidence event history without relying on provider narrative.
Alternative direction: define recognition criteria under which consumer devices with specified secure components can serve as [=QSCD=]-class signature creation environments for decentralized legal trust workflows.
Companion report: https://z-base.github.io/lqscd-report/