i3X 1.0, Cyber Resilience Act, and the assurance gap in open industrial APIs

OT SECURITY BRIEF: We look into the security aspects of the recently introduced i3X 1.0 (Industrial Interoperability eXchange)

In June 2026, CESMII froze version 1.0 of i3X — the Industrial Information Interoperability eXchange — and shipped it with an implementation guide, an OpenAPI definition, a Python client, a conformance test suite and an MCP server. Forty-four technology providers have publicly aligned behind it. The specification is small, MIT-licensed, and by several vendors’ accounts implementable in under a fortnight. On the merits of the interoperability problem it addresses, it is the most credible attempt yet made at the application layer.

This is a bold move. The industry desperately needs harmonization of interfaces and in my opinion long overdue. It is a serious attempt to democratize smart manufacturing. Its promise of being able to build agents against an API that is vendor neutral and with levels of abstraction should allow accelerated development and increasing levels of operational efficiency. It truly represents a milestone for IT/OT convergence.

However, this not the theme of this article. What I intend to point to here is what is shipped by vendors need to take into account the CRA aspects if they intend to ship into the EU. Critically, this is a network-facing HTTP interface, with a write path, into the system that holds the plant’s contextualized information model. On 11 September 2026, the first operative obligation of the Cyber Resilience Act attached to exactly that interface — while the design requirements that will govern it do not bind until December 2027.

The Layer has moved Upward

Every prior interoperability contest in this industry was fought at or near the wire. OPC UA, MQTT with Sparkplug, the long tail of fieldbus and the longer tail of drivers — all concerned with moving values between endpoints, all constrained by an installed base that changes on a cycle that lasts decades. i3X does not compete there. It sits above the information platform — the historian, the MES, the DataOps hub, the contextualization engine — and standardises the interface an application uses to interrogate a namespace that has already been organized.

The primitive set is deliberately narrow: discover namespaces, explore object types and their definitions, retrieve instances, navigate hierarchical and non-hierarchical relationships, query current values, query history, subscribe to changes and events, and update current and historical data where permitted. Anyone who has read OPC UA Part 3 will recognize the pattern — value-quality-timestamp, namespaces, types and instances, a MonitoredItem-shaped subscription model — re-expressed over HTTP and JSON. The barrier to implementation drops from an SDK license and a working understanding of the address space to an afternoon with an OpenAPI file.

That said, the security consequence of the move is not insignificant. An endpoint at the wire exposes tags. An endpoint at the information platform exposes the resolved, aggregated, cross-system semantic model: which asset is which, how assets relate, what the process history is, and what the organisation believes its own plant to be. It is the artifact an adversary would otherwise have to reconstruct. Per endpoint compromised, the blast radius is categorically larger than anything the wire-level debates concerned themselves with — and the population of people who can reach an HTTP endpoint is well beyond the population who can reach a fieldbus.

Its a Conduit, Not a Feature

Vendors are presenting i3X support as a connectivity feature, in the same respect as adding a Databricks connector or a REST data service. Under IEC 62443-3-2 it is not a feature. It is a new conduit, terminating inside a component that already holds conduits into lower-trust zones, and it therefore requires its own zone and conduit treatment, its own threat analysis and its own target security level assignment. Nothing in the current ecosystem messaging says this, and nothing in the conformance suite tests for it.

Three properties make the conduit unusual enough to deserve separate attention.

•     The transport is universally reachable. HTTP and JSON were chosen precisely so that IT developers could consume OT data without OT tooling. That is the benefit and the exposure in the same sentence. Anything with a browser stack, a scripting runtime or a curl binary is a candidate client, and the historical containment afforded by protocol obscurity is gone.

•     The intended clients are non-deterministic. The 1.0 release ships an MCP server specifically so that language models can query a compliant endpoint in natural language. Agentic clients are credentialed, are not reproducible run to run, and exert steady pressure toward broad authorisation scopes, because narrowly scoped credentials are the thing that makes the demonstration fail. The realistic steady state is an agent holding namespace-wide read, and eventually write, because that is what the integration was easiest to build. Annex I, Part I, point (2)(g) of the CRA — process only data adequate, relevant and limited to what is necessary for the intended purpose — is not obviously survivable by a namespace-wide agent credential.

