Digital Product Passport and Asset Administration Shell: When Your Customers Include Them in the Specifications

A typical scenario: A pharmaceutical company issues a request for proposals for a new packaging line. The specifications include output, format changeover time, and qualification documentation, and on page 34, there’s an item the sales department hasn’t seen before: an administrative folder with a type plate, documentation, and a bill of materials, plus a digital product passport for each machine, maintained throughout its entire service life. Sales asks Engineering, Engineering asks IT. And no one can say where the current configuration of a machine is actually documented after the third modification. In conversations with manufacturers, we’re hearing more and more about the digital product passport. Companies in the pharmaceutical, chemical, and automotive industries are already including the product passport and Asset Administration Shell (AAS) in their specifications and requests for proposals. There is currently no legal requirement for this regarding machinery. For manufacturers, however, it is still a requirement that can influence whether a contract is awarded or a product is accepted. Here’s a quick overview of what matters:

• The requirement comes from the customer, not from the law. There is no deadline set for the product passport for machines. Nevertheless, it decides who wins the contract, as specified in the request for proposals.
• What’s in demand is the individual machine. Operators want data related to the serial number: condition, inspections, spare parts, maintenance, repairs, and documents.
• One delivery isn’t enough. The fit and the administrative shell should still be correct even after the first part replacement and the first modification.
• The format is the smaller task. It is more difficult to keep the data for each machine up to date in day-to-day service operations because it is currently scattered across ERP, PLM, service software, and file storage systems.

What Operators in the Pharmaceutical, Chemical, and Automotive Industries Are Looking for Today

The three industries have different reasons, but they all come to the same conclusion. In pharmaceutical manufacturing, every production line must be qualified, and every change to a machine requires traceable documentation. Chemical plant operators run their facilities for decades and want to import manufacturer data directly into their own systems. In the automotive industry, companies exchange data via the Catena-X network in the “Verwaltungsschale” format. One thing they all have in common: The operator wants the machine data in a format that their own systems can read. A PDF folder on a USB flash drive no longer meets this requirement. For manufacturers of production machines, this means meeting the same requirement for dozens or hundreds of shipments each year.

What is typically included in such requirements

The wording in requirements specifications is rarely consistent. In terms of content, they usually boil down to the same data domains for which the Industrial Digital Twin Association (IDTA) provides standardized submodels in the administrative shell: The last column contains the actual findings. No field comes from a single system, and for many manufacturers today, the “Access by Role” row has no source at all.

Digital Product Passports for Machines: What Is and Isn’t Required by Law

The legal basis for the digital product passport is the Ecodesign Regulation (EU) 2024/1781, or ESPR for short, which has been in effect since July 18, 2024. It establishes the framework. The European Commission specifies, in separate delegated acts, which product groups require a passport, what data it must contain, and when it takes effect. The product groups to be addressed first are listed in the European Commission’s 2025–2030 Work Plan dated April 16, 2025: iron and steel, aluminum, textiles, tires, furniture, and mattresses, along with overarching requirements regarding the repairability and recyclability of electrical and electronic equipment. Industrial machinery is not on the list. A mid-term review of the plan is scheduled for 2028. Anyone who claims today that there is a fixed, mandatory deadline for the product passport for machinery cannot substantiate that claim. The question of “per model or per machine” is also left open by law. The ESPR allows for a record to apply at the model, batch, or item level; the decision is made on a product group-by-product group basis. Operators who require a record for each serial number are already going beyond any conceivable minimum requirement. Their focus is on their own documentation, not on compliance. A specific deadline applies only in one neighboring region: The Battery Regulation (EU) 2023/1542 requires a battery passport for every single industrial battery with a capacity exceeding 2 kWh, effective February 18, 2027. This applies to manufacturers whose machines contain such batteries, such as autonomous guided vehicles or industrial trucks. The administrative shell is a standard: internationally standardized as IEC 63278-1 (since December 2023), and defined through the IDTA’s submodels. In 2026, the IDTA published its own submodel for the digital product passport and is participating in the European standardization committee that is developing the technical standards for the product passport system (CEN-CENELEC JTC 24). It has not yet been decided which format the EU product passport will ultimately use from a technical standpoint. The Machinery Regulation (effective January 20, 2027) and the Cyber Resilience Act impose separate obligations with their own deadlines. They pertain to the same data but are not the subject of this article. This text is not a substitute for legal advice regarding the legal assessment of specific cases.

