The box and the brain: integrating IEC 62443 and ISO 42001 in intelligent industrial products
Putting a machine learning model inside an industrial control device is by now a normal product decision. Predictive maintenance, vision, real-time optimization: the “brain” moves into the machine. But along with the brain comes a risk that your OT cybersecurity process, on its own, simply cannot see.
If you design industrial products you already know IEC 62443. You have a secure development lifecycle, component requirements, patch management, logging for intrusion detection. The 62443 secures the box and the channels it communicates through. But who guarantees that the brain inside the box decides correctly, traceably, and without silently degrading?
That is the question ISO/IEC 42001 answers. And the answer is not “add a second management system next to the first one”: it is to graft the AIMS into the ISMS/CSMS you already have. The 42001 does not replace 62443 — it sits on top of it. Let’s see where, concretely. Six points.
Risk doesn’t add up, it fuses
The first mistake is treating AI risk and OT risk as two separate lists. They are not.
An adversarial attack on a model — inputs built specifically to fool it — formally belongs to the domain of AI governance. But if that model drives an actuator, the effect doesn’t stay in software: it becomes a wrong movement, a pressure beyond threshold, physical damage. The “AI quality” risk and the “OT security” risk are the same risk seen from two sides.
The practical consequence is precise: the AI impact assessments required by 42001 cannot remain standalone documents. They have to translate into OT security requirements in the language of 62443. If the risk analysis of the two worlds doesn’t fuse into a single assessment, you have two partial maps of one territory — and the blind spots sit exactly on the boundaries.
There is only one lifecycle (62443-4-1)
The 62443-4-1 defines the secure product development lifecycle: requirements, design, implementation, verification, change management. It is the discipline through which a manufacturer demonstrates it builds securely, not by accident.
When there’s an AI model in the product, its training, its testing and its validation are not a parallel track managed by the data science team under its own rules. They go inside the same lifecycle. A model validated on a dataset but outside the product’s verification gates is an untracked component inside a system that is supposed to be tracked in full. The 42001 brings the discipline of the model lifecycle; the 4-1 is where you anchor it.
The intelligent component has two fronts (62443-4-2)
The 62443-4-2 sets security requirements at the component level. For an edge device hosting a model that means, as always, resilience against network attacks and tampering.
But an intelligent component has a second front that a “mute” component doesn’t have: the input. A model decides based on sensor data. If that data is corrupted — through fault, noise or manipulation — the model can decide in a perfectly “secure” way from a network standpoint, and perfectly wrong on the substance. The robustness of the sensor input thus becomes a security requirement in its own right. It is the point where data quality (42001) and component security (62443) stop being two topics and become the same requirement.
Two kinds of logs, two different questions
Both standards require you to log. But they answer different questions, and confusing them is a mistake.
The 62443 logging serves to detect: intrusions, network anomalies, out-of-norm behavior. It answers “did someone or something attack the system?”.
The 42001 logging serves to account: traceability of the model’s decisions, recording of inputs and outputs, explainability. It answers “why did the system decide this way?”.
In an intelligent product you need both, and they must talk to each other. When an anomalous model decision coincides with a network anomaly, it’s the overlap of the two logs that tells you whether you’re facing a fault, a drift or an attack. Designing them separately means giving up exactly the information that matters in the worst cases.
Updating the brain is as critical as patching the box
Here lies the most OT-specific point, and the least told.
Updating an OT system is notoriously delicate: it requires maintenance windows, validation, rigorous patch management procedures, because a wrong update stops a line or puts people at risk. It is the operational heart of 62443.
An AI model introduces a second reason to update, one that didn’t exist before: drift. The model isn’t “breached” — it simply stops being accurate because the world has changed relative to the data it was trained on. When that happens, you need to retrain it or update its weights: a 42001 intervention.
But the release of that update in the field cannot follow the relaxed rules of any ordinary software deploy. It has to go through the same maintenance windows and the same validation as a 62443 security patch. Changing the brain of a system in production is no less critical than closing a vulnerability in the box. Often it’s more so — because drift is invisible: no alert warns you that the model is getting it wrong more and more often.
One system, for one market
Let’s put the pieces together. A manufacturer of intelligent embedded control systems that wants to sell into the European single market faces two converging regulatory fronts: the Cyber Resilience Act on the product security side, the AI Act on the AI side. Neither 62443 nor 42001 is mandatory by law — but they are the practical references with which you demonstrate you’ve done things properly on both fronts.
The right move is not to run two management systems in parallel. It is to integrate the 42001 AIMS (Artificial Intelligence Management System) into the 62443 ISMS/CSMS that — if you build serious industrial products — already exists or is taking shape.
Because the principle, in the end, is the one we started from: 62443 ensures the box and its channels are impermeable and secure. The 42001 ensures the brain inside the box operates fairly, transparently, under control and without degrading invisibly. You need both things. And you need them to be one thing.
If you are putting — or about to put — an AI model inside an OT product, the hard part isn’t choosing the standard. It’s understanding where the two worlds touch in your specific product, and where you have blind spots on the boundaries.
The Regulatory Spark is a 45-minute call to map exactly this: where AI and OT security intersect in your product, and where it makes sense to start. You leave with a written summary and a direction. No fluff.