•     The write path is in the base specification. i3X permits updating current and historical data where permitted. The current-value write is the conventional problem and can be reasoned about with the usual controls. The historical write is not conventional. A standardized, remotely reachable interface for mutating a process historian is an integrity and non-repudiation problem.

A standardized, remotely reachable interface for mutating a process historian is a potenital integrity problem .

The Default-On Question

Whether the i3X service is enabled at installation, and whether the write path is enabled within it, are the two configuration decisions that determine the real-world risk profile of this standard. The CRA has a view on both. Annex I, Part I, point (2)(b) requires products to be made available on the market with a secure by default configuration; point (2)(j) requires design, development and production to limit attack surfaces, including external interfaces. A service that is on by default, with writes enabled by default, because the specification made it easy, is not an arguable position against either.

Point (2)(l) is the one nobody is discussing. It requires products to provide security-related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions. Audit logging of the i3X write path is therefore not a hardening recommendation. It is an essential requirement, and it is the requirement most directly aimed at the capability i3X normalises - its strength is also its biggest risk.

The Regulation Arrives at the Same Interface

A vendor shipping an i3X server into the European market is shipping a product with digital elements with a network interface, and Regulation (EU) 2024/2847 attaches to it in full. None of that obligation is diluted, transferred or shared by the fact that the interface was specified by someone else.

Annex I, Part I is structured as one residual principle at point (1) — an appropriate level of cybersecurity based on the risks — followed by thirteen specific properties at points (2)(a) to (2)(m), each conditioned on the cybersecurity risk assessment required by Article 13(2). Beyond (2)(b), (2)(g), (2)(j) and (2)(l) already discussed. Two of these land directly on this interface: point (2)(d), protection from unauthorised access by appropriate control mechanisms including authentication and identity or access management systems, and report on possible unauthorised access; and point (2)(f), protection of the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against manipulation or modification not authorised by the user, and report on corruptions. Both of those requirements contain a reporting limb that most implementations will overlook, because detecting and reporting unauthorized access and data corruption is harder than preventing it.

The SBOM point deserves some attention here. Generating a server from an OpenAPI definition is fast because the code generator brings a dependency tree with it: an HTTP server, a JSON serialiser, a validation layer, an authentication library and their transitive closure. For a controls vendor whose prior bill of materials was a firmware image and a protocol stack, the i3X endpoint may greatly increase the number of third-party components the organisation must monitor, attest to and patch for the product’s entire support life.

The Classification - Default

Annex III lists nineteen categories of important products in Class I and four in Class II. A historian, MES, MOM, DataOps hub or contextualisation engine that exposes an i3X endpoint appears in neither. The nearest adjacencies are Class I item (6), network management systems, and Class I item (1), identity management and privileged access management — and under the core-functionality test set out in recital 45, an industrial information platform is not either of those things. Class II is hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, and tamper-resistant microprocessors and microcontrollers. None of them applies.

The consequence is that an i3X server sits in the CRA’s default category, where conformity is assessed by internal production control under Annex VIII with no notified body involved at any point. The regulatory conformity assessment is self-declared by the manufacturer. The i3X conformance result is self-run by the manufacturer. That CLC/TC 65X has a dedicated work item, prEN 50770-2, for OT network management systems indicates the sector is being drawn toward that category deliberately.

Presumption of Conformity - None Currently

As I have pointed out in a number of articles, absent of harmonized standards at this writing means no presumption of conformity can exist. To drill down, Article 27 provides three routes to a presumption of conformity with the Annex I essential requirements. Article 27(1): conformity with harmonised standards, or parts thereof, whose references have been published in the Official Journal. Article 27(2) and (5): conformity with common specifications established by Commission implementing act, available only where a standardisation request has not been accepted or the standardisation process has stalled. Article 27(8): an EU statement of conformity or certificate issued under a European cybersecurity certification scheme adopted pursuant to Regulation (EU) 2019/881. i3X is on none of those paths and is not on a trajectory toward any of them.

The presumption of conformity is therefore not available to anyone, for anything, today. Every manufacturer in scope is currently obliged to demonstrate Annex I conformity directly, from first principles, in its own technical documentation. That is the vacuum into which the i3X conformance badge arrives — a clean, automated, machine-checkable verdict, produced by a credible working group, in a market where no legitimate conformity signal yet exists and every procurement function is looking for one.

The presumption of conformity is currently not available to anyone, for anything.

The Duty to Confess Arrives First

