What should organisations verify before accepting a QES implementation?

What a QES check has to prove, not just what the marketing label says

A qualified electronic signature is only as strong as the weakest step in the trust chain. Before acceptance, organisations should confirm the trust service provider is actually qualified, that the signature device or equivalent QSCD claim is evidenced, and that enrolment identity proofing matches the assurance level they need. If one link is missing, the result may be lower-assurance AdES rather than true qualified-signature assurance.

The practical issue is that QES is a chained claim: provider status, signing device assurance, and identity proofing all have to line up. A front-end product screen or sales statement is not enough. Governance should ask for verifiable evidence for each layer, because a strong-looking signing flow can still fail the legal or assurance test if any upstream control is weak.

That means organisations should treat acceptance as a controls review, not a procurement checkbox. The right question is whether the implementation can demonstrate the full qualified-signature path end to end, including who enrolled the signer, how that identity was proofed, and what evidence shows the qualified device or equivalent protected the signing operation.

How to test the assurance chain in practice

Start with the provider’s qualified trust service status and the exact service scope covered by that status. Then verify how the signing key or signature creation device is operated, because a qualified label is not meaningful if the actual workflow does not use a QSCD or an equivalent qualified arrangement.

Next, review the enrolment process. Strong identity proofing matters because the signature binds legal effect to the asserted signer, not just to an authenticated session. If enrolment is weak, the signature may still be technically valid as a cryptographic object, but the organisation has less confidence that the signer was properly identified before issuance.

Finally, test the documentary evidence rather than relying on architecture diagrams. Acceptance artefacts should let a reviewer see the provider qualification, the signing assurance mechanism, and the proofing method as separate facts. If those facts only appear in different contracts, certificates, or assurance reports, the organisation should reconcile them before approval.

Why weak acceptance creates legal and operational exposure

When teams accept a QES claim without checking the full chain, they can inherit a false assurance boundary. The biggest risk is treating a service as qualified when it actually delivers a lower level of assurance, which can weaken non-repudiation, evidentiary value, and internal control confidence.

That risk is amplified when procurement, legal, security, and identity teams review different slices of the service in isolation. One team may validate vendor status, another may assume QSCD use, and a third may focus only on user login. The implementation can look compliant in pieces while still failing the end-to-end qualification requirement.

Failure mechanism: The service passes a label check, but the underlying trust service status, signing device assurance, or identity proofing does not meet the conditions required for a qualified signature.

Impact: The organisation may rely on an AdES-level service as if it were QES, creating legal challenge, audit findings, and avoidable trust failures in high-stakes signing workflows.

Practitioner Guidance

What to verify: Ask for evidence of qualified trust service status, explicit proof of QSCD use or an equivalent qualified signing arrangement, and the enrolment proofing method used for each signer. Do not accept a single certificate or marketing statement as sufficient proof.

Decision rule: If the provider cannot show all three elements as part of one coherent assurance chain, treat the implementation as unqualified for acceptance purposes until the gaps are closed or the use case is reclassified.

What practitioners underestimate: The acceptance decision is often less about the cryptography than about governance over the trust chain. A technically sound signature process can still be the wrong assurance grade if the provider scope and identity proofing do not support the claimed status.

Practitioner takeaway: Accept QES only when you can independently verify the provider, the signing device assurance, and the proofing behind the signer’s enrolment, because the label is only meaningful when the whole chain is evidenced.

Related resources from NHI Mgmt Group

• What should security and compliance teams verify before accepting a QES claim?
• How should organisations verify external security researchers before accepting reports?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?