The EU battery passport: How PLM and MES get you ready for February 2027

Four months. That is all that is left before the EU's first mandatory digital product passport goes live. From 18 February 2027, every EV battery, light means of transport (LMT) battery and industrial battery above 2 kWh placed on the EU market needs a digital battery passport. No passport, no market access.

This is not just an automotive problem. Grid-scale, C&I and most home storage systems count as industrial batteries, and that market is booming. SolarPower Europe's European Battery Market Outlook 2026–2030 reports 36 GWh of new storage installed in Europe in 2025, up 48%, taking total capacity past 100 GWh. Annual installations are expected to exceed 50 GWh in 2026 and reach 138 GWh by 2030.

The question for manufacturers, pack assemblers and storage integrators is no longer whether to prepare, but whether your product and production data can deliver what the passport demands. That is where PLM and MES come in.
‍

What the EU battery passport actually requires

The passport is created by Article 77 of the EU Batteries Regulation (EU) 2023/1542, with its content defined in Annex XIII. It is an electronic record per individual battery, reached through a QR code on the product and linked to a unique identifier.

Three categories are in scope from 18 February 2027:

• Electric vehicle batteries, regardless of capacity.
• Light means of transport (LMT) batteries, such as e-bike batteries.
• Industrial batteries above 2 kWh, including stationary storage for the grid, C&I sites and most homes.

The Battery Pass consortium translated the regulation into a data attribute longlist of roughly 90 mandatory data points, now formalised in DIN DKE SPEC 99100. They span product information, material composition, carbon footprint, recycled content, due diligence, performance and durability, circularity and dynamic state-of-health data. Access is tiered between the public, parties with a legitimate interest such as recyclers, and authorities.
‍

What the Commission clarified in 2026

• The registry is live. The EU Digital Product Passport Registry opened on 20 July 2026. Operators verify themselves with a qualified electronic seal and register each passport's identifier.
• Whoever finishes the battery owns the passport.The Commission's battery passport FAQ (September 2026) places responsibility with the operator that completes the working battery, usually where the BMS is fitted. Suppliers can enter data on its behalf, but legal responsibility stays with the operator.
• Second life means a new passport. A repurposed battery, such as an EV battery turned into stationary storage, needs a new passport linked to the old one.
• The date is not moving. The Environmental Omnibus (Omnibus VIII) amends parts of the regulation, but not the passport deadline. EUROBAT and RECHARGE are lobbying for a phased rollout; that is a position, not law.
  ‍

What is still open

The implementing act on who may access restricted data missed its 18 August 2026 deadline; Taylor Wessing expects adoption in Q4 2026. Carbon footprint and recycled content follow their own timelines, and due diligence reporting starts in August 2027. In short: the deadline is fixed, the rulebook is not, so your data architecture must absorb changes without a rebuild.
‍

A data problem, not a QR-code problem

It is tempting to treat the passport as a labelling exercise: generate a QR code, host a page, done. But the QR code is the easy part. The hard part is the data behind it, which lives in many places:

The pattern is clear: the designed product lives in PLM, the produced product lives in MES. The passport needs both, per battery, consistent and up to date across a life that can span a decade or more.

The companies that will struggle in February are not those without a passport platform. They are those with product data in spreadsheets, as-built records that cannot be traced to a design revision, and no clear view of which cell lot went into which pack.
‍

PLM: The product backbone of the passport

A battery passport is a structured description of a product, and your Product Lifecycle Management (PLM) platform already owns that description. With PLM for manufacturing on Siemens Teamcenter or Teamcenter X, PLM delivers four things the passport needs.

1. One trusted source for the as-designed battery
   Chemistry, capacity, weight, cell format and pack structure are all defined in the engineering BOM. Pulling passport data from PLM instead of spreadsheets gives every field an owner, a release status and a revision: data you can defend to a market surveillance authority.
2. Material compliance built into design
   Capturing supplier material declarations against parts in PLM means hazardous substances and critical raw materials are checked while the design is still changeable, not after the first production run. The same structure supports recycled content reporting later.
