How strongly this file proves, on its own, who signed it and that it has not changed — and how long it will keep proving it, without the signing platform.
Version 0.2.0 · pre-release, open for comment · published 2026-09-25
Superseded version. This version is kept published, unchanged, so that grades issued under it can still be checked against the rules that produced them. See the current version
Pre-release. This is a 0.x version under semantic versioning: the scale and its thresholds have not yet been calibrated against a real distribution of documents and may still change materially. Grades issued under a pre-release rubric carry no commitment and should not be cited as a settled assessment.
How it works
Three questions in strict order: integrity (has it changed?), then trust (does the identity chain to a recognised trust regime?), then durability (will it still verify years from now without anyone's help?). This is a ladder of necessary conditions, not a points total — a file receives the highest grade whose conditions it meets in full, and one failed gate caps it regardless of everything else.
The scale
A+
Beyond the standard
The supplier went further than the standard asks.
All of
Everything required for A.
ETSI baseline B-LTA — carries archive timestamps, so the proof can be refreshed as cryptographic algorithms age and outlives the certificate itself.
No material change after signing — nothing that alters what the document shows, and nothing the validation engine cannot classify (adding validation data, timestamps or further signatures after signing is how a signed PDF is legitimately extended, and does not count).
At least one marker from the closed list below.
A
The ETSI standard, met in full
This is what a properly signed document looks like. It proves who signed it, when, and that nothing has changed — on its own, offline, without the platform that made it.
All of
Validation outcome TOTAL_PASSED — intact, chain valid, not revoked.
Chains to a trust regime that reaches the top of the scale: an EU/EEA Trusted List, or a third-country list recognised through an eIDAS Article 14 mutual-recognition agreement.
Qualifies as a qualified electronic signature (QES) or qualified electronic seal (QESeal).
ETSI baseline B-LT or B-LTA — certificates and revocation data embedded, so the file verifies offline without contacting anyone.
The signature covers the whole document. Later revisions of the file are allowed only if they add nothing that changes what the document shows — adding validation data, timestamps or further signatures after signing is how a signed PDF is legitimately extended, and does not count.
B
Trusted and time-anchored
An independent third party has proven when this was signed, and it will keep verifying for years.
All of
Clears everything required for C, and carries a timestamp (ETSI B-T or better).
Misses at least one A requirement: the trust regime’s own ceiling is B; the validation outcome is not TOTAL_PASSED; it is an advanced rather than a qualified signature or seal; it is B-T rather than B-LT/B-LTA; or the signature does not cover the whole document.
C
Trusted, but decaying
Verifies today. There is no independent proof of when it was signed, and once the signing certificate expires or its revocation data goes offline, it may stop verifying entirely.
All of
Intact, and chains to a recognised trust regime.
Either ETSI baseline B-B — no timestamp, no embedded validation material — or a signature form outside the ETSI baseline profiles, whose durability cannot be assessed against them.
D
Provable file, unprovable signer
You can prove this file has not changed. You cannot prove who signed it. The result also states the grade the file’s own construction would reach with a certificate from a recognised provider — B or C — so a well-built document on a private root is not confused with a self-signed PDF.
All of
The signature verifies and the document is intact.
The certificate chains to no trust regime we recognise — self-signed, a private CA, or an unknown issuer.
E
A claim, without proof
Something was signed. This file cannot prove it. The proof sits with the signing platform, not with you. Nothing here is wrong — it is simply not self-proving.
All of
The file carries a signing claim — an attached evidence package, a platform audit trail, or a visual signature.
There is no cryptographic signature over the document that can be independently verified, so integrity cannot be checked at all.
F
Fails
This document does not prove what it claims. Do not rely on it without going back to the source.
Any of
The signed content has been modified since signing.
The signature is cryptographically invalid.
The signing certificate was revoked at the time of signing.
—
Not graded
No letter is issued when there is no signature and no evidence package to assess, or the file cannot be read. This is never shown as F. F means we checked and the document failed; absence of proof is a different statement from disproof.
Trust regimes and their ceilings
A validator applying the scale checks every trust source it carries and names the one that vouched for the document, rather than refusing documents outside a preferred list. What differs between regimes is what a positive result legally means — and that sets the highest grade the document can reach.
Regime
What it is
Legal weight
Ceiling
EU/EEA qualified
Member-state trusted lists under eIDAS Article 22, where the service is granted for qualified certificates. Published by each member state, aggregated by the European Commission.
Qualified signatures have the legal effect of a handwritten signature (eIDAS Article 25(2)); qualified seals carry a presumption of integrity and origin (Article 35(2)). Advanced signatures and seals — including on qualified certificates — carry neither.
A+
Recognised third country
Trusted lists of countries holding an eIDAS Article 14 mutual-recognition agreement — currently Ukraine and Moldova.
Legally equivalent to EU-qualified, by agreement.
A+
EU/EEA non-qualified
On a member-state trusted list, but the service is not granted for qualified certificates.
Supervised; no presumption.
B
National regulated
A national trusted list operating outside eIDAS recognition — the Swiss list (ZertES, Swiss Accreditation Service) and the UK list (Information Commissioner's Office). Real supervision, real audit, no EU mutual recognition.
Regulated nationally; no eIDAS presumption.
B
Commercial programme
The Adobe Approved Trust List — around 300 certificate authorities admitted under Adobe's published technical requirements and independent audit. This is what makes Adobe Acrobat show a green tick.
Contractual, not statutory; no presumption.
B
Not recognised
Chains to no list we carry: self-signed, a private certificate authority, or an unknown issuer.
None.
D
The A+ markers
This list is closed and published, so A+ is achievable rather than a matter of taste. A document needs everything required for A, plus the conditions listed under A+, plus at least one of these:
A qualified certificate held on a qualified signature creation device (QSCD).
A qualified electronic seal from the issuing platform over the finished document, in addition to the party signatures.
Two or more independent qualified timestamps.
A complete machine-readable evidence package embedded in the file.
Rules for every grade
A document's grade is the lowest of its signatures' grades — a contract is only as good as its weakest party's proof. Each signature also carries its own grade, so the roll-up is never opaque.
A grade is never shown as a bare letter. It always appears with the assurance level, the ETSI form, and the trust regime that vouched for it — the letter carries the legibility, the rest carries the defensibility.
A real document, walked through the ladder
A PDF sealed by an e-signing platform, validated by Tindom. It clears every gate up to the top of the ladder and is then held at B by two separate things — which is the ordinary case, not a failure.
IntegrityIntact — the signed content has not been modified since sealing.
RevocationNot revoked, checked live against the issuer's OCSP responder at validation time.
Trust regimeEU Trusted List (Norway), via a trust service granted for qualified certificates. Regime ceiling: A+.
Signature scopeCovers the whole document.
DurabilityPAdES-BASELINE-T. A timestamp proves when it was sealed, but the certificates and revocation data are not embedded — verifying it later means fetching them from the issuer, which will not be possible forever. A needs B-LT.
Assurance levelAdvanced electronic seal supported by a qualified certificate — not a full qualified electronic seal. A requires QES or QESeal.
Grade B. Trusted and time-anchored, and it will keep verifying for years — but two separate things stand between it and A, and either one alone would be enough to hold it there. Both are configuration changes on the signing platform's side, not re-architecture.
How to raise a grade
The scale is only useful if it says what to change. Each entry below is a ceiling a document can hit, what it means, and what would move it up.
Timestamped, but the file does not carry what is needed to verify it on its own later (B-T).
Embed the certificate chain and revocation data at signing time — B-T becomes B-LT. Usually a setting in the signing platform.
The signature alone, with no independent proof of when it was made (B-B).
Add a timestamp from a trusted timestamping authority at signing — B-B becomes B-T, and the document stops depending on a claimed signing time.
An advanced signature or seal, possibly on a qualified certificate, but not a qualified signature or seal in the eIDAS sense.
Issue on a qualified certificate held on a qualified signature creation device (QSCD). This is a change of product with the trust service provider, not a file-format change.
Self-contained, but without archive timestamps the proof cannot be refreshed as cryptographic algorithms age (B-LT).
Apply an archive timestamp — B-LT becomes B-LTA, and the evidence outlives both the certificate and the algorithms in use today.
The certificate chains to nothing we recognise — self-signed, a private authority, or an unknown issuer.
Sign with a certificate from a provider on one of the trust lists above. An internal certificate authority cannot reach beyond D, however well run.
The file records that signing happened, but carries no cryptographic signature we can check.
Embed a real signature in the document itself (PAdES for PDFs) rather than keeping the proof on the platform. This is the single largest step available — it moves a document from E to a graded rung.
Something was added to the file after signing that changes what the document shows, or that the validation engine cannot classify — or the signature covers only part of the content.
Sign the whole document, and make any later change as a new signed revision. Adding validation data, timestamps or further signatures is fine; editing content after signing is not.
The certificate chains to a list whose ceiling is B — a non-qualified EU/EEA service, a national list outside eIDAS recognition, or the Adobe Approved Trust List.
Sign with a qualified certificate from a provider on an EU/EEA Trusted List. The file format is not the limit here; the trust regime is.
The signature is intact and trusted, but the validation engine could not reach a definitive pass — for example because revocation status or a certificate in the chain could not be confirmed.
Embed the full certificate chain and revocation data at signing (B-LT), so the result does not depend on what can be fetched at validation time.
A trusted signature in a form outside the ETSI baseline profiles, so its long-term durability cannot be assessed against them.
Produce signatures to an ETSI baseline profile — PAdES for PDFs, XAdES, CAdES or JAdES otherwise.
A signature is present, but whether the signed content is intact could not be determined.
Check that the file is the original signed version and has not been converted or re-saved after signing.
Meets the ETSI standard in full, but something added after signing changes what the document shows or cannot be classified.
Make later changes as new signed revisions rather than edits to a signed file.
The ETSI standard is met in full, including archive timestamps. A+ needs one more thing from the closed list above.
Add one of the listed markers — for example, embed a complete machine-readable evidence package in the file.
The published text and the grading code now say the same thing. (1) Signature scope: validation data, timestamps and further signatures added after signing no longer count as content outside the signature — this is how PAdES B-LT and B-LTA are built, and under 0.1.0 it held every such PDF at B. (2) The A+ condition "no post-signing modification" now means no material change, for the same reason. (3) A multi-signature document now reaches A+ only if every signature meets A in full; before, the result could depend on signature order. (4) The B and C criteria list every reason a document lands there, and B requires a timestamp rather than a qualified one — the qualification of the timestamp was never checked. (5) A D now states the grade the file’s own construction would reach with a recognised certificate. (6) Corrected the legal weight of the EU/EEA qualified regime. Released as 0.2.0 because the scale is still pre-release; under the published policy the change is major, since one grade can go down.
Grades affected: Up: PAdES B-LT/B-LTA documents held at B only by signature scope (B → A); B-LTA documents held at A only by permitted additions can reach A+. Down: a multi-signature document graded A+ where one signature was held at A by something other than the missing marker (A+ → A). No change to the letter of a D. Separately, Norwegian BankID SDO files are no longer graded (previously a false F) and are refused as not yet supported.