CRA for Industrial Protocols - A Critical Comparison

SECURITY BRIEF: CRA secure-by-default essential requirement through the lens of protocols that the device supports.

Protocol security does not behave like a product property. Every industrial protocol that has added cryptographic protection — PROFINET Security Classes 2 and 3, CIP Security on EtherNet/IP, the OPC UA secure channel — protects a session, and a session needs two capable endpoints. The security a plant actually achieves is set by the least-capable peer in each relationship. A device that supports mutual authentication and authenticated encryption, installed under a controller that supports neither, either runs unprotected or does not run at all. 

That leaves the manufacturer of every security-capable device with a decision the regulation does not make, and, in most cases, their protocol consortium has not made either:

What does the device do out of the box when an unsecured peer asks to talk to it?

Refuse and break brownfield interoperability. Accept, and weaken the secure-by-default case. Or accept, record and disclose. The answer has to be in the technical file for any product placed on the market after 11 December 2027, which means it has to be in firmware designs being frozen now. 

Three Consortia, Three Postures

The three dominant protocol organisations have answered the question differently. One legislates the default, one automates the default, and one delegates the default to the manufacturer. The Posture is our internal take as to the nature of the position of the protocol - not a formal designation by the consortiums.

Protocol	Posture	Default mechanism	Residual gap
OPC UA	Legislate	Security profile None disabled by default whenever a stronger profile is available (Part 2)	Trust-list handling; enforcement in shipped products
CIP Security	Automate	Security configuration accepted only over a secure connection, even from Factory Default; no PSK suites by default; Pull Model auto-provisioning	Unsecured data-plane ports stay open unless closed; certificate-failure behaviour vendor-specific
PROFINET	Delegate	Reset-to-factory; default configuration set by the manufacturer	No consortium default for accepting plain ARs

OPC UA: Legislate

OPC UA is the only one of the three whose core specification states a normative default. Part 2, the Security Model, describes the “None” security profile as intended for testing and requires it to be disabled by default whenever a more secure profile is available; security mode None can only be used with that profile. The OPC Foundation applied the same logic when it deprecated the SHA-1-based security policies in version 1.04: a server that still includes them must ship with them disabled, must document that they should not be used, and remains subject to testing. 

CIP Security: Automate

ODVA took a different route. A CIP Security device starts in a defined Factory Default state holding a default device certificate, which the specification recommends vendors install at manufacture.  Rather than forbid unsecured operation outright, ODVA has progressively restricted what the default state can do. Its mandatory change list requires that changes to CIP Security configuration be accepted only over a CIP Security connection even in the Factory Default state, that the cipher suites allowed in that state support confidentiality, and that pre-shared-key suites not be allowed by default.  The Pull Model then lets a compliant device locate a certificate authority and request a certificate automatically. ODVA’s own CRA analysis presents the Pull Model, together with port management through the TCP/IP Interface Object, as a possible path to meeting (2)(b).

The residual gap is the data plane. In Cisco and Rockwell’s validated reference architecture, a CIP Security-capable module continued to serve devices without CIP Security on the standard unsecured ports after security policy had been deployed. That design guide predates the latest mandatory changes, and the ports can be closed — but closing them is a configuration choice, not a default. Behavior when the active device certificate is unavailable is also vendor-specific: a device may revert to Factory Default or fall into a closed state. That is a direct trade between access control under (2)(d) and availability under (2)(h), and ODVA leaves it to the manufacturer.

PROFINET: Delegate

PI’s August 2026 whitepaper on CRA compliance is candid about scope: it maps PROFINET security features against Annex I Part I and states plainly that no protocol specification confers compliance.  On (2)(b), its only protocol-level contribution is reset-to-factory; what the default configuration should be is left to the manufacturer’s assessment of intended purpose and reasonably foreseeable use. Secure application relations require both endpoints to support Security Class 2 or above, and the paper’s Secure Cell scenario presents perimeter protection as the migration path for devices without PROFINET security features.  The V2.5 specification carrying the full security feature set is published by PI, but its new Security Profile document is still an IEC committee draft.

Delegation is legally accurate — the obligation is the manufacturer’s — but it produces a different answer per manufacturer. An integrator building a line from five suppliers’ Class 2 devices can find five different behaviors toward the same legacy controller. 

The Reset Problem

The same clause of (2)(b) that demands a secure default also demands a reset to the original state. The original state is the default. If the default accepts unsecured sessions, reset is a downgrade path, and who may invoke it becomes a security question in its own right. 

ODVA has answered it: the EtherNet/IP Security Object Reset service is accepted over any connection only until the object reaches the Configured state, after which it is accepted only over a CIP Security connection.  PROFINET V2.5 defines reset-to-factory behavior for security configuration, but PI’s whitepaper does not say which roles or connection types may invoke it, and we have not verified the specification’s answer.  A reset that any unauthenticated peer can trigger turns a compliant default into a removable one.

The Decision Set

Whatever the protocol, the manufacturer’s technical file needs a defended answer to six questions. 

•    Default acceptance. Does the device refuse, accept-and-record, or silently accept unsecured sessions out of the box — answered separately for configuration, firmware and write paths and for cyclic data exchange?

•    Exit from default. Is the move to a secured state manual, or automated through provisioning in the manner of ODVA’s Pull Model?

•    Trust establishment. Does the device refuse unknown certificates by default, or auto-accept during commissioning — and if so, does auto-accept switch itself off?

•    Downgrade visibility. Is every unsecured session, and every fallback from secured to unsecured, raised as a security event under (2)(l)?

•    Credential failure. When the device certificate expires or is revoked, does the device fail closed or revert — and has the availability consequence under (2)(h) been assessed?

•    Reset authority. Which roles, over which connection types, can return the device to its default?

The user information required under Annex II should state those answers, including what protection is lost when the device is paired with a lower-capability peer and which compensating controls the manufacturer assumes the operator will provide. 

One escape valve exists and is narrow. (2)(b) permits a different configuration only where it is agreed between manufacturer and business user in relation to a tailor-made product. That helps a machine builder delivering a bespoke line. It does not help the manufacturer of a catalog device, whose default must stand on its own. 

Our Position

The defensible default for a catalog device is to lock the management plane and negotiate the data plane: refuse unsecured configuration, firmware and write access by default; permit secure provisioning without manual intervention; and accept unsecured cyclic exchange only with a recorded security event and explicit disclosure in the user information. ODVA’s mandatory changes come closest to this in specification. OPC UA’s rule on None is the clearest statement of intent. PROFINET leaves each manufacturer to assemble the equivalent from the V2.5 hardening policies on its own.

A consortium can move the default. Only a conformance test makes it stay that way.

None of this carries legal weight on its own. Consortium specifications are not harmonized standards, and conformance to them confers no presumption of conformity under Article 27. No consortium posture is a defense before a market surveillance authority applying (2)(b) to a product. 

For consortia, the useful next step is not another mapping paper but a normative default with a certification test behind it: OPC UA’s rule, ODVA’s lock on the management plane, and a test that checks both before a logo is granted. For buyers, the step is simpler.