Who Holds the Proof — the eCMR Record or the Platform?

July 7, 2026 ·Gustav Poola ·

ecmreftiun-cefactdata-modelverifiable-credentialsdigital-signatureeidassovereigntytruth-anchorcross-border

39 countries accept eCMR. eFTI becomes mandatory in July 2027. Yet the data model underneath still records signers as plain text — and most digitisation puts the proof in the platform, not the record. That architecture choice decides who owns the truth.

Who Holds the Proof — the eCMR Record or the Platform?

39 countries have ratified the eCMR protocol (full list). From July 2027, every EU authority must accept digital freight data under eFTI. The consignment note is going digital — that fight is over. The fight that matters now is architectural: when a dispute lands three years after delivery, does the proof live inside the eCMR record itself, or inside whichever platform happened to process it? One of these answers survives a platform migration, a vendor bankruptcy, and a border. The other does not.

For seventy years, the paper CMR did something quietly remarkable: it was self-contained. The yellow copy in the driver's cab carried everything a Belgian judge, a Polish insurer, or a Turkish consignee needed to assess it — names, stamps, signatures, remarks — with no phone call to a third party required. Verification was manual and forgeable, but it was portable. The document was the evidence.

Digitisation, done carelessly, breaks exactly that property. And most current eCMR implementations are doing it carelessly.

The Document Layer Is Solved

The case for eCMR is closed on the economics: processing a paper CMR costs €6.23 against €1.69 for its electronic equivalent, and takes 23 minutes against 9. Ratification keeps expanding. The eFTI Regulation forces every EU member state to accept electronic freight information from July 2027, and its Article 5 already mandates identity verification for platform users.

The UN/CEFACT working group that maintains the international eCMR data model is updating it now (Project P1142) — the standard that determines what an eCMR is, structurally, in every ratifying country. IdentiGate has contributed a technical proposal to that update, and this post makes the argument behind the contribution public, because it affects procurement decisions freight operators are making today.

The Data Model Records Names, Not Proof

The current international eCMR data model dates from 2018. It replicates the paper form faithfully — and that includes replicating paper's approach to identity. Consider what the model actually stores when someone seals or signs a consignment note (field definitions from the published Open Logistics Foundation eCMR building-block specification):

Class	Field	What it holds	Evidential limit
`SealMetadata`	`sealer : String`	Free-text name of the sealing party	No cryptographic link to the claimed entity
`Signature`	`userName`, `data : String`	Human-readable signer text and payload	The spec itself notes eIDAS adaptation is pending
`SealedDocument`	`precedingSeal : String`	Reference to the prior document version	Version chain exists; identity provenance does not

A string that says "Jan Kowalski, Trans-Pol Sp. z o.o." carries a name. It does not carry proof that Jan Kowalski existed, was employed by that carrier, was authorised to sign, or was the person holding the tablet. This is a gap of era, not of design — in 2018, W3C Verifiable Credentials were not yet a standard and eIDAS 2.0 did not exist. In 2026, both are deployed technology, and a scribble on a tablet is still the weakest signature eIDAS recognises.

The legal stakes are concrete. Under the CMR Convention, liability disputes turn on contemporaneous facts — who took over the goods, in what condition, when, and where. The consignment note does not cause those legal effects, but it is usually the only contemporaneous record of the acts that do. A record whose "who did what" reduces to unverifiable strings forces every dispute back into re-litigating identity — the exact cost the digital format was supposed to remove.

The Fork: Proof at the Gate, or Proof on the Record

Here is the architectural decision almost nobody in freight procurement is being asked to make explicitly.

Modern platforms do use strong trust services — qualified seals, timestamps, verified onboarding. The question is where those bind:

	Applied at the platform / gate	Carried on the eCMR object
Where trust lives	In the platform's infrastructure and logs	In the record's own fields
When the record leaves the platform	Proof stays behind — the exported document is just data	Proof travels — the document remains verifiable
Verifying party needs	An account, an API agreement, or a subpoena for the platform	Public trust lists and standard cryptographic verification
Vendor bankruptcy or migration	Evidential value degrades or vanishes	Nothing changes
Cross-border acceptance	Depends on mutual platform recognition	Depends only on the receiving jurisdiction's trust rules
Lock-in profile	Structural — leaving costs you your evidence	None — records are portable by construction

Both columns can be built with today's certified technology. But only one of them keeps the e in eCMR a property of the record. In the other, it is a feature of someone's platform — and the moment your consignment note crosses a border or outlives a contract, you discover which one you bought.

There is a one-sentence diagnostic every freight operator can put to their eCMR vendor:

For each trust service your platform relies on — the seal, the timestamp, the identity attestation — is there a field that carries it on the eCMR record itself, or is it applied at the gate and dropped from the record?

If the answer is "it's in our audit log," you do not own your evidence. You rent it.

What a Truth Anchor Actually Is

"Trust the platform" is a policy. A truth anchor is a structure. A handover event becomes dispute-resistant when four dimensions are cryptographically bound together inside the record:

Anchor	What binds it	Standard machinery
WHO	A credential issued under a trust framework — not a self-asserted name — with revocation checked at signing time	W3C Verifiable Credentials, eIDAS 2.0 certificates
WHAT	The consignment data itself — cargo IDs, seal numbers, condition remarks — hashed and bound into the signature	Advanced electronic signatures (XAdES / JAdES)
WHEN	A timestamp from an independent authority — a clock no party to the dispute controls	Qualified timestamps (eIDAS Art. 41–42)
WHERE	A location reading signed by a device whose private key lives in hardware and cannot be extracted	Hardware-bound device certificates (TPM / secure element)

