Registry-ready
before the registry is open
The EU DPP Registry is being built. PassportLab is already inside the CIRPASS-2 pilot pipeline — with working registry integration, hash-chained audit records, and W3C VC proofs. Competitors are writing blog posts. We have running code.
The Commission's verify tool is coming. Ours works today.
The EU DPP Registry regulation includes Art. 3(c): an official verification platform, operated by the Commission, that market surveillance authorities and customs will use to check passports in the field. That platform has not launched. It has no public preview date.
Until it does, passportlab.io/verify runs the same checks: GS1 Digital Link resolution, W3C VC proof verification, ESPR schema conformance, and SHACL shape validation against the CIRPASS-2 data model. When the Commission platform goes live it will consume the same signed DPP endpoints PassportLab already publishes today.
Registry downtime doesn't break your compliance record.
The regulation flags availability risk for high-throughput operators: if the central registry is unreachable, downstream verification fails. Art. 15 imposes continuity requirements, but the Commission's uptime SLA is not yet specified.
PassportLab's PassportAuditLog is a hash-chained, append-only record — every field change is cryptographically linked to the previous entry. MySQL triggers enforce DB-level immutability; no application-layer delete or update can silently remove an entry. This is the record that survives a registry outage.
entry[n].prevHash = SHA-256(entry[n-1]) entry[n].hash = SHA-256(entry[n] + prevHash) integrity = chain unbroken since genesis db trigger = DELETE / UPDATE → rejected
One config swap away from production.
PassportLab already speaks CIRPASS-2 format. Every DPP is pushed to the registry pipeline via POST /metadata/v1/registerDPP with the full required payload: UPI, EORI-based reoId, live URL, backup URL, granularity level, facilities list, and deactivation flag.
When the Commission's implementing act lands and the production registry endpoint goes public, the switch is a single environment variable — not a migration project.
{
"upi": "DPP-04012345000010-A001",
"reoId": "DE123456789012", // EORI
"liveURL": "https://passportlab.io/dpp/…",
"backupURL": "https://backup.passportlab.io/…",
"granularityLevel": "item",
"facilitiesId": ["GLN-4270054032051"],
"deactivated": false
}What's done. What's pending on the EU side.
PassportLab's registry integration is not a roadmap item. These are shipped features. The remaining gaps are legally and procedurally blocked on the Commission — not on PassportLab.
Understand your registry position before your competitors do.
Book a 30-minute call. We'll map your products to their CIRPASS-2 UPI format, confirm your EORI is wired correctly, and show you what a registry submission looks like end-to-end on your actual data.
Standards notice: Standards status: EN 18216:2026–EN 18223:2026 — including the data-carrier standard EN 18220 and the data-persistence standard EN 18221 — were published by CEN/CENELEC on 27 May 2026. They are not yet cited in the Official Journal of the EU, so they do not yet confer formal presumption of conformity. EN 18239 (access rights) and EN 18246 (data authentication) remain in draft, expected late 2026. ESPR (EU 2024/1781) delegated acts and per-category Annex I requirements are still being finalised. CBAM Reg. 2023/956 obligations continue to evolve under Commission guidance. Results are a readiness indication based on the latest available standards and drafts, and do not constitute legal advice.