Article 71 does not switch the CRA on at a single date, the reporting duty, applies from 11 September 2026. Everything else — the Annex I essential requirements, vulnerability handling, conformity assessment and the CE marking — applies from 11 December 2027.

I have written articles on the reporting clock for both operators and manufacturers so I am not going to repeat that in its entirety here — only the potential impacts.

The duty to confess a defect arrived fifteen months before the duty to have prevented it - September 11, 2026. In this case the defect may not be yours to fix

A vulnerability in an implementation belongs to the vendor who wrote it, and the ordinary machinery applies. A vulnerability in the specification — an authentication flow that can be replayed, a subscription mechanism that can be made to amplify, a relationship-traversal call that leaks across an authorization boundary by design — belongs to every implementation of it simultaneously. Dozens of vendors would have the same defect, arrived at by correctly following the same document, and every one of them would independently owe the 24-hour early warning.

i3X has no security response function. There is no PSIRT, no coordinated disclosure policy, no embargo mechanism, no CVE numbering arrangement and no private reporting channel. The published route for specification issues is a public GitHub tracker, with a standing instruction to start in Discussions — which is to say that the only available disclosure path is disclosure, immediately, to everyone, including the people one would prefer not to tell first. The working group has stated that 1.0 is frozen and that only documentation and demonstration bugs will be addressed until a vNext charter is established in late 2026. There is no stated exception for security.

A defect in the specification is a defect in every implementation of it: reportable by every vendor, and fixable by none of them alone.

Each vendor is then left with a choice the specification has no answer to: fix it unilaterally and diverge from the standard, forfeiting the interoperability that was the reason to implement it, or remain conformant and ship a known defect while reporting it every 24 hours to two authorities.

What Reasonable Parties Should Do Now

None of the foregoing is an argument against i3X. It is an argument that the assurance scaffolding around it has not been built, that the regulatory scaffolding it would otherwise lean on has not been built either, and that the parties exposed should build their own in the interim.

If you are shipping an i3X server

•     Get the Article 14 chain working this month, not next year. The reporting duty is live and your endpoint is already in the field. Detection, a decision-maker with authority on a Saturday night, and a filing route to the coordinating CSIRT and ENISA. This is the only CRA obligation you are currently late on.

•     Ship it disabled. Annex I Part I (2)(b) is not satisfied by a documented hardening procedure. The service should be off at installation and the write path should be a separate, separately defaulted, separately privileged grant from read.

•     Gate and log historical writes. Point (2)(l) requires recording access to or modification of data, services or functions. Treat historical mutation as a distinct privilege with mandatory audit logging, and be prepared to demonstrate that logging to a data-integrity auditor.

•     Scope credentials by ObjectType, not by namespace. This is the control that determines whether an over-permissioned agent is an incident or a catastrophe, it is what point (2)(g) is asking for, and it is the same work that makes the endpoint semantically useful.

•     Document the endpoint in the technical file explicitly. An Annex I analysis treating the i3X interface as its own attack surface; the OpenAPI-derived dependency tree in the Part II (1) SBOM; the endpoint as its own conduit in the 62443-4-2 component security context.

•     Say in the datasheet what the badge does and does not mean. One line stating that i3X conformance attests functional interoperability and makes no security or regulatory claim costs nothing and forecloses a category of customer dispute.

•     Assume specification defects are yours. Until CESMII publishes a security response policy, plan on carrying them as your own product defects, with your own disclosure timeline, your own Article 14 filing and your own decision about divergence.

If you are procuring a platform that offers one

•     Do not accept the conformance result as a security artifact. Ask instead for IEC 62443-4-1 development-process evidence and the draft CRA technical documentation covering the i3X interface specifically. No harmonised standard exists to point at, so what you are testing is whether the vendor has done the Annex I reasoning at all.

•     Verify the default state yourself. Install it and look. Do not accept the configuration guide as evidence of the shipped default.

•     Ask the ObjectType question. Does the endpoint expose object types and permit querying by them, or is it a namespace-flattened tag list? The answer determines whether you are buying interoperability or a second REST API.

•     Ask what happens when the flaw is in the specification. The vendor’s answer, or absence of one, tells you how seriously the endpoint has been thought about.

•     Zone it separately. The i3X endpoint is not part of the platform’s existing conduit inventory. Give it its own risk assessment and its own target security level.