Strip any one anchor and a familiar dispute pattern re-opens: without WHO, "that's not our signature"; without WHAT, "the remarks were added later"; without WHEN, "the damage happened after delivery"; without WHERE, "the goods never reached the warehouse." Bind all four to the record and the dispute becomes a verification exercise instead of a credibility contest.

Crucially, none of this requires the record to contain certificates. The data-model fields are conduits, not containers — each one carries a reference into the trust layer where the real credential, signature, and timestamp live and can be checked against public trust lists. The record stays lean; the proof stays checkable.

Sovereignty: Sockets, Not Mandates

Every conversation about digital trust in Europe eventually hits the sovereignty question, and it is usually framed backwards — as a choice between "the EU way" and everything else.

The object-bound architecture dissolves that framing. If the international standard defines the fields — the sockets — then each jurisdiction plugs in its own trust regime: eIDAS 2.0 and the EUDI Wallet in the EU, UNCITRAL MLETR-aligned frameworks and national PKI elsewhere. The record's structure is identical everywhere; only the trust list consulted at verification time is local. No jurisdiction is asked to adopt another's trust framework, and no platform circle gets to become the de-facto standard by network effect.

That last point matters more than it looks. Channel-bound trust — proof living in accredited platforms and the connections between them — inevitably concentrates: whoever operates the accredited channel is the trust infrastructure, and every operator, member state, and non-EU trading partner has to route through it. That is how digitisation quietly converts a public convention into a private toll road. Object-bound proof is the antidote: verification requires no one's permission, no one's API, and no one's continued solvency.

The same architecture is also the only realistic answer for the parties the EU system structurally cannot cover. The EUDI Wallet serves 27 member states; the other ~150 passport-issuing countries are outside it — and non-EU drivers carry a material share of EU freight. A record with standard identity sockets can hold an EUDI-derived credential for a Dutch dispatcher and a biometric-passport-derived credential for a Kazakh driver in the same document, each verifiable against its own root of trust. The alternative — waiting for one wallet to rule them all — is not an architecture; it is a deferral.

Maritime is already learning this lesson the hard way: electronic bill of lading adoption is stuck at 11% precisely because document transfer was standardised and party identity was not. Road freight has the chance to specify the identity layer in the data model before repeating that plateau.

What Freight Operators Should Do Now

The standards process will run its course. Procurement decisions will not wait, and records created today will be evidence in 2029. Three moves cost little now and buy portability later:

Put the diagnostic question in your RFP. Ask where each trust service binds — record or gate. Vendors building object-bound records will answer in one sentence; vendors renting you your own evidence will answer with a diagram of their platform.
Demand exportable proof. A conformant answer is a signed record you can hand to any third party — insurer, court, counterparty — who can verify it with no relationship to your vendor. Test it: export an eCMR, terminate the sandbox account, verify the export.
Solve identity for all your signers, not just the EU ones. If your driver pool or counterparty network extends beyond the EUDI Wallet's reach — for most international operators, it does — you need identity proofing that works from the documents those people actually hold. A biometric passport under ICAO 9303 is issued by roughly 180 states and is cryptographically verifiable offline; identity derived from it, expressed as a verifiable credential and signing at AdES level, plugs into exactly the sockets described above.

Frequently Asked Questions

Is the eCMR data model changing? The international data model maintained under UN/CEFACT is currently being updated (Project P1142). Proposals under discussion include optional fields for verifiable identity, signature references, and device-signed telemetry. Additions of this kind are designed to be backward-compatible: an eCMR without them remains valid.

Does object-bound proof mean putting certificates inside the eCMR? No. The fields carry references — to a credential on a trust list, to a signature held in the signing layer, to a timestamp token. The record points; the trust layer proves. That keeps records small and verification standard.

Is this an EU-only architecture? No, and that is the point. eIDAS 2.0 and the EUDI Wallet are the EU instance of the trust layer. The same record fields accept credentials from any jurisdiction's trust framework — MLETR-aligned regimes, national PKI, or UN-level frameworks. The structure is global; the trust consulted is local.

Our platform is certified — isn't that enough? Certification tells you the platform behaves correctly while you are its customer. It says nothing about the evidential value of a record after export, after migration, or after the vendor exits the market. Portability of proof is a property of the record's architecture, not of the vendor's audit report.

What happens to eCMRs created before any standard update? Nothing — they remain valid under the current model. But records created without verifiable identity binding will always have string-level evidence for who signed. For long-tail liability (CMR claims can surface years after carriage), that difference materialises exactly when it is too late to fix.

Does this require QES? No. Advanced electronic signatures (AdES) with a verified identity behind them meet the evidential bar for consignment notes in practice, and the AdES-vs-QES trade-off in logistics rarely favours the qualified level's cost for this document class. What matters is the binding — identity, payload, time — not the label.

The Bottom Line

The last decade of freight digitisation solved document transfer and called it a day. The result is visible in maritime's 11% and in every eCMR pilot whose records lose their evidential value at the platform boundary. The next revision of the consignment-note standard will decide whether the proof is a property of the record or a feature of a vendor. Operators do not have to wait for that decision to act on its logic: buy records that carry their own truth, verify against public trust lists, and treat any architecture that cannot survive your vendor's disappearance as what it is — someone else's sovereignty over your evidence.

Sources

Regulation and standards

Data model and industry

Related IdentiGate analysis

IdentiGate builds the identity layer this architecture assumes: cryptographic identity proofing from biometric passports issued by roughly 180 states, verifiable credentials bound to verified humans, and Advanced Electronic Signatures under eIDAS that remain verifiable wherever the record travels. Learn more at identigate.com

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back. He contributes to the UN/CEFACT eCMR data-model update (Project P1142) on identity and signing.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.