ETSI TS 119 511 explained: PDS, PGD, AUG and WST, WTS, WOS

If you have read an archiving or e-signature vendor’s compliance page recently, you may have met a line like “PDS + WST, policy 0.4.0.19511.1.1” and moved on. Those six letters are the most useful thing on the page. They say exactly what the service keeps, for how long, and who is responsible when the cryptography underneath starts to age.

They come from ETSI TS 119 511, the European standard for preservation services. This post explains the two axes it uses to describe one — the preservation goal and the storage model — what “qualified” does and does not mean here, and how to check a vendor’s claim in five minutes. At the end, TrustBeat serves as a worked example.

The problem a preservation service solves

A qualified electronic time-stamp proves that data existed at a point in time. It is verified with the time-stamping authority’s certificate — and that certificate lasts a few years. Contracts, invoices, clinical records and source code often have to be provable for decades. Once the certificate has expired, or the algorithms behind it are considered weak, a verifier can no longer rely on the time-stamp alone.

The fix is old and well understood: before the current proof stops being verifiable, put a new time-stamp over it, and keep doing that for as long as the evidence must live. RFC 4998 (Evidence Record Syntax) standardises the data structure for this. ETSI TS 119 511 standardises the service around it: the policies, security controls, documents and promises a provider must make so that someone else can trust the evidence in twenty years’ time.

Axis 1 — the preservation goal: what is being preserved

TS 119 511 defines three goals. A service may support one or several.

The difference between PDS and PGD is the one that matters most in practice. PDS keeps a signature valid: the evidence must show that the signature was valid at a time when its certificate and algorithms were still trustworthy. PGD makes no statement about signatures at all; it proves the existence and integrity of data — in the standard’s words, “proofs of existence over long periods of time of general data whether this data is signed or not”. A PDF with no signature, a CSV export or a hash of a container image can all be preserved under PGD.

Axis 2 — the storage model: who keeps what

Two details are easy to get wrong. First, “with storage” does not have to mean the provider stores your documents: the preservation object can be a hash of the data, and the standard explicitly allows that. Second, WOS is strict. It means the service keeps nothing — not the data, not a hash, not the evidence. A service that keeps only hashes and evidence is not WOS; it is WST or WTS.

The practical question behind the storage model is simple: in year twelve, when a time-stamp certificate is about to expire, whose job is it to renew the evidence? With WST it is the provider’s, for the whole preservation period. With WTS and WOS it ends up being yours, which means you need your own process, your own monitoring of certificate lifetimes and algorithm strength, and someone who still remembers why it matters.

Goal + model = profile

A provider describes each combination it offers in a published preservation profile: the goal, the storage model, accepted input formats, the evidence format, the preservation period and a link to the preservation evidence policy that says how evidence is built and renewed. Above the profiles sits a practice statement describing how the service is actually run — infrastructure, subcontractors, availability, export, what happens at the end of the period and if the provider shuts down. TS 119 511 requires all three to be public. If a vendor claims the standard but cannot point you to them, the claim is marketing.

Each service also states the policy it follows, by object identifier. The main policy is 0.4.0.19511.1.1; it covers everything in the standard except Annex A, which holds the extra requirements for qualified services.

What “qualified” means here — and why PGD can never be qualified

Under the eIDAS Regulation, a qualified preservation service exists only for qualified electronic signatures (Article 34) and qualified electronic seals (Article 40). That is goal PDS. TS 119 511 says so directly: a qualified preservation service “is only mentioned for the preservation of QES, not for the preservation of general data”.

So a PGD service cannot be on an EU Trusted List as a qualified preservation service, however good it is. What it can do is follow the main policy and, eventually, be assessed against it by a conformity assessment body under ETSI EN 319 403 — that route is open to non-qualified services too. Until such an assessment, the honest wording is “designed to ETSI TS 119 511”, not “compliant” or “certified”. Treat any other phrasing on a PGD service with suspicion.

None of this makes PGD evidence weak. The time-stamps inside it can still be qualified electronic time-stamps, which carry their own legal presumption of accuracy of the date and time and of the integrity of the data (eIDAS Article 41). What the service adds is the guarantee that this presumption can still be demonstrated long after the original certificate has expired.

