ISO 10218 and R15.06 were rewritten. What changed for your cell.

What actually happened

Two things, about eight months apart.

In January 2025, ISO published revised editions of both parts of the industrial robot safety standard: ISO 10218-1:2025, covering the robot itself, and ISO 10218-2:2025, covering robot applications and robot cells. They replace the 2011 editions that the industry had been working to for fourteen years.12

Then in September 2025, A3 published ANSI/A3 R15.06-2025, the United States national adoption of those two documents. It revises and replaces ANSI/RIA R15.06-2012, which is being withdrawn.45

So if you are in the United States and you are reading a quote or a specification in 2026 that cites R15.06-2012, that document is referencing a standard on its way out. That does not make the cell unsafe. It does tell you when the specification was last genuinely reviewed.

The change that matters most: consolidation

The headline is not a new requirement. It is that several documents people had to hold in their heads at once are now one document.

The revision brings in ISO/TS 15066, the technical specification on collaborative robots, along with the technical reports TR 20218-1 and TR 20218-2 covering manual load and unload and end-effectors.3

This is a bigger deal than it sounds. For a decade, anyone designing a cobot cell was working from a main standard that largely predated the cobot market plus a separate technical specification that was not a harmonised standard. That split produced a lot of confused specifications and a lot of integrators citing TS 15066 as if it settled questions it did not settle. Collaborative operation is now treated inside the main standard as one of the ways an industrial robot application can be safeguarded.

A cobot is not a safe robot. It is a robot that can sometimes be made safe for a specific application, and the application is what gets assessed.

That was always true. The 2025 structure makes it much harder to read the documents and conclude otherwise.

Robots are now classified

Part 1 introduces a classification of robots with corresponding functional safety requirements, so that genuinely low-hazard machines are not held to the same control requirements as a full industrial arm.3 Secondary coverage describes this as two classes: one for robots assessed as not presenting a significant hazard, carrying reduced requirements, and one covering all other industrial robots, which is expected to be the large majority.6

Treat that summary as orientation rather than as the definition. The class boundaries and what follows from them are exactly the kind of detail you should read in the standard rather than in a blog post, this one included.

Part 2 roughly tripled in size

The application and cell standard is the one integrators actually build to, and it grew substantially. Trade coverage of the revision reports terms and definitions expanding from about two pages to fifteen, safety requirements and protective measures from about twenty-eight to fifty, and the list of significant hazards from three pages to eight.6

A tripled definitions section is not padding. It is a standards committee concluding that a lot of arguments over the previous fourteen years came from people using the same words differently.

Cybersecurity is now in scope

The revised series adds cybersecurity content, which the 2011 editions did not address.3

The reasoning is straightforward once stated. A modern cell is on the plant network, is often remotely supported by the integrator, and frequently exchanges data with an MES or ERP. If someone can reach a safety-related parameter over the network without authorisation, that is a safety problem wearing an IT costume. Putting it in the safety standard puts it in the conversation you have with your integrator, rather than the one you have with IT six months after commissioning.

Practically: ask who has remote access to the cell, how that access is authenticated, and what the change control is on safety-related configuration. If those questions produce a shrug, you have learned something useful.

Terminology moved, which matters when reading a spec

Two shifts worth knowing.

• "Robot application" is emphasised over "robot system". The application includes the workpieces, the task program, and the supporting equipment, not just the arm and its controller.6 This is the standard formalising the thing every deployment engineer already knows, which is that the arm is the least interesting part of the safety case.
• "Monitored standstill" replaces "safety-rated monitored stop".4 The protective principle is unchanged. The rename is useful as a dating tool: a specification mixing old and new vocabulary is usually one that was partially updated rather than genuinely re-reviewed.

What to actually do

Five things, in the order I would do them.

1. Check which edition your open quotes cite. Anything specifying R15.06-2012 or ISO 10218:2011 for new work in 2026 should be questioned. Not rejected. Questioned.
2. If you are buying a cobot cell, ask what it is assessed against. If the answer is ISO/TS 15066 as a standalone basis, ask which edition of ISO 10218 the assessment actually uses.
3. Make the risk assessment a named deliverable. With an author, a date, and the edition it was performed against. It is the document that establishes conformity, and it is remarkable how often nobody can produce it a year later.
4. Put remote access and change control in the safety conversation. Not the IT conversation. Ask before commissioning, not after.
5. Do not panic about installed cells. Standards are not law in the United States, and a withdrawn standard does not retroactively condemn equipment built to it. What changes is the baseline for new work, and what a reasonable duty of care looks like if something goes wrong.

If you want the wider context on why a cell's cost and risk sit almost entirely outside the arm, the piece on why pilots stall covers the same ground from the deployment side, and our qualification and safety page covers how we handle it.