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.
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.
All of the following:
The supplier went further than the standard asks.
All of the following:
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 the following:
An independent third party has proven when this was signed, and it will keep verifying for years.
All of the following:
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 the following:
You can prove this file has not changed. You cannot prove who signed it.
All of the following:
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.
Any one of the following:
This document does not prove what it claims. Do not rely on it without going back to the source.
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.
Tindom validates against every trust source it carries and names the one that vouched for each document, rather than refusing documents that sit outside a preferred list. What differs between regimes is not whether we check them — it is what a positive result legally means, and that is what sets the ceiling.
| 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. | Presumption under eIDAS Article 25 (signatures) / Article 35 (seals). | 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 |
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 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 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.
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.
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 qualified timestamp 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.
Content sits outside what the signature actually covers.
Sign the whole document. A partial signature vouches only for the part it covers, whatever the rest of the file appears to say.
First published version of the scale. Pre-release under semantic versioning: the thresholds have not yet been calibrated against a real distribution of documents, so they may still move.
What changed between versions, and which grades moved as a result. Subscribable by RSS.
Every version stays available so a grade issued under it can still be checked.