Checking a vendor’s claim in five minutes

1. Which goal and which model? If the answer is vague, or “WOS” for a service that clearly keeps your hashes, stop there.
2. Is the profile published, with an identifier? And is the evidence policy it references public too — with algorithms, time-stamping authorities and renewal rules?
3. Is there a practice statement? Look for export, end of period and termination. A preservation service that cannot tell you what happens if it closes is not one.
4. “Designed to” or “assessed against”? If assessed, ask for the assessment body and the report date. If qualified, it must be PDS, and it must be on the EU Trusted List.
5. Can you verify the evidence without the vendor? The evidence should be in a standard format — RFC 4998 evidence records, or AdES signatures for PDS — that an independent validator such as the European Commission’s DSS accepts. Proprietary verifiers are lock-in.
6. Can you take everything with you? A WST service must offer an export-import package so your evidence can move to another provider.

Worked example: TrustBeat is PGD + WST

TrustBeat’s Document Anchoring proves that a document existed at a point in time, without the document ever leaving your systems: you submit its SHA-256 hash, and every ten minutes all submitted hashes are combined into one hash tree whose root gets a qualified electronic time-stamp from an EU qualified trust service provider (SK ID Solutions, with EuroCert as fallback).

Since 14 September 2026, every document anchor is also a preservation object under the profile pgd-wst-v1:

• Goal PGD — we prove the existence of data, not the validity of a signature. The data is your hash; we never receive the document.
• Model WST — we keep the hash, its hash tree, the time-stamps and an RFC 4998 evidence record for 30 years from submission, and we renew the record with a new time-stamp 90 days before the certificate behind the last one expires. You do not have to do anything to keep the evidence alive.
• Main policy 0.4.0.19511.1.1, designed to — not yet assessed against. It cannot be qualified: it is PGD.
• Included on every plan, including Free, with nothing to switch on.

The status of any anchor shows which profile covers it and until when:

GET https://api.trustbeat.eu/v1/anchor/{id}/status

"preservation": {
  "profile": "https://trustbeat.eu/preservation/profile/pgd-wst-v1",
  "preserve_until": "2056-10-11T09:14:03Z"
}

Why WST and not WTS? Interestingly, the standard’s own illustration of temporary storage — evidence records produced daily from the hash values presented during the previous 24 hours — is close to how our batching works. But what matters is the promise, not the batching. With WTS, renewing the evidence after the retention period would be the customer’s job. Our promise is “anchor and forget: we keep the proof alive”, which is WST.

One stated deviation. TS 119 511 expects a service with storage to let subscribers delete stored objects. We do not, before the end of the preservation period, and we say so in the practice statement: each evidence record is built from all the hashes in its batch, which belong to many customers, so removing one would make every other record in that batch unverifiable. A hash on its own reveals nothing about your document.

Verify it yourself

Every anchor’s evidence record can be downloaded from a public endpoint, without an account:

GET https://api.trustbeat.eu/v1/public/proof/{id}/evidence-record.ers
→ RFC 4998 EvidenceRecord (DER), validation data embedded

Upload the .ers file together with your original document to the European Commission’s DSS demonstration web app. It validates the record against the EU Trusted Lists without any TrustBeat software involved. We run that check on production records ourselves, and we also run Germany’s BSI ERVerifyTool (TR-ESOR, Basis-ERS profile) over them offline: evidence records created since 11 October 2026 pass its format checks. Neither tool is ours, and neither endorses anyone — that is the point of checking with them.

The profile, the evidence policy and the practice statement are public at trustbeat.eu/preservation. The product page is Long-Term Preservation, and the binding terms are in Terms of Service §4.

The short version

• PDS keeps a signature valid. Only PDS can be qualified under eIDAS.
• PGD proves that data existed and is unchanged, signed or not.
• AUG extends a signature and hands it back.
• WST: the provider keeps the evidence alive for the whole period.
• WTS: the provider keeps it for a while, then it is yours.
• WOS: the provider keeps nothing at all.

If you need documents to stay provable for decades and do not want to run renewal yourself, you want WST. If you cannot or must not hand over the documents, you want a service that preserves hashes. TrustBeat does both — start free, no card.