EN 18221 — Digital Product Passport lifecycle continuity, backup and archival

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. Under ESPR Article 11 the passport that documents each of them must remain resolvable for the same duration, regardless of what happens to the brand that originally issued it.

EN 18221 specifies how. It is the least glamorous standard in the JTC 24 suite — there are no consumer scan interactions to design, no UI decisions to make — and the most consequential for the DPP framework's long-term credibility.

What EN 18221 requires

Six technical requirements make up the substance of the standard.

1. Backup replication is mandatory, not optional

Every passport that has been placed on the market must have a redundant copy held by a party independent of the primary resolver. "Placed on the market" is a defined term borrowed from CE-marking practice: the moment a product with a passport is first offered for sale in the EU.

Independence is enforced structurally. The primary resolver operator (typically the brand or the platform the brand contracted) must have a written data-processing agreement with a backup-host operator that is not a subsidiary or corporate parent. The intent is that a single-company insolvency cannot destroy the passport archive.

DPP Agent implements this via the backup-host provider system. The default backup for tenants who do not specify one is dpp-backup.com, an independently-operated backup platform. Enterprise tenants can specify Blippa, their own S3, their own Postgres, or any endpoint that implements the BACKUP-HOST-PROVIDER-SPEC contract.

2. Replication semantics are at-least-once, hash-verified

A DPP write to the primary resolver must trigger a write to the backup host with the same content and a matching cryptographic hash. The backup host verifies the hash on receipt and rejects mismatched payloads. The primary resolver retries on failure until the backup acknowledges.

The at-least-once guarantee means the backup can occasionally receive a duplicate write (network partition, cross-region retry). The backup is required to be idempotent: writes are keyed by (passport_id, revision_number) so re-delivering the same revision is a no-op. Two different revisions with the same passport_id create a version history the backup must retain.

3. Retention is category-derived, minimum ten years

Retention windows are set by the ESPR delegated act for each product category, not by EN 18221 itself. The standard establishes the minimum floor — ten years from the date the passport was placed on the market — and requires the backup host to preserve the passport for the greater of that floor and the delegated-act requirement.

Practical retention windows for categories currently in scope:

4. Read access continues after primary operator insolvency

If the primary resolver operator ceases operations (voluntary shutdown, insolvency, corporate acquisition where the acquirer discontinues the platform), passports must remain resolvable via the backup host. The standard specifies a fallback resolution protocol: DNS at the resolver host is redirected (by court order in insolvency proceedings, or by pre-agreed continuity contract otherwise) to the backup host, which serves the passports read-only.

For this to work reliably the standard imposes three conditions:

• The backup host must implement the full EN 18219 resolver semantics, not just a raw-data endpoint. Consumers scanning a passport after a brand's insolvency must get the same rendered HTML they got before.
• The backup host must maintain a public record of which primary operators it backs up. This lets courts and administrators route DNS redirections without a case-by-case investigation.
• The backup host operator must be financially independent enough to fund read-serving for the full retention period. In practice this means an escrow-funded model or a certified backup-host category with regulatory oversight.

5. Passport versioning must be preserved

DPPs are updated over time: composition data is refined, journey steps are added, corrections are issued. The backup host must retain the full revision history, not just the latest snapshot. This is what lets regulators reconstruct "what was the passport actually claiming on the date this product was placed on the market" — a question that comes up in enforcement cases and product-safety investigations.

Revisions are stored as immutable records keyed by (passport_id, revision_number, timestamp). Deleting a revision is prohibited. Withdrawal of a passport (product removed from market) sets a withdrawn_at timestamp on the latest revision but does not remove prior revisions.

6. Audit trail

Every backup write and every read against the backup must be audit-logged with retention matching the passport retention window. The audit log is what enables post-incident forensics, compliance-report generation, and regulatory investigations. The standard specifies the audit-event vocabulary (write, read, admin-access, retention-expire, redirection) but does not prescribe storage technology.

Common mistakes

Treating backup as a nightly database dump. A nightly dump of the primary Postgres to S3 does not implement EN 18221. It has no independence property (same operator), no hash verification, no at-least-once semantics, and no versioning of individual passports. Regulators will not accept it as backup replication.

Not testing the failover path. Brands set up backup replication and never test that a resolver switchover actually works. When the primary operator has an outage, the DNS redirect procedure has never been rehearsed and takes weeks instead of hours. Fix by running a quarterly failover drill in a staging environment.

Assuming ten years is enough for everything. Construction products, some machinery, and heirloom-quality furniture regularly outlive the ten-year floor. The retention window is minimum, not maximum. Reserve budget and storage for realistic product lifetimes.

Backing up to a subsidiary. The backup host being a corporate subsidiary of the primary operator defeats the independence property. When a group insolvency filing hits both entities at once, both go dark simultaneously. The standard requires an unrelated third party.

How DPP Agent implements EN 18221

DPP Agent's implementation covers all six requirements:

• Backup providers — the tenant admin exposes three canonical backup options (Blippa, dpp-backup.com, self-host to S3/Postgres/Mongo) plus a spec for custom providers. Independence is by construction: each provider is a separate legal entity from BlippaCo AB.
• Replication semantics — migration 077 adds the publish_outbox table that queues every DPP write for delivery to the backup host. The delivery cron runs every minute, retries on failure, and idempotency is keyed by (passport_id, revision_number).
• Retention — passports carry a category-derived retention_until field validated at write time. Archived passports remain resolvable via the resolver but are excluded from the active-DPP count for billing purposes.
• Failover — the backup host implements the full EN 18219 resolver so DNS redirection to the backup produces the same consumer experience.
• Versioning — the dpp_revisions table (migration 073) records every write immutably with author, timestamp, and diff.
• Audit trail — the audit log captures every backup write and every read against a backup passport, retained for the same window as the passports themselves.

Practical checklist

• Every published DPP has a designated backup host that is a separate legal entity
• Backup writes carry a cryptographic hash verified by the backup host
• Retry semantics guarantee at-least-once delivery
• Revision history is preserved without deletion of prior revisions
• Retention windows are set by category, not a single default value
• Failover from primary to backup has been rehearsed
• Audit log records write, read, admin-access and retention-expire events
• The backup host implements the full EN 18219 resolver, not just raw storage

Standard reference

CEN/CENELEC JTC 24. EN 18221:2025 — Digital Product Passport — Lifecycle continuity, backup and archival services.

Related regulatory references:

• ESPR Article 11 (retention requirements)
• Regulation (EU) 2023/1542 Article 77 (battery-specific backup)
• ISO 27001 Annex A.17 (business-continuity controls, referenced for backup-host certification)