3. Carbon footprint as a design parameter
   The carbon footprint is declared per model and plant, and future rules foresee performance classes and maximum thresholds. That makes CO₂e a design constraint, just like cost and weight. Teamcenter Product Cost Management lets engineers compare the cost and carbon footprint of alternatives early, as we explored in AI in product cost management and sustainability.
4. Change management that keeps the passport up to date
   A new cell supplier, a firmware update or a different cathode blend can all change passport data. Formal change management in PLM ensures every relevant change triggers a passport update, with a full history of who changed what and why, including the dismantling and spare part information recyclers need.
   ‍

MES: The production evidence behind every passport

PLM describes the battery you designed. But a passport is issued for each individual battery, and only the shop floor knows what went into it. That is the job of your MES, part of a Manufacturing Operations Management (MOM) landscape built on solutions such as Siemens Opcenter.

1. A unique identity per battery
   Every passport needs an ISO/IEC 15459-compliant identifier linked to the QR code. MES assigns it when the battery is completed and ties it to the work order and the date and place of manufacture.
2. Full genealogy from cell to pack
   Because the passport sits with whoever finishes the battery, pack assemblers and storage integrators inherit the data work for components they did not make. A complete as-built genealogy connects supplier data on incoming cells to the finished product, and answers a recall or an authority's question in hours, not weeks.
3. Test results as performance data
   Capacity, internal resistance, power and round-trip efficiency are measured at end-of-line testing. Captured in MES, they become passport performance data and the baseline for later state-of-health reporting.
4. Plant-level data for the carbon footprint
   The footprint is declared per manufacturing plant. Energy use, scrap and yield from MES, combined with IoT data from Siemens Insights Hub, turn estimates into measured figures.
   ‍

The realvalue: Closing the loop

Released designs flow from PLM to the shop floor; as-built data, deviations and test results flow back. When a battery deviates from its released design, its passport reflects it. That digital thread from as-designed to as-built is exactly what the regulation asks you to prove.
‍

From compliance to the agentic enterprise

PLM and MES give you the data, but a passport is a living record: created at production, updated on change, extended on repurposing, closed at recycling. Across thousands of batteries, dozens of suppliers and an evolving rulebook, manual processes will not keep up.

This cross-system, rule-heavy, auditable work is what the agentic enterprise is built for: humans and AI agents working side by side on trusted data, inside governed processes. Enter Siemens Intelligence Center X (ICX), announced at Realize LIVE 2026 and built on Mendix. As our colleague Gerrit Kiefer explained in Make processes intelligent, ICX combines four capabilities on one governed foundation. Here is how they map onto the passport.
‍

Knowledge graph: One connected view of every battery

Graph Studio connects the design revision in Teamcenter, the genealogy in Opcenter, supplier declarations in ERP and BMS field data through one ontology, instead of copying them into yet another database. The passport becomes a governed view on that graph, with lineage for every field.
‍

Machine learning: From records to predictions

AI Studio runs models on that contextualised data: predicting state of health from test and field data, flagging production anomalies that may affect durability claims, or identifying the best second-life candidates in a storage fleet.
‍

Agentic applications: Let agents do the legwork

With the Mendix AI platform, teams build agentic applications such as:

• A passport readiness agent that checks each model against Annex XIII and flags missing or inconsistent fields before release.
• A supplier data agent that requests, validates and chases material and carbon footprint declarations.
• A change impact agent that detects when an engineering change affects passport data and proposes updates.
• A regulatory watch agent that maps new implementing and delegated acts to your data model.
  ‍

Orchestration and trust: Humans stay accountable

Legal responsibility stays with the company placing the battery on the market, whoever enters the data. Mendix Workflows orchestrate agents and people in one traceable process: an agent prepares, a human approves, the system publishes. The ICX trust layer adds guardrails, logging and access control, so every update has an owner, a timestamp and a data lineage. That is how AI becomes a compliance asset instead of a risk, and what we call intelligent enterprise orchestration.
‍

A practical roadmap to 18 February 2027

