On 20 January 2027, EU Machinery Regulation 2023/1230 becomes fully applicable and replaces Machinery Directive 2006/42/EC. One detail is easy to miss: it is a regulation, not a directive. It applies directly in every member state. There is no national transposition law left to wait for.
For machine builders it contains a permission that surprisingly few people write about.
What Article 10(7) actually says
The common reading is: from 2027 the instructions may be delivered digitally, as a PDF behind a QR code on the machine. That is true, and it is only half the statement.
The regulation says the requirement also applies where the instructions are embedded in the software of the machinery. Verbatim: "this requirement also applies where the instructions for use are embedded in the software of the machinery". The regulation explicitly anticipates the case where the manual is no longer a separate document but part of the operating interface.
The same opening appears twice more: Article 10(8) allows the EU declaration of conformity to be digital, reachable through an internet address or a machine-readable code. Article 11(7) extends the rule to assembly instructions for partly completed machinery.
The four conditions attached to it
The permission comes with obligations. Deliver digitally and you take on these four:
| Condition | What it means |
|---|---|
| The access path must be marked | The machine, its packaging or an accompanying document must state how to reach the digital instructions. In practice: a QR code. |
| Print, download, store offline | The format must allow all three. The regulation explicitly names the breakdown case: "in particular during a breakdown". |
| At least ten years online | From placing on the market, or across the expected lifetime of the machine, whichever is longer. |
| Paper on request | The buyer may request a printed version at purchase, free of charge and within one month. For non-professional users, safety-related information must be on paper anyway. |
The second row is the interesting one, and it is missing from most compliance summaries. "In particular during a breakdown" means the instructions must not become unreachable at exactly the moment the machine has stopped and somebody needs to repair it. Documentation that lives only in an online customer portal does not reliably meet that.
"Ten years online" is an architecture question, not a hosting question
Ten years is a very long time in software. Think about the tools you were using in 2016, and how many of them still exist in the same form today.
Delivering the manual digitally ties your conformity to a software stack for a decade. That is a decision about vendor risk, not about hosting. The real question is not "where does the documentation live" but: what happens to my delivery if the vendor behind it discontinues the product, gets acquired, or disappears?
There is an answer that works regardless of the vendor: the delivered documentation must not be a service, it must be a stack of files. No backend, no database, no login server, no subscription. Then you can put it wherever you want: your own web server, an S3 bucket, the customer's intranet, or a USB stick that ships with the machine. A static web server is about the most stable thing on the web. It will still run in ten years.
For us that has an uncomfortable consequence, and we took it deliberately: your delivery must not depend on realvirtual still being around in ten years. That is why the realvirtual WEB viewer is open source (AGPL) and self-hostable. You hand over files, host them anywhere, and they keep working, with or without us. We make our money on the authoring side, not on the delivery.
Which technology can carry ten years?
Choosing digital delivery means implicitly choosing a technology base. Four criteria decide whether it survives the decade, regardless of which product you end up picking.
Reach beats specialization. A platform with a large ecosystem outlives individual vendors, because developers, documentation and replacements exist. A special-purpose engine maintained by a single vendor stands or falls with that vendor. This is not a quality judgement about niche products. It is a statement about failure probability across ten years.
Open formats for the geometry. A model only one program can read is exactly as durable as that program. Formats like STEP for CAD and glTF/GLB for 3D delivery are documented and supported by many tools. Proprietary binary containers are the most common quiet lock-in.
Delivery should be standard web. Browsers are more backwards-compatible than almost any other platform. HTML and JavaScript from 2016 still run today. A native application built against a particular Windows version is a considerably riskier bet. Your customer would also need permission to install it.
Separate authoring from delivery. This is the important one. The tool you build the twin with may be complex, capable and may change every two years, because it runs in your engineering department, before the machine is placed on the market. What you ship must be the opposite: as simple and as stable as possible. Ship both as one piece and every change to the tool is inherited by a machine that is supposed to sit still for ten years.
In our case that split looks like this: authoring happens in Unity, a platform with a very large ecosystem, with full C# source on our side. Delivery is a browser viewer on web standards, open source under AGPL, handed over as static files. Two layers, two lifespans.
Is closed source safe enough if the vendor disappears?
This question comes up in almost every conversation, and the honest answer is more nuanced than "open good, closed bad".
Closed source is not the actual problem. The dependency is. Does what you shipped keep working if the vendor behind it discontinues the product, gets acquired, or goes insolvent? A closed engineering tool you use before placing the machine on the market is uncritical: if the vendor folds, you switch tools on the next project. Annoying, but manageable. It only gets critical for the part that has to run at your customer's site for ten years.
The classic answer is source code escrow. It is better than nothing, but it has three known weaknesses. First, the trigger is usually narrowly defined, typically insolvency. "Product discontinued" or "vendor acquired and roadmap cancelled" often does not trigger it, yet those are the far more common cases. Second, you receive code, but not necessarily a working build environment, the matching dependencies, and the knowledge of how the two fit together. A package nobody has ever built is an archive, not a contingency plan. Third, source code only helps if you or a service provider can actually take it over.
The more practical test is simpler: can you keep operating the delivered artifact without anyone building anything? With static files on a web server the answer is yes. There is nothing left to fail except the web server itself, and you control that. With a hosted service and a license server the answer is no, whether or not the code sits in escrow.
That leads to a practical rule: in the vendor selection meeting, do not ask "is this open source?" but "what exactly do I hand to my customer, and which parts of it still need you?" The answer to that question determines your conformity risk, not the licensing model on the datasheet.
AI moves faster than your machine ages
Put the two timescales side by side. A machine sits on the shop floor for ten, often twenty years, and the documentation obligation attached to it runs for at least a decade. The AI tools everyone works with today did not exist three years ago. Language models that can read and answer from technical documentation are a recent development, and the pace is not slowing down.
That leads somewhere uncomfortable: you cannot know today what will be connected to your machine documentation in 2032. Choosing a closed platform now, one that does exactly what its vendor anticipated, means making that decision for a decade, on today's knowledge.
It shifts how you should look at a machine information system. It is not primarily an application, it is an integration platform: a clean data layer of geometry with stable component IDs, signals and structured documentation, reachable through open, documented interfaces. Whatever plugs in on top is replaceable: a diagnostic assistant today, something else in five years. The layer underneath stays.
The benefit already shows in the grounding problem: a language model without access to the machine data answers generically and plausibly, but not about your plant. One that can read the component documentation of your specific machine answers concretely and cites its source. Nobody knows which model that will be in five years, which is precisely why the connection should be open and the data layer should be yours.
Which leaves the sober sentence that applies to us as much as to anyone: the web will still be here in ten years. Your software vendor might not be. Build on the layer that survives, and keep everything above it replaceable.
What this has to do with the 3D model
If the manual is allowed to live inside the software anyway, it is worth asking why it should stay a 200-page PDF.
The practical difference shows up during a breakdown. Traditionally, the maintenance technician looks up the part number, scrolls through the PDF and cross-checks exploded views. With the 3D model as the carrier, they open the machine in a browser, click the component, and the documentation is attached to it: datasheet, spare part number, maintenance step. That is what a machine information system means.
None of this is speculative. It is a question of linkage. Every component in the 3D model needs an ID, and every documentation section must point at a component that exists. Anyone who has already built a simulation model of the machine (for sales visualization or virtual commissioning) already has that structure. The documentation layer sits on top; it does not start from zero.
The twin does not end with virtual commissioning
In most projects the digital twin stops precisely where it starts to pay off. The usual pattern: build a model for sales visualization, extend it with drives and sensors for concept simulation, connect a real controller for virtual commissioning. And once the machine ships, the project moves to the archive.
Yet those are only the first two of four levels:
| Level | What is connected |
|---|---|
| 1: Simulation (sales & planning) | Scripted PLC and robot behavior |
| 2: Virtual commissioning | Real PLC, real robot controller |
| 3: Integration test | PLC plus MES |
| 4: 3D HMI / digital shadow | The physical machine in the field |
Virtual commissioning pays off once: shorter commissioning, fewer errors on site. That is a good business case, but it ends at acceptance. Level 4 pays off across the entire lifetime of the machine. From 2027 you have a legal obligation covering part of it anyway.
That is the real point: the model you built for virtual commissioning is already the data basis for the digital instructions. The geometry is right, components have identifiers, signals are defined, kinematics are described. What is missing is the documentation layer on top and a delivery format that runs in a browser without Unity. That is considerably less work than a second project, but only if you plan for it from the start instead of closing the VC project and starting over two years later.
So anyone investing in virtual commissioning today should settle one question up front: will what the customer eventually receives come out of the same toolchain? If simulation and delivery are two separate worlds with two separate models, you pay for the modeling twice.
New in 2027: cybersecurity is part of machine safety
The regulation's second major block gets discussed less often, but it concerns anyone building a modern HMI. Annex III lists protection against corruption, including through attacks (1.1.9), and the reliability of control systems (1.2.1) as essential safety requirements. The 2006 directive did not put it that way.
In practice: any path that can write to the controller from a visualization is a potential attack path and needs the same care as any other safety-related control component. A pure display system (reading signals, showing documentation, surfacing alarms, with no write access) is considerably easier to assess. For most first projects that is the sensible starting position. Write access comes later, deliberately, and assessed separately.
What you can do now
Six months is not much for a decision that has to hold for ten years. What is worth doing now:
- Decide whether you stay on paper or go digital. Both are allowed, but digital is a ten-year commitment, not a format choice.
- If digital: check whether your delivery keeps working without the vendor behind it. If it does not, you are carrying a conformity risk you do not control.
- Test the offline criterion concretely: can the documentation be printed, downloaded, and opened with the machine stopped and no internet connection?
- Check the technology base for longevity: a widely used platform, open formats, delivery on web standards, and an artifact that keeps running without the vendor.
- Settle internally who owns those ten years: engineering, technical documentation, or IT. In many companies that responsibility does not exist yet.
- If a 3D model of the machine already exists: check what is missing to use it as the documentation carrier. Usually it is the component IDs, not the geometry.
Not legal advice. This article summarizes how we read the regulation for our own product architecture. Only the regulation itself is binding: Regulation (EU) 2023/1230 on EUR-Lex.
We wrote the topic up in more depth in the ebook From Visualization to Action, published by Unity: Part 1: Machine Information Systems and Part 2: The Reasoning Layer. If you want to see what a machine with attached documentation looks like in a browser: open the live demo.
Frequently asked questions about digital instructions
Do instructions have to be digital from 2027?
No. The regulation permits the digital form, it does not mandate it. Paper remains valid. What is new is the choice, and the obligations attached to the digital variant.
How long must digital instructions stay available?
At least ten years from placing the machine on the market, or across its expected lifetime, whichever is longer. The manufacturer remains responsible for availability and for keeping it current.
Is a QR code on the machine enough?
The QR code satisfies one of the four conditions: the access path must be marked on the machine, its packaging or an accompanying document. The other three (print and offline capability, ten-year availability, and paper on request) apply regardless.
Do I still have to supply paper?
On request, yes. The buyer may ask for a printed version at purchase, to be supplied free of charge within one month. For non-professional users, safety-related information must be provided on paper anyway.
What does "print and store offline" mean in practice?
The format must be printable, downloadable and storable on a device. The regulation explicitly names the breakdown case: the instructions must remain usable when the machine has stopped and there is no internet connection.
Does this apply to partly completed machinery?
Yes. Article 11(7) extends the rule to assembly instructions for partly completed machinery. Article 10(8) additionally permits a digital EU declaration of conformity.
What happens if my documentation vendor shuts down the service?
The conformity risk stays with you, because the regulation obliges the manufacturer, not its software supplier. That is why delivered documentation should be static files you can host yourself. Then it survives the failure of any single vendor.
Which technology should a digital twin be based on to last ten years?
Four things matter: a widely used platform with a large ecosystem rather than a single vendor's special-purpose engine, open geometry formats such as STEP and glTF/GLB, delivery on web standards, and above all the separation of authoring from delivery. The tool you build with may be complex and may change; the artifact you ship must be simple and stable.
Is source code escrow enough protection?
Only partly. The trigger is usually tied to insolvency, while product discontinuation or acquisition are the more common cases. And you receive code, but not necessarily a working build environment and the knowledge to use it. A more telling question is whether the delivered artifact can keep running without anyone rebuilding anything. With static files, it can.
How do I make sure I can connect new AI technology in five years?
By treating the machine information system as an integration platform rather than a finished application. What matters is an open data layer: geometry with stable component IDs, defined signals and structured documentation, reachable through documented interfaces. Which AI model plugs in later then becomes a replaceable decision instead of a fundamental one.