Who is accountable if a signature service claims QES but does not meet the standard?

Why This Matters for Security Teams

A QES claim is not just a product label. It is a control assertion with legal and operational consequences, especially when a signature service is used for contracts, regulated workflows, or cross-border transactions. If the service does not actually meet the standard, the failure can affect evidentiary weight, non-repudiation, and downstream assurance decisions. That is why accountability has to be traced across procurement, legal, security, and governance, not left to the provider alone.

Security teams often get this wrong by treating certification language as equivalent to ongoing compliance. In practice, the relevant question is whether the service still meets the standard in the jurisdiction where it is used, whether identity proofing and signer authentication are supported at the required level, and whether audit evidence exists to prove it. NIST guidance on control selection and assessment, such as NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful here because it reinforces the need for evidence, continuous monitoring, and accountability for inherited controls.

In practice, many organisations discover the gap only after a signature is challenged in dispute, audit, or regulatory review, rather than through intentional control testing.

How It Works in Practice

Accountability for a failed QES claim is usually shared, but not evenly. The provider may be responsible for misrepresenting capabilities, failing to maintain qualified status, or operating outside the scope of its approved trust services. The organisation selecting the service remains accountable for due diligence, risk acceptance, and ensuring the service fits the legal environment in which signatures are used. Compliance and legal functions are accountable for validating that the control claim maps to actual regulatory requirements, not just marketing language.

Operationally, the first step is to verify the trust service status and the exact assurance scope. That includes checking whether the provider is qualified in the relevant jurisdiction, whether the signature process supports the required identity proofing, and whether certificate issuance, revocation, timestamping, and audit logging are all covered. Where digital identity assurance is part of the workflow, NIST SP 800-63 Digital Identity Guidelines helps teams assess whether identity proofing and authentication are aligned to the trust level the business expects.

• Confirm the provider’s qualified status and the specific legal regime it applies to.
• Review contracts for responsibility, indemnity, audit rights, and incident notification.
• Test the end-to-end signing workflow, not just the vendor certificate or attestation.
• Keep evidence of monitoring, revocation checks, and periodic revalidation.

From a governance standpoint, the organisation should define who approves the assurance claim, who owns periodic reassessment, and who escalates discrepancies. In higher-risk environments, that includes mapping the service into broader trust and resilience controls using ENISA guidance on remote electronic signature schemes and, where the signatures support regulated operations, linking the control to operational resilience expectations under DORA. These controls tend to break down when the service is resold through a chain of intermediaries because responsibility for the actual trust service, the proofing process, and the evidence trail becomes difficult to prove.

Common Variations and Edge Cases

Tighter assurance checks often increase procurement friction and legal review time, requiring organisations to balance speed against evidentiary confidence. That tradeoff is especially visible when teams want a fast integration but the signature use case has regulatory weight.

Best practice is evolving for situations where a provider offers multiple signature tiers, operates across several jurisdictions, or bundles QES-like claims with non-qualified services. There is no universal standard for internal accountability in those mixed-service environments, so the safer approach is to document exactly which service instance, trust list entry, and certificate policy were approved. If the provider’s qualified status lapses after onboarding, the organisation may still own the governance failure if it did not monitor the claim over time.

Edge cases also arise when the service is embedded in a larger identity platform or workflow automation stack. In those cases, the direct provider may be technically qualified, but the organisation can still lose assurance if downstream systems alter the signer journey, weaken identity verification, or bypass required audit controls. For that reason, the compliance function should treat QES as a living control with periodic validation, not a one-time procurement checkbox. Where regulated signatures support financial or cross-border transactions, the evidence chain should be reviewed alongside privacy and assurance obligations under GDPR.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access is misused in a public service environment?
• Who is accountable when a signature is challenged in court or audit?
• Who is accountable when a cracked service account is used for lateral movement?
• What problem does ownership attribution solve for service accounts and API keys?