Four months is tight but workable. We recommend this sequence:

1. Confirm scope and role (now). Which products are EV, LMT or industrial batteries above 2 kWh? For modular storage, check whether units share a BMS, since their combined capacity then counts. If you finish the battery, the passport is yours.
2. Assess data gaps (November). Map the roughly 90 attributes against PLM, MES, ERP and supplier data, with a source, owner and quality level per field.
3. Secure supplier data (November–December). Agree written authorisations, data clauses, formats and update triggers with cell, module and material suppliers.
4. Connect the digital thread (December–January). Link released PLM data with serialisation, genealogy and test data in MES. Start your EU registry verification early.
5. Pilot one product family (January). Create, publish and update a passport end to end, including an engineering change and a repurposing scenario.
6. Go live and scale with agents (February onwards). Roll out across product families and automate with governed agents, ready for due diligence reporting from August 2027 and the obligations that follow.

Meanwhile, watch the access rights act: its draft, expected around year-end, decides who can read the restricted parts of your passport.
‍

How CLEVR helps you get passport-ready

The battery passport is the EU's first mandatory digital product passport, not its last: the Ecodesign for Sustainable Products Regulation extends the same logic to many more products. A quick QR-code fix means starting over for every next regulation. Connected PLM and MES data, orchestrated by governed agents, builds a foundation for better traceability, faster recalls, smarter design and new second-life business models.

As the largest dedicated Siemens and Mendix partner in Europe, with more than 30 years of industry experience, CLEVR helps manufacturers and energy and utilities companies connect Teamcenter, Opcenter and existing systems into one digital thread, extended with agents through Intelligence Center X. We start where you are: A scope and data gap assessment, a pilot, and a roadmap to scale.

February 2027 is closer than it looks. Let's make sure your data is ready before your batteries are.

‍Part 4 of 4, Straight from the Mendix Community Round Table Meetup in Amersfoort on June 2nd, 2026. Parts 1 to 3 questioned what is left for the consultants to do, whether we can trust an AI agent to do it, and whether the platform still earns the choice. This article asks the commercial question underneath all three: who actually needs such a platform?

A seller at one of the tables had called the Dutch IT director of a top-tier investment bank to invite him to an event. Friendly guy, so he got a few minutes, and the director used them to explain why the answer was no. "No issue with low code," he said. "We're just not doing that anymore. We do everything with AI now, the full application lifecycle." And how do you govern all that? "We have four thousand engineers, and the resources to have full teams checking it." The seller told us afterwards that he could not counter it and did not pretend otherwise.

That answer stayed with me for the rest of the evening, and it has been hanging over this series ever since. I have written three times about June 2nd: what is left for the consultant to do, whether we can trust an agent to do it, and whether Mendix is still a defensible platform to do it on. Each of them ends up in roughly the same place: the value holds if you build it right. So the commercial question remains. If all of that is true, who actually needs it?

‍

The upper end of the market answered honestly

The bank was being accurate rather than dismissive. A company with four thousand engineers can do everything with AI and put full teams on checking the output, because it can afford to. Those enterprises have their AI in place and their budgets spent, so the question they ask is fair: why would we add a platform for this when we already build one ourselves?

The instinct many of us were trained on, chase the biggest logos and land the enterprise, deserves a second look. The companies with the most resources need a platform that takes the hassle away the least, because they are used to carrying the hassle themselves. At least when they are a software-focussed enterprise already. If they are not, a platform like Mendix still gives an incredible head start without the years it takes to build a platform approach yourself. Because yes, that's what it needs to reach a situation that is only getting close to what platforms like those of Siemens can offer.

‍

A nuance I want to add myself

Read that answer back and it sounds like AI mostly closed the door. I do not think it did. Was that bank ever going to buy a low code platform? In 2019, with the same four thousand engineers, before any of this? Almost certainly not to replace its entire tech stack.

A few things keep a company that size building its own, and most of them have little to do with AI.

