AI ships HMI features faster, the CRA wants security fixes shipped separately, and operators who get burned often stop updating. Design two tracks.
The Cyber Resilience Act just split your HMI release train in two
For most of my career, a software update on a machine was a box to tick. Somebody from service flashed a new version during commissioning or a maintenance visit, the operator found a moved button the next morning, and everyone got on with production.
That model is ending, and not because designers asked for it. Two pressures are hitting industrial HMI teams at the same time. AI coding tools are pushing more features out of engineering faster. The EU Cyber Resilience Act (CRA) will require, from December 2027, security fixes to move fast and, where technically feasible, on their own. Between those two forces sits the person who has to accept the update: an operator or shift lead with a production target and no patience for surprises.
My view: the update experience is now part of the HMI, and it needs two deliberately different designs. One for security. One for everything else.
What changed on 11 September
The CRA entered into force on 10 December 2024. According to the European Commission, its reporting obligations apply as of 11 September 2026, and its main obligations apply from 11 December 2027. On 11 September, ENISA launched the CRA Single Reporting Platform, the channel manufacturers now use to report actively exploited vulnerabilities and severe incidents.
The reporting clock is short. For an actively exploited vulnerability, Article 14 requires an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure becomes available.
Figure 1. CRA milestones and the Article 14 reporting clock for actively exploited vulnerabilities. Sources: European Commission CRA policy page; ENISA; Regulation (EU) 2024/2847 Article 14 as quoted by the OpenSSF CRA PSIRT checklist.
Reporting is a compliance task. The design consequences sit in Annex I, which becomes binding with the main obligations in December 2027. Three lines matter to anyone who designs how software reaches a machine:
Vulnerabilities must be addressable through security updates, "where applicable" through automatic security updates enabled by default "with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them" (Annex I, Part I, 2(c)).
"Where technically feasible, new security updates shall be provided separately from functionality updates" (Annex I, Part II, 2).
Security updates must be disseminated without delay and, with a narrow exception for tailor-made products agreed with a business user, "free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken" (Annex I, Part II, 8).
Read those as a designer, and you get a brief: a notification, an opt-out, a postpone control, an advisory message, and a separation between two kinds of release. That is interface work. If nobody on the HMI team owns it, a compliance spreadsheet will design it by default.
A caveat before going further. I am a designer, not a lawyer. Whether a given controller, teach pendant app or cell HMI is in scope, and how "where applicable" and "where technically feasible" play out for a specific product, is a question for your legal and product security people.
AI is speeding up the wrong half of the train
The second pressure comes from inside engineering. The 2025 DORA report, based on a survey of nearly 5,000 technology professionals, found that 90% of respondents use AI at work. It also found, unlike the year before, a positive relationship between AI adoption and software delivery throughput. The same report says AI adoption "does continue to have a negative relationship with software delivery stability."
DORA studies software teams in general, not robotics specifically. I wouldn't stretch its numbers to our industry. But the direction is worth taking seriously: more output, less stability. In an office app, an unstable release is an annoyance. On a cell HMI, an unexpected change to a recovery screen or a jog dialogue is a production problem, and it can be a safety conversation.
Now put that next to the CRA. If feature work and security fixes ride the same release, every urgent patch inherits the risk of whatever new features were merged that week. Faster feature output makes the bundle heavier, not lighter. In my view, separation stops being a nice engineering practice and becomes the most reliable way to ship a fix quickly without shipping a surprise with it.
Operators remember the update that broke their shift
Good research shows what happens when updates go wrong for users, and it is not encouraging.
Kami Vaniea, Emilee Rader and Rick Wash studied this at CHI 2014 in a paper titled "Betrayed By Updates". Their finding: users "frequently decide not to install future updates, regardless of whether they are important for security, after negative experiences with past updates."
A SOUPS 2016 study by Arunesh Mathur and colleagues, with 30 participants in its first phase, found that unwanted reboots and context switches lowered productivity, and that people lacked the information to decide whether to update. One participant put it bluntly: "Just being told that it is critical does not really make me feel like it is critical." Their recommendations include minimising interruptions and improving the information shown about an update.
Both studies looked at desktop and personal computing, not factory floors. I think the pattern transfers, and probably gets stronger. An office worker who postpones a patch loses little in the moment. A shift lead who installs an update that changes a recovery flow mid-shift loses output and trust. The next time a notification appears on that panel, the answer will be "later", and later can last a long time.
Figure 2. The update moment is an HMI flow like any other: who sees it, what it says, who decides.
That is the trap. The CRA wants security fixes applied quickly. Operators will only apply them quickly if updates have earned a reputation for being safe and boring. A single badly bundled release can spend that reputation for years.
The industrial reality: test first, then install
Industrial teams already know you don't push a patch to a running line on a whim. NIST SP 800-82 Revision 3, the US guide to operational technology security, recommends "expeditiously deploying security patches after testing all patches under field conditions on a test system, if possible, before installation on the OT system."
Note the tension in that sentence. Expeditiously, and after testing. That is exactly the tension your update UX has to resolve. A security update needs to move faster than a feature release, but it still has to fit a validation step and a planned window on the plant side. My reading is that for most running cells, the "automatic by default" model from consumer software will be the exception. Notification, a clear advisory, a controlled postponement, and a planned installation window will be the norm. That is my design judgement, not a legal interpretation.
ENISA is already working on guidance in this direction. A May 2026 draft technical advisory on secure update mechanisms (Version 0.1, public consultation closed 10 July 2026) recommends supporting "the independent delivery of security updates from functional changes" and giving users "clear controls to opt out or temporarily postpone updates, without preventing the timely application of critical security updates." It is a draft, so treat it as direction rather than settled guidance.
Design two tracks with two different contracts
Here is the model I would put in front of any HMI product team right now. Two release tracks, each with its own promise to the operator.
Figure 3. A two-track release model for industrial HMI software. Framework by the author; requirement wording from Regulation (EU) 2024/2847 Annex I as quoted by the OpenSSF CRA PSIRT checklist.
The security track promises: nothing you see will change. No moved buttons, no new screens, no renamed parameters. If a fix genuinely needs a visible change, it moves to the feature track or gets its own explicit advisory. This track's value is predictability, and predictability is what gets updates installed quickly.
The feature track promises: you will know what changes before it changes. Release notes written for operators, not developers. Screenshots of changed screens. A training note if a workflow moves. A scheduled window agreed with the plant. This is where AI-accelerated feature work belongs, behind the same validation you already apply to anything touching a running cell.
The update interface itself then needs designing like any other critical flow:
Where the notification lives. A security advisory belongs where the person responsible for the machine will see it, which is not necessarily the operator mid-cycle. Role matters. A decision to postpone a safety-relevant system is a shift lead or maintenance decision, not a dismiss button.
What the advisory says. The CRA asks for "relevant information, including on potential action to be taken." Write it in plain language: what is affected, what the risk is, what the operator or maintenance team should do, how long installation takes, whether the cell needs to stop.
What postpone means. Annex I asks for the option to temporarily postpone. Temporarily is the key word. Show the postponement, show who chose it, and bring it back at the next planned window instead of nagging every few minutes.
How the result is confirmed. After installation, the HMI should show the installed version and when it changed, in a place maintenance can find without a service laptop.
A practical checklist for HMI teams
Use this before your next release planning session:
Map your current release. Does your last security fix ship only as part of a feature release? If yes, you have one track, and the CRA expects two where technically feasible.
Write the security track's no-change rule. Agree with engineering that security releases carry no visible UI change by default, and define the exception process.
Design the advisory template. Affected product and version, risk in one sentence, required action, expected downtime, who should decide. Test it with a shift lead, not only with the security team.
Design postpone as a role-based decision. Who can postpone, for how long, and where that decision is recorded and shown.
Give the feature track an operator changelog. Screenshots of changed screens and one line on why each change happened.
Close the feedback loop. Capture what operators report after each feature release and feed it into the next one. If a release caused confusion, that is a defect, and it should be tracked as one.
Watch your AI-generated changes. Anything an AI tool helped write goes to the feature track with the same review and validation as everything else. It never rides along with a security fix.
Conclusion: make updates boring again
The most valuable thing an industrial HMI team can build over the next fourteen months is a reputation for boring security updates. Operators who trust that a security fix will not move their buttons will install it when it arrives. Operators who have been burned will postpone, and the paper trail will say the manufacturer shipped a fix that never reached the machine.
The CRA did not invent good update design. It made it visible, set deadlines, and, where technically feasible, put the separation of security and functionality into law. Meanwhile, AI is making the feature half of the train longer every quarter. Split the train now, give each half its own contract with the operator, and design the update moment as carefully as you design the recovery screen. It is the same operator either way.
Sources
European Commission, Cyber Resilience Act policy page: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
ENISA, "The CRA Single Reporting Platform is launched" (11 September 2026): https://www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched
Regulation (EU) 2024/2847 (Cyber Resilience Act), official text: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
OpenSSF, CRA PSIRT Obligations Checklist (quotes Annex I and Article 14): https://policy.openssf.org/CRA/checklists/PSIRT_Obligations_Checklist.html
ENISA, Technical Advisory on Secure Update Mechanisms, draft Version 0.1 (May 2026; consultation closed 10 July 2026): https://www.enisa.europa.eu/sites/default/files/2026-05/Draft%20-%20ENISA%20Technical%20Advisory%20-%20Update%20Mechanisms%20-%20v0.6.pdf
Google Cloud, "Announcing the 2025 DORA report" (23 September 2025): https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
Vaniea, Rader, Wash, "Betrayed By Updates: How Negative Experiences Affect Future Security", CHI 2014: https://rickwash.com/papers/conference/betrayed-by-updates.html
Mathur, Engel, Sobti, Chang, Chetty, "They Keep Coming Back Like Zombies: Improving Software Updating Interfaces", SOUPS 2016: https://obj.umiacs.umd.edu/hcil_paper/Software_Updating_Study__SOUPS_2016_.pdf
NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
