CRA Annex I for buyers: what to ask your machine and automation suppliers before 2027

A new filling line is at the specification stage. Delivery is planned for spring 2028, qualification after that. The supplier’s answer to the cybersecurity chapter of the user requirements fits on one line: “The system complies with IEC 62443.” Nothing on updates. Nothing on how long the controller firmware will be maintained, or on what happens when a vulnerability is published in the remote-access gateway three years after the performance qualification.

That line will not survive 2028. Every controller, operator panel, industrial PC, switch and gateway on that line placed on the EU market after 11 December 2027 has to meet the essential requirements of the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847. The reporting clock of Article 14 has been running since 11 September 2026; we covered it in CRA reporting obligations are live. This article deals with the rest: what the product itself must be, what the manufacturer must keep doing after delivery, and how a regulated site turns that into questions it can actually check.

A product regulation that lands in your purchase order

The CRA does not regulate the site that runs the line. It regulates whoever places a “product with digital elements” on the market, meaning hardware or software whose intended or reasonably foreseeable use includes a data connection to a device or network (Article 2(1)). On a process line, that is nearly everything with a processor in it.

The manufacturer is whoever markets the product under its own name (Article 3(13)). For a packaging machine, the machine builder is the manufacturer of the machine as a whole, and the Commission’s guidance uses exactly that case: the maker of an industrial automation system integrates components and makes sure the system as a whole meets the essential requirements. The makers of the controllers and drives inside remain manufacturers of their own products.

A machine also covered by the Machinery Regulation (EU) 2023/1230 has to satisfy both texts. Recital 53 of the CRA notes that meeting the CRA can help with the Machinery Regulation’s requirements on protection against corruption and on the safety and reliability of control systems. Where several Union acts require an EU declaration of conformity, the manufacturer draws up a single one that names them all (Article 28(3)).

Two dates decide whether a project is affected. The main obligations apply from 11 December 2027 (Article 71(2)). A product placed on the market before then only falls under the CRA if it is substantially modified from that date (Article 69(2)); the reporting obligations are the exception and apply to everything already on the market (Article 69(3)). A line ordered now and shipped in 2028 is squarely in scope.

What Annex I asks of the product and of the manufacturer

Annex I has two parts, and they are different in kind. Part I is about the product: it must “ensure an appropriate level of cybersecurity based on the risks”, and point 2 lists thirteen properties, (a) to (m), applied on the basis of the manufacturer’s own cybersecurity risk assessment. Part II is about a process: eight vulnerability-handling obligations that run for the whole support period. Annex II then lists what has to be handed to the user.

Parts of Part I read like a hardening checklist. The product must be placed on the market “without known exploitable vulnerabilities” (point (2)(a)), with a secure-by-default configuration and a way to reset it (b), access control (d), protection of the confidentiality and integrity of data, commands, programs and configuration (e, f), a limited attack surface (j), logging of relevant internal activity (l), and a way to remove all data and settings securely (m). Anyone who has sat through a data integrity inspection will recognise (f) and (l). They are close to what GMP already asks of a computerised system, only now the component itself has to deliver them.

Part II is where the regulation reaches into the years after delivery. The manufacturer must identify the components of the product, “including by drawing up a software bill of materials”, fix vulnerabilities without delay, test the product regularly, publish information on fixed vulnerabilities, run a coordinated vulnerability disclosure policy with a contact address, and distribute updates securely. Security updates have to come “without delay” and free of charge, unless something else has been agreed with a business user for a tailor-made product.

Where the text leaves room, and the contract has to fill it

Read from the buyer’s side, four places in Annex I matter more than the rest. In each, the text either sets a floor that is too low for a production line or leaves the choice to the manufacturer.

The first is the support period. Article 13(8) requires at least five years and asks the manufacturer to set it according to how long the product is expected to be in use. Recital 60 names industrial control systems among the products often used for much longer, and the Commission’s guidance of July 2026 says plainly that five years is not a default. The end date, at least month and year, must be stated at the time of purchase (Article 13(19)). A line qualified in 2028 will still be running in 2043. Ask for the date, component by component, before the order goes out.

The second is the software bill of materials. The manufacturer must draw one up, in a commonly used, machine-readable format, covering at least the top-level dependencies (Part II, point 1). Annex II, point 9, however, only requires telling the user where to find it “if the manufacturer decides to make available” the SBOM. The CRA obliges nobody to give it to you; your purchase order can. Expect to be offered SPDX (ISO/IEC 5962:2021) or CycloneDX (Ecma-424).

Third, secure by default, unless agreed. Point (2)(b) lets a business user and a manufacturer agree another configuration for a tailor-made product, and most special machines are tailor-made. The exception has its uses: a validated line sometimes needs a service left enabled. But it should be a written, risk-assessed agreement, not something an engineer switched on at commissioning because the clock was running.

Last, automatic updates. Point (2)(c) expects security updates to install automatically by default where applicable, with a clear opt-out and the option to postpone. On a validated system they will go through change control instead, so what you need is the opt-out and the notification. Annex II, point 8(e) requires instructions for switching automatic installation off. Part II, point 2 asks for security updates to be shipped separately from functional ones “where technically feasible”, which keeps the impact assessment of a security patch small.

From the requirement to the evidence

