CIRPASS-2 registerDPP adapter live against the production registryEU DPP Registry: live since 20 July 2026
PassportLabEU DPP Registry
CIRPASS-2 format · registerDPP endpoint implemented

Registry-ready
and registering today

The EU DPP Registry has been live since 20 July 2026. PassportLab submits directly to it via the CIRPASS-2 registry format — with working registry integration, hash-chained audit records, and W3C VC proofs. Competitors are writing blog posts. We have running code.

Last updated: August 2026
Art. 3(c) · Official Verification Platform

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.

DPP Verification · Art. 3(c) checksPASS
GS1 Digital Link resolution · ISO/IEC 18975
W3C VC 2.0 proof · Ed25519 signature
ESPR data schema conformance · EU 2024/1781
SHACL shape validation · CIRPASS-2 profile
EPCIS 2.0 event log export
Stakeholder role-based field visibility
Art. 3(c)
EU DPP Registry — official verify platform clause
Today
passportlab.io/verify available to any operator, zero setup
No date
Commission platform launch — no public timeline
Hash-Chained Audit Log

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.

PassportAuditLog — hash chain verificationSHA-256
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
Block 1
DPP created
a3f8…c120
Block 2
Material data updated
7d2e…b459
Block 3
VC proof issued
f19a…0d83
CIRPASS-2 · registerDPP Integration

Submitting to the live registry today.

PassportLab already speaks CIRPASS-2 format. Every DPP is pushed to the registry 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.

The EU DPP Registry has been live since 20 July 2026, with a public testing environment and API. Registered products receive a proof-of-registration document. Art. 77/78 delegated acts governing the full battery passport data model are still pending — our schema is versioned to absorb those changes without a migration project.

POST /metadata/v1/registerDPPCIRPASS-2
{
  "upi":              "DPP-04012345000010-A001",
  "reoId":           "DE123456789012",  // EORI
  "liveURL":         "https://www.passportlab.io/dpp/…",
  "backupURL":       "https://backup.passportlab.io/…",
  "granularityLevel": "item",
  "facilitiesId":    ["GLN-4270054032051"],
  "deactivated":     false
}
CIRPASS-2 registerDPP payload
UPI, reoId (EORI), liveURL, backupURL, facilitiesId
GS1 Digital Link / UPI normalization
GTIN + serial → UPI per CIRPASS-2 spec
Backup URL + deactivation flag
Art. 15 continuity fields wired to product model
Content negotiation · JSON-LD + AAS
Accept: application/ld+json → UNTP/CIRPASS-2 @context
EU DPP Registry endpoint
Live since 20 July 2026 — submitting registrations today
Readiness Checklist

What's done. What's pending on the EU side.

PassportLab's registry integration is not a roadmap item. These are shipped features, submitting to the live EU DPP Registry today. The remaining gaps are legally and procedurally blocked on the Commission — not on PassportLab.

CIRPASS-2 registerDPP format
POST /metadata/v1/registerDPP with full CIRPASS-2 payload — UPI, reoId, liveURL, backupURL, granularityLevel, facilitiesId, deactivated.
GS1 Digital Link / UPI normalization
Every DPP resolves via /01//21/ per GS1 Digital Link ISO/IEC 18975. GCP 42700054032 registered with GS1 Germany.
Hash-chained audit log · cryptographic integrity
PassportAuditLog is append-only, SHA-256 hash-chained, with DB-level immutability enforced by MySQL triggers.
W3C VC 2.0 + Ed25519 proofs
Every passport ships a W3C Verifiable Credential with Ed25519 signature and DID:Web identity. SD-JWT selective disclosure is available for all regulated data categories.
eIDAS QSealC storage architecture
Key storage is designed for QTSP-issued qualified electronic seals. Signing infrastructure is in place; QTSP procurement is a legal calendar item.
EPCIS 2.0 event repository
Full supply-chain event log per EPCIS 2.0 spec, exportable as EPCIS Document. Operator chain with transfer endpoint live.
EU DPP Registry endpoint
Live since 20 July 2026 with a public testing environment and API. PassportLab registers products and returns the proof-of-registration document.
QTSP Q-Seal procurement
Requires a qualified trust service provider under eIDAS 2.0. Procurement is on the legal calendar, not a technical gap.
Blocked: legal calendar

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. In July 2026, CEN/CLC JTC 24 formally recognised six of these EN standards, including EN 18222 (interface/API layer). 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.