• Habit and history. An organization that has built software its own way for twenty years has an estate, standards, a review process and existing resources and components. Nobody rips that out because a vendor turned up with a better story.
• Talent, which is more local than we usually admit. If you can hire four thousand engineers, and hire them where the labor cost works out, building in-house is a defensible choice. For a company in the Netherlands hiring in the Netherlands that calculation can look completely different, and so can the values and beliefs behind it.
• The cost they already paid, which the bank did not mention. Years of procedures, internal standards, a platform team, an internal developer platform that somebody has to keep alive. They did not skip the hassle. They bought it in-house and spread the cost over a decade, which is an expensive position that only a company with the scale, strategy and time could get into.

So the four thousand engineers do not prove the platform case is dead. They show that a company big enough, with the right strategy, can build a similar platform experience for itself. This one did, and it took years and real money. It says little about low code, and a lot about who can afford to do without it.

‍

A moving market

I do not even feel it changed too much, with one important addition that I will come back to later. The opening sits with the company that says something close to "I am a construction firm, I am not an IT company," and wants a single supplier to have covered the security, the governance and the integrations already. They cannot put internal teams on checking high-code AI output, and they do not want to either. They want to buy off the hassle, which, as I argued last time, is the real low code pitch once you stop thinking it is only about first-delivery speed.

A useful dividing line through the middle of that market is roughly the number of apps you run. A one-app company drifts toward the pure-prompting tools as a head start, because for one app, why not just prompt it and see how it holds? But once you have a dozen apps, integrations, and things that have to talk to each other and be governed together, you need something that holds the whole estate together. An orchestration platform that can manage them all starts to make sense there in a way it never did for a single app. That is the enterprise profile where all of this still fits. It is too small to have outgrown the platform for domain-specific reasons, and too big to prompt its one app into existence before caring about the full picture. I call it the orchestrating middle, and it is where most companies will find themselves.

‍

The objections

Some objections come up every time, and I would rather answer them than wish them away.

The first is perception. There is a feeling in some rooms that choosing low code in 2026 is the unadventurous option, the sensible and slightly dull choice while everyone else does something shiny with AI. That perception is only partly real, given the huge AI investments from Siemens as well. The platform might not be on par with the possibilities of the big frontier models the day after they release a new version. That said, even since the Meetup in June (this article was published in September), AI assisted development with Mendix matured enormously. I am quite sure the discussion would be more nuanced if we hosted this session again.

The second is lock-in, and it is a fair concern. "It's half the price, and then I own the IP" is something buyers genuinely say when they weigh a managed platform against high code. High code feels like freedom, a managed platform can feel like a cage, and AI has, if anything, made the high-code side look less locked-in than it used to. Denying the lock does not help. Being clear about what it buys you does, and so does being clear about what migrating away would cost. With a reasonably open platform like Mendix that cost is lower than people expect, and with Maia Transform it is now fairly doable to migrate code bases to and from Mendix. Having that option can be a good peace of mind while you enjoy the benefits of the platform.

The third one is quieter. A customer who already has a mature AI strategy elsewhere does not want to bolt new AI onto yet another platform's resource pool. They want to use what they have already invested in. Pitch only greenfield, "add AI here," and you will keep meeting buyers who came at AI from a different direction and got there first. Respecting that allows for a much deeper conversation about what is needed, especially as Mendix lets you use "their" AI, bring your own, or blend them into a mix you like.

‍

The actual pitch

It is sharper than what came before, even if it sounds like a downgrade at first.

You sell having already done it: the supplier who has solved the governance, the security and the integration, so the construction firm does not have to. For the right customer, "we have done the hard part already" is a stronger line than "we are faster," which stopped being true the moment a prompt could ship faster than any of us. Even though these are mostly prototypes and not enterprise grade apps from the first delivery. When shipping your Mendix app on day one, you get ISO 27001, 27017, 27018, 9001, and SOC 2 Type II reports, plus support for GDPR, HIPAA and PCI-DSS without even knowing what they entail. This is and always will be one of the huge drivers of owning Mendix as your enterprise app platform.