Anyone who has worked to IEC 62443-4-1 (secure product development) and IEC 62443-4-2 (technical requirements for components) will find little new here. What changes is that the manufacturer now owes it by law, and that you can ask for the evidence in terms the supplier recognises.

The evidence does not all arrive at once. Some belongs in the specification, some is checked at the factory acceptance test, some at site acceptance and installation qualification. Some is only proved years later, the first time a security advisory actually reaches the site and someone has to decide what to do with it.

EU GMP already gives you the handles. Annex 11, clause 3.1 requires formal agreements with suppliers who provide, integrate or maintain a computerised system, with clear statements of their responsibilities; clause 3.2 makes the supplier’s competence and reliability a selection criterion. Annex 15, clause 3.6 allows tests done at the FAT to be reused in IQ and OQ when transport and installation do not affect them. A port list or a firmware baseline checked at the factory can be reused on that basis, provided the protocol was written with that in mind before the test. More on this in FAT and SAT: what the supplier’s tests can prove for you.

Standards: useful evidence, not yet a presumption

A product built to harmonised standards whose references are published in the Official Journal is presumed to meet the requirements they cover (Article 27(1)). Under standardisation request M/606 the Commission has asked the European standards bodies for 41 standards, horizontal and product-specific. On the industrial side, CENELEC TC 65X is preparing amendments to EN IEC 62443-4-1 and EN IEC 62443-4-2 for the CRA. Until a reference appears in the Official Journal, the word “harmonised” in a quotation carries no legal weight. Check the list before you accept it.

The class of a product matters for the switches and firewalls on your network. Operating systems, switches, routers and network interfaces are important products of class I (Annex III): their manufacturer can only self-assess if it has applied harmonised standards, common specifications or a certification scheme, and otherwise needs a notified body (Article 32(2)). Firewalls and intrusion detection or prevention systems sit in class II and always need a third-party procedure (Article 32(3)).

An IEC 62443-4-1 certificate is still good evidence that a supplier has a development process and follows it. It is not a CRA declaration of conformity, and a product developed under a certified process can still ship with a known vulnerability.

Eight lines for the specification

1. Scope statement: which delivered components are products with digital elements, who manufactures each one, and whether the machine will be placed on the market after 11 December 2027.
2. EU declaration of conformity naming Regulation (EU) 2024/2847 alongside the Machinery Regulation, for the machine and for each component supplied separately.
3. Support end date, month and year, per component, with the security update policy after that date. Ask for a period that matches the planned life of the line, not the five-year floor.
4. SBOM in SPDX or CycloneDX, delivered before the FAT and refreshed with each release, at least down to the top-level dependencies the CRA requires.
5. Vulnerability handling contact: the single point of contact, the disclosure policy, and the channel through which advisories reach your engineers, not just the purchasing department.
6. Hardening at delivery: default accounts, open ports and services, logging, reset and data removal, each declared and then verified at the FAT, with any deviation from the secure default agreed in writing.
7. Updates: security releases separate from functional ones where feasible, automatic installation switched off on validated systems, advisories that say what the update changes.
8. Remote services: a cloud or remote function the machine needs to perform one of its functions is part of the product under the CRA (the Commission’s guidance uses an industrial robot as its example). Name it, and say who operates it.

Where to start

List the projects that will deliver equipment after 11 December 2027. Those are the ones where the order you write this year decides what you receive. Add the eight lines above to the cybersecurity chapter of your user requirements template, and ask your current automation suppliers now for their disclosure policy and support end dates, for the installed base too; the answers will tell you quickly who is ready. Then look honestly at your own change control. A supplier who ships security updates “without delay” is of little use if the site needs three months to assess and install one.

Five common mistakes

The most frequent is treating the CRA as the supplier’s problem. The obligations are theirs, but the evidence you will need for qualification, and for NIS2 supply-chain questions, is yours to ask for.

• Accepting five years of support because the regulation says five. It is a legal minimum, and the recital itself says industrial control systems usually need longer.
• Assuming the SBOM comes with the product. The manufacturer must have one; handing it over is a contract term.
• Reading “IEC 62443 compliant” as CRA conformity. Ask which part, which certificate, which product version, and look for the declaration of conformity.
• Letting automatic updates run on a validated system, or the reverse: never installing anything because nobody specified how updates would be handled.

The CRA makes secure products the manufacturer’s legal duty. A regulated site still has to ask for the proof in the order, and check it before signing the FAT.

References

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal L, 20 November 2024: Articles 2, 3, 13, 27, 28, 32, 69, 71, recitals 53 and 60, Annexes I, II and III, eur-lex.europa.eu
• European Commission, Commission guidance on the application of the Cyber Resilience Act, C(2026) 5252, 27 July 2026, digital-strategy.ec.europa.eu
• European Commission, Cyber Resilience Act, standardisation (request M/606), digital-strategy.ec.europa.eu; CENELEC TC 65X work on EN IEC 62443-4-1 and 4-2, stan4cra.eu
• EudraLex Volume 4, Annex 11 Computerised Systems, clauses 3.1 and 3.2, health.ec.europa.eu; Annex 15 Qualification and Validation, clause 3.6, health.ec.europa.eu
• The starting point: automation.com, The Cyber Resilience Act: Compliance Starts with Product Security, Not Documentation, opinion, 24 September 2026, automation.com