The catch: The data is scattered and becomes outdated

A product passport or administrative template is an output. It shows what is stored in the source systems, and for a typical machine manufacturer, these sources are not built for the individual machine in the field. The ERP system knows the serial number, customer, and delivery date. The PLM system knows the bill of materials, specifically as the machine was designed. The service software tracks service calls, often noting replaced parts in free-text fields. The documents are stored in a file repository, sorted by order or model series. At the time of delivery, this data can be consolidated once—though it requires some effort. After that, the machine changes. A service technician replaces a subassembly with the next-generation model, a retrofit installs a new control system, or the machine changes locations or operators. None of these changes are automatically recorded in the PLM, and the documentation from the delivery date reflects a state that no longer exists. That is why the question of format is of secondary importance. A company that focuses solely on the export function will deliver a clean data package at the time of acceptance and an incorrect one a year later. For a manufacturer with 3,000 machines of a single model series in the field, this cannot be corrected manually.

The file for each machine as a data source

Essentially, what the operator requires is a well-maintained file for each machine that can be exported in an agreed-upon format. For this file to be correct, it needs four things:

• The serial number as a key. All data is tied to the specific machine; the operator and the job are added through it.
• The condition of the building, including inspections. Which components are currently installed and what has changed since delivery.
• Care in Service Processes. When the technician replaces a part, he records it on the machine during the service call.
• Roles and Rights. The operator monitors its machines; maintenance is handled by departments other than purchasing, and internal cost calculations remain internal.

Only the department that actually handles the machine after delivery—the service department—can maintain this file. Engineering and IT provide the initial data; the service process currently maintains it. For many manufacturers, this is a new role, because until now, the installed base has primarily appeared as a total in sales reports and rarely as a list of individual machines with known status. This is where the Digital Machine File (IOTAM) comes in. It consolidates each machine’s serial number, configuration, condition, operator, contracts, deployments, and documents, and is updated through service processes. The machine file is stored in Salesforce and is based on the standard data set for assets. Manufacturers who already manage their machines there retain their data model and supplement any missing information for the record. How this is then used in a second step to create a product passport or administrative template in the customer’s preferred format is a decision made independently regarding the interface and tools used. This requires that the data for each machine be accurate. This same file also supports our own business. Knowing which parts are installed in which machines allows us to offer targeted spare parts, establish maintenance contracts, and plan upgrades. The article on the intelligent installed base describes how this can be leveraged across the entire fleet.

Where to Start

A glance at your own records will reveal whether the product passport and administrative template are a minor issue for you or a criterion for awarding a contract. Three questions can help you assess this:

• How often does this requirement come up? Review the specifications and requests for proposals from the past twelve months, particularly those from the pharmaceutical, chemical, and automotive industries.
• Which model series is affected? Choose one with many machines in the field that serves exactly these customers.
• What is the current status for each serial number? For this series, check the rows in the table above: present, distributed, or missing.

The risk lies in the acceptance process and the next order. Anyone who fails to deliver a promised administrative file or provides data that is outdated after one year will lose the operator’s trust, even without legal sanctions. On the other hand, anyone who maintains the file for each machine as part of their service meets the requirement and, at the same time, has the data foundation for the aftermarket business. At the end of the life cycle, that same file helps with end-of-life management. Two pragmatic approaches:

• Installed Base Assessment – when serial numbers, production statuses, and documents are currently scattered across ERP, PLM, service software, and file storage systems. The assessment identifies, for a specific product series, which data is reliable for each machine and where the mapping breaks down.
• introductory call – when the database is largely in place and you want to clarify how the file for each machine is kept up to date during the service processes.

Start with the product line for which your customers are already making requests today.