Does the system that told you about Article 13 also perform Article 13?

"Our PLM vendor says they'll handle it."

That comes up in most first conversations, and it is a reasonable thing to believe. A product passport is product data. Your PLM, PIM or ERP already holds the product data. The step from one to the other looks small.

On 6 and 7 September 2026 we went and checked. About fifty vendors across three software categories, read against their own published pages rather than against anything we happen to think about them. Eight questions per page. Does it name ESPR. Does it name Regulation (EU) 2024/1781. Does it cite an article. Does it name a CEN/CENELEC standard. Does it name GS1 Digital Link. Does it name the EU registry. Does it commit to a granularity level. Does it mention eIDAS or a qualified electronic seal.

Something fell out of that which we were not looking for, and it turned out to be more useful than the thing we were.

Accuracy and capability run in opposite directions

Start with what actually ships.

In PLM, two vendors sell a named passport product. In PIM, two ship a first-party module and four resell somebody else's. In ERP, across the global suites, the mid-market suites and every regional vendor we could find in our nine markets, the count is zero. Not one ERP vendor in the sweep sells a DPP module as a product. Everything else, in all three categories, is blog posts, gated eBooks and webinars.

Now put that list next to the regulatory content, and the two do not overlap.

The four most legally precise pages in the entire sweep belong to vendors with no passport product at all. One cites Article 13 of Regulation (EU) 2024/1781 by number and states the registration duty it creates, in a collapsed FAQ accordion at the foot of the page. Another, published on 2 September, names the EU registry and its 20 July 2026 go-live, names 18 February 2027, and frames the model-versus-batch-versus-item question correctly as still open. Both of them then sell you a PIM.

Meanwhile the vendor with the sharpest product commitment in the class names ESPR twice, names no article, no standard, no registry and no seal.

There is a plain commercial reading of that, and it is worth stating as a reading rather than a finding. A vendor with nothing to sell can afford to be accurate. Accuracy costs it nothing and earns search traffic. A vendor with something to sell inherits every date it prints as a support obligation. One product page in the sweep says so in its own disclaimer: general information, not legal or regulatory advice, requirements and dates subject to change.

So the question to put to your vendor is not whether they know about the passport. Several of them clearly do, in detail. It is whether the system that told you about Article 13 is the system that performs Article 13.

Three vendors answer that question themselves

The strongest evidence here is not ours. It is theirs, in their own words, on their own pages.

A PIM vendor writes this into its own module copy. The module makes passport data available to downstream systems, "including the Economic Operator's DPP Service Provider of choice", and then, in the same breath: "[the product] is not itself a DPP Service Provider; it makes your governed DPP data available so any accredited provider can consume it." It adds that the passport page is hosted externally and that the module stores its address. Read that twice. It uses the regulation's own vocabulary correctly, it names the role it does not play, and it never names the regulation.

A Turkish ERP vendor published in August 2026 what is, by some distance, the most regulation-literate ERP page in the sweep. Its own FAQ asks whether an ERP produces the passport by itself. The answer is that the product-group data model, the evidence documents, and the access and publishing infrastructure "must be built separately."

And in March 2025, an ERP vendor answered a customer asking for exactly this, on the vendor's own community forum: "We have started to look at it but it isn't on the current roadmap. This is due to the fact that we cannot assume serialised structures so we need to think about traceability down to the components without serial or batch tracking."

That last one is the most durable evidence in this piece, and the reason is worth spelling out. Marketing copy changes in an afternoon. A data model does not. The refusal was architectural, the customer asking was a manufacturer, and eighteen months later nothing about it has moved.

Three columns that are empty across the whole class

Reading fifty pages the same way makes holes visible that reading one page does not.

The registry. Operational since 20 July 2026. Named on four pages out of roughly fifty, and every one of those four belongs to a vendor that sells no passport product. Both PLM vendors that ship are silent on it. Every ERP vendor is silent on it.

The seal. Not one page in the sweep mentions eIDAS or a qualified electronic seal. Registry registration is gated on a qualified credential, and that is not the same object as an electronic signature; we wrote that up in detail at the end of August. Fifty vendor pages, seven weeks after the registry opened, and nobody in this class has written a sentence about it.

The standards. Not one page names a CEN/CENELEC EN 182xx standard or CEN/TS 18272-1. The only standards named anywhere in the class come from industrial-automation lineage, plus GS1 Digital Link on three pages.

One more, which surprised me more than those three. Across roughly a hundred pages, no vendor in this class names a passport customer. The closest is a set of case studies where the passport language sits in the customer's mouth rather than the vendor's, phrased as something they are investigating.

Granularity is where the boundary becomes concrete

Whether a passport exists per model, per batch or per item is not a configuration setting. It decides what the system has to store, how many passports a single product line generates, and whether a certificate is valid for a style or only for the run it was tested on.

Exactly one vendor in the sweep commits to a level in product copy, and it is one of the two that ship. It generates passports by supplier, bill of materials, colourway, size or production batch, and it says the operational consequence out loud: certificates validated batch by batch rather than assumed across a whole style. That is a real engineering commitment rather than a marketing line, and it deserves to be answered rather than ignored.

It is also where that vendor's own silence bites hardest. It will generate a passport per colourway and per batch, and its page never says who registers any of them, or what seals them.

Everyone else either frames granularity correctly as an open question and stops there, which is honest, or hedges it toward category level, which is the wrong direction, or says nothing.

In our markets, the class is barely present

Worth knowing where these vendors actually are. Across the nine markets we serve, the corporate footprint of this class is thin and badly distributed. Poland has six of them. Turkey has three. Bulgaria, Serbia, Kosovo, Greece and Slovakia have none at all, and one global ERP group's Sofia entity is registered as shared services, which is a back office rather than sales or delivery.

The two regional products we found that ship anything are in Croatia and Poland. One of them has not had its passport content touched in about twenty months and carries two contradictory compliance dates on its own pages, three paragraphs apart.

Note on method, because it changes what the paragraph above is worth: that is site-restricted search against a US index, not a crawl. It supports "no discoverable passport product or announcement". It does not support "these vendors have never mentioned it."

Necessary, and not sufficient

None of this makes your PLM useless for the passport. The opposite.

Every vendor in the class leads with the same claim, that they already hold the data, and on that claim they are largely right. One ERP vendor puts it at around 70% of what a passport needs already sitting in its system of record. That is the honest and useful half of the pitch, and if you are running a serious PLM or PIM you are further along than a company that is not.

What the class does not do, on its own published evidence, is the second half. Register the identifier in the EU registry. Seal it with a credential the registry accepts. Structure the fields to a harmonised standard. Commit to whether the passport is per model, per batch or per item. Then keep the whole thing readable for as long as the product lives, which is longer than most software contracts run.

PLM and PIM are necessary and not sufficient. That is a category boundary, not a criticism, and one PIM vendor has already drawn it in writing on its own website.

Three questions

If a vendor tells you they will handle the passport, three questions separate a data source from a service provider. None of them is a trick, and all three have real answers.

Which delegated act are you building to? There is no adopted delegated act yet for textiles, furniture, iron and steel or construction materials. A vendor who answers with a firm compliance date should be asked where the date came from.

At what granularity does the passport exist: per model, per batch, or per item? One vendor out of fifty commits to this in product copy. If your product varies by colourway, size or production run, the answer changes what you have to build.

Who registers the identifier in the EU registry, and what seals it? If the answer is "we make the data available to whoever does that", it is a good and honest answer. It is also the boundary, and somebody still has to be on the other side of it.

Ask those three of us too. We will answer them in that order, and we will tell you which parts are not settled yet.