There is also one wedge the four-thousand-engineer crowd cannot take, because it has nothing to do with resources and everything to do with trust. Data. A consultant at another table, talking about a government client, put it plainly: they are "very scared, what's going to happen to the data." So you do not lead with the AI. You build the trust first, keep the data in their hands on infrastructure they control, and let the AI come second. For a whole class of customers, in government, in healthcare, anywhere the data cannot leave the building, that is the entire reason they can say yes at all. Local LLMs rapidly land here, and Mendix and Maia can use them just as well.

For those who reached this part of the series and think: but what about Siemens? Most of the Dutch Mendix Community has experience in other domains than manufacturing, so it does not come as a surprise that this angle did not reach a table. It should not be ignored either. With Mendix in its portfolio, including the broad (AI) capabilities discussed above, I can only be happy for the customers that are already well invested in the Siemens ecosystem.

‍

Closing the series

The bank with four thousand engineers was never going to be the main growth, and chasing it is how you end up feeling replaceable. The growth is with everyone below that line who cannot do it themselves and does not want to: the orchestrating middle, the regulated, the ones who want one trusted supplier to have covered the hard parts and to keep their data where it belongs.

Those were four questions from one evening: what is left for us to do, whether we can trust the agent to do it, whether the platform still earns the choice, and who actually needs it. Now that I have written them down, I notice that none of the answers are really about the technology. They come down to judgment, trust, and knowing who you are for. Which is a reassuring thing for a room full of consultants worried about AI to have talked their way into.

Thank you for reading, if you made it through the full series. These articles reflect the discussions in the room, completed with my own opinion, so I am very much looking forward to your thoughts. Does it resonate with what you are seeing? Are you happy, or worried about the possible new perspectives? Either way, I am eager to host another Round Table later this year, or early next year, to go through some statements in person again.

‍

Originally published here.

Part 3 of 4, from the Mendix Community Netherlands Round Table in Amersfoort, June 2nd, 2026. Parts 1 and 2 asked what is left for the consultant to do and whether we can trust an agent to do it; this one goes after the platform underneath both.

Someone at the table put the case for Mendix in just a few words: you buy off a lot of hassle. A governed cloud, a validated stack, security handled, Siemens standing behind it, all of it kept in order so you do not have to. Not speed. Not even, really, a model you can read. The whole platform.

I have written twice now about June 2nd. The first article envisioned what is left for the consultant to do. The second asked whether we can trust an agent to do it. This third one went after the thing underneath both: the platform we are building all of it on. Is choosing Mendix in 2026 still a defensible decision where concepts like TCO and developer productivity seem to change on a monthly basis?

‍

What the defenders actually defended

The claim on the table was deliberately blunt: the reason to choose Mendix over AI-augmented React in 2026 is not build speed; it is that the thing is still standing, readable, and governed in 2034.

The room that defended it did something I did not expect as the first argument. It defended Mendix without once leaning on speed. "Speed has never been the most important thing," one of them said, "because then everybody would already be using low code." So if not speed, what?

Security and governance, mostly. You are not buying a faster way to type. You are buying a governed cloud that is already set up, a stack that has been validated for years, a thing that is, in one consultant's words, "all in order," with Siemens behind it. "If I were a customer right now," someone said, "I would still go for Mendix with Siemens behind that." The pitch was never the build. It was everything wrapped around the build that you would otherwise have to assemble, secure, and answer for yourself.

That is a real argument, and a better one than "we ship faster". With Mendix we have been used to shipping software faster for a long time. So from first-hand experience, we do know that it's great to be able to spend the well-needed time on getting the requirements and adoption straight instead of battling a coding syntax.

A personal note I must add here is that I strongly believe communication is (and always will be) one of the most costly and time-consuming obstacles to creating new things, whether it's software or something else. For decades, Mendix has enabled very small teams to build enterprise-grade software, whereas high-code approaches require much larger teams to reach the same. AI can help reduce the size of those teams to some extent, but this doesn't mean the responsibility is shared with an organization like Siemens. Rather, it's shared with an LLM developed by someone else, including an expiry date on its possible availability. That's something to be aware of, to say the least.

