EN 18221 — Data storage, archiving, and data persistence

Products outlive companies. A jacket bought in 2027 will still be worn in 2037; a battery installed in 2029 will still be recycled in 2039. EN 18221:2026 is the JTC 24 standard that says where a passport's data lives, how its history is kept, and who still has it when the company that issued it is gone.

This page paraphrases the standard clause by clause. It is not a substitute for the text, which is sold by the national standards bodies (SIS in Sweden, DIN in Germany, BSI in the UK).

How long is "the lifetime"?

The standard does not set a number of years, and no clause in it does.

It defines digital product passport lifetime (3.4) as the period during which the passport is required by regulation to be available to anyone with a right to access its data. Every duration requirement in the document then points at that definition. So the answer to "how long must this be kept" comes from the ESPR delegated act for the product category — not from EN 18221.

Anyone quoting a fixed floor from this standard is quoting something that is not in it.

What the standard requires

4.1 — Storage

The passport is stored by whoever created it, or by a service provider acting on their behalf. Stored data must be accurate, complete, and reflect all changes up to the current state, and the passport must be reachable online over the EN 18216 protocols for the whole lifetime.

Storage must hold data such that both the human-readable and the machine-readable forms EN 18216 requires can be generated from it. The architecture is explicitly decentralised and the standard imposes no storage technology.

A passport may reference other passports; passports are always stored independently of one another.

The storage requirements apply to the main and the back-up service provider alike. Both must protect against data loss, malicious modification and unauthorised access, referencing EN 18239 (access rights, under preparation) and EN 18246 (data authentication and integrity, under preparation).

4.2 — Archiving

Archiving starts at the first change to the initial passport. Before a first change there is nothing to archive.

Archived versions are stored twice: by the back-up service provider, and by the creator of the passport or a main service provider acting on its behalf.

All archived versions are maintained for the passport lifetime. All changes are archived, with one carve-out: changes explicitly identified as exempt by product-specific requirements — the standard's own example is real-time sensor data.

Archived attributes carry the same access restrictions as the corresponding attributes in the current passport. The version as it stood at a given point in time must be retrievable by authenticated and authorised actors — so the archive is queryable, not a write-only log.

Integrity and originality of archived versions follow EN 18246. For the archive itself the standard recommends (should, not shall) ISO 14721 — the OAIS reference model — naming the subclauses to take into account.

4.3 — Data persistence

When a product is placed on the market, a back-up copy can be required to be made available through a service provider. The standard's wording is conditional; whether it is required for a given product comes from that product's rules.

Where it applies, the back-up holds the most recent version and all required historical versions. Back-up attributes carry the same access restrictions as the original.

Two different access rules, worth separating:

• Specifically authorised users can reach the passport at the back-up provider during the lifetime.
• General access at the back-up provider opens once the economic operator is no longer active on the market.

That second sentence is the continuity mechanism in the standard. It is a change in who may read from the back-up, not a redirection protocol — EN 18221 says nothing about DNS, court orders or registries of backed-up operators.

4.4 — Attached documentation

Additional digital documentation is included in the passport directly or by reference, and made accessible through it. It must be presented so a user can download and save it on a device and reach it at any time, and be online for the whole lifetime.

The back-up service provider is responsible for storing and making accessible mandatory documentation included in the passport, whether it was included directly or by reference. A link is an acceptable way to include a document; it does not move the obligation to keep that document reachable onto whoever hosts the link.

4.5 — Replication

The passport and all its changes are replicated to the back-up service provider as required by 4.3.

The standard sets no interval. It requires the frequency to be sufficient to minimise data loss if the economic operator leaves the market, giving a maximum Recovery Point Objective as the example of how to express that, and allows product-specific rules to define it further.

Replication should be possible over the standardised lifecycle API of EN 18222, and may also use other mutually agreed secure mechanisms. Either way it runs over an EN 18216 data-exchange protocol.

Who is who

The standard's definitions matter for reading the rest of it:

• Digital product passport service provider (3.3) — an independent third party authorised by the economic operator that places the product on the market, processing passport data to make it available to those with a right to access it.
• Main service provider (3.3.1) — hosts the passport on behalf of the economic operator, when the operator chooses not to host it themselves.
• Back-up service provider (3.3.2) — hosts the back-up copy.

The independence in 3.3 is independence from the economic operator. The standard does not state a corporate-independence test between the main and the back-up provider.

Where DPP Agent stands

Honest status rather than a checklist of green ticks.

Implemented.

• Versioned writes. Every passport write records a revision with author, timestamp and a field-level diff, and prior revisions are not deleted. A withdrawn passport keeps its history and returns 410 with lifecycle information rather than disappearing.
• Storage supporting both output forms — the resolver generates the human-readable page and the machine-readable JSON-LD from the same stored row, negotiated by Accept per EN 18216.
• Back-up host selection. Tenants designate a back-up provider; the default is dpp-backup.com, and enterprise tenants can point at another provider, their own S3 or Postgres, or any endpoint implementing the backup-host contract.
• Attached documentation by reference, with the document catalogue tracking what each passport points at.

Not yet true, and stated here because a compliance page that overclaims is worse than one that admits a gap.

• Replication has not run. The back-up host is selected on a number of tenants and the replication log is empty. Until it runs, 4.3 and 4.5 are configuration rather than implementation.
• Archiving at the back-up provider (4.2 requires archived versions in both places) cannot be satisfied while replication has not run.
• 4.4's requirement that the back-up provider store mandatory documentation, and not only its address, is not implemented.

Standard reference

CEN/CENELEC JTC 24. EN 18221:2026 — Digital product passport — Data storage, archiving, and data persistence. Published as SS-EN 18221:2026 (en) by SIS. Sold per single-user licence by the national standards bodies.

Normatively related and still under preparation at the time EN 18221 was published: prEN 18239 (access rights and security) and prEN 18246 (data authentication, reliability, integrity). Clauses 4.1 and 4.2 depend on both.