‍

Readability is part of "in order"

One piece of that package matters more now than it did two years ago, and it is the part people reach for first: you can still read it.

When an agent writes the code, being able to open it up and understand it stops being a nicety. It becomes the difference between owning your app and renting a black box. "I don't like to see an app as a black box," one developer said, "where you prompt, it builds, and you don't know how it works inside." His worry was concrete and client-facing: when the customer asks how you built it, you do not want your only honest answer to be "this was my prompt." When a production issue lands on your desk at the wrong hour, you want a flow you can read, even if an agent wrote it. And the readable model is what lets a developer and someone from the business sit and look at the same thing and actually talk. Even if the AI generates the whole thing, the defenders argued, you can still fall back on something readable and go through it together.

So far this is a strong, grown-up case for Mendix. Governed, secure, readable by a broad audience, and someone else keeps it in order. Which is what makes the next part interesting.

‍

So why did half the room say "neither"?

Because the whole package rests on one assumption, and the skeptics went straight at it. The platform stays worth it only if Mendix itself stays stable and stays ahead. 54% of that vote landed on "neither", the durability claim assumes Mendix keeps its end up, and they were not sure it would.

The other room said it plainly. "In ten years, people will see Mendix as high code," one put it, "or as legacy." Another did not think we would be writing code anywhere in ten years, not in Mendix either. Someone pointed at the pure-prompting tools, where "I don't need to do anything anymore; it's just prompting," and "it changed everything." The governed, validated, readable platform is a great answer, right up until someone else offers the same governance "for free" and lets you prompt your way there. But is that even possible without being able to look inside? And if anyone can do this with years of experience in shared responsibilities on exactly this axis, that would be Mendix, right?

While I was not in that room myself, I still believe that the platform itself proves the highest value here. Many Mendix customers don't like to spend much time or budget on their IT landscape when it's not needed. Even if you can deliver "working" software really fast, if there is no place to put it in such a way that you can sleep at night without the need for a costly department or other mechanism looking after it, what did that first-time delivery speed really bring you? With the large customer base, Mendix simply benefits from economies of scale already. Letting customers enjoy that uniform approach to the cost of a license.

‍

The part that should worry Mendix most

This did not come from a skeptic in the room. It came from someone defending Mendix.

He laid out the whole case, the governed cloud, the validated stack, Siemens, all of it, and then said the quiet thing out loud: "if you look at 2034, why shouldn't an AI-code thing provide the same trust and governance? And that's the main challenge for Mendix."

That is the real competition, and it is not AI-augmented React's build speed. It is whether an AI-native stack can wrap itself in the same trust, governance and readability that Mendix sells today. None of those three is a law of physics. They are a head start. The hassle you buy off with Mendix is hassle that, the day a competitor buys it off too, you can get there too. While typing this based on the outcomes of the round table, I am very much trusting that Mendix will stay on top of it's game. Staying completely up to date with the monthly release notes has never been too easy (in a positive way), but now both the breadth and depth of the releases have increased even more.

‍

So, defensible or not?

Yes, and for the right reasons: the governed platform and the readable model, not the demo-day speed. But that case is not self-renewing. Mendix is not really competing on whether it can build the app. It is competing on whether it stays the most governed, most readable, most in-order way to build, while the AI tools climb steadily toward the same promise. That is a race, not a moat. Referring back to my personal note, building better software with fewer people has been one of the major powers of the Mendix ecosystem. And for exactly this, I have not seen many solid challengers yet when it comes to enterprise-grade software without being tied to a specific domain or software ecosystem.

The defenders in that room were not wrong. They were just honest about the clock. The reason to choose Mendix is still a good one. The question is for how long, and that answer depends less on what AI does next than on what Mendix does next. With the recently announced Intelligence Center X, we can surely say that Siemens is ahead of its game.

Which leaves one more question from June 2nd, and it is the awkward commercial one. If all of this is true, who actually needs it? More on that next time.

‍

Originally published here.