Mythos Changed the Threat Model for Critical Infrastructure

In April 2026, an AI found a 27-year-old vulnerability in OpenBSD. OpenBSD is the operating system that sits inside the firewalls, VPNs, and industrial gateways protecting IoT/OT networks across critical infrastructure. It was chosen for those roles because it is considered one of the most secure pieces of software ever written. Security researchers have been reading its code professionally since the late 1990s. None of them found the flaw.

Anthropic's Mythos Preview did, along with thousands of others in hardened software across the industry.

That disclosure is not a news story. It is a warning.

The implication is simple and uncomfortable. Right now, as you read this, the sensor data flowing into your historian could have been altered in transit and you would have no way to know. The setpoint adjustment you pushed to a controller yesterday could have been intercepted and changed, and you would have no record that proved what was authorised. The AI model your engineering team is rolling out across operations next quarter will be reading all of that data, and acting on it, and it will inherit every assumption of trust that cannot currently be verified. And the AI features your existing vendors are shipping into your environment right now, in your historian, your SCADA, your OT security tools, your engineering workbench, are inheriting those same assumptions, whether you chose to deploy AI or not. The walls around your plant are still standing. The attacker no longer needs to go through them.

Why walls stopped working

Almost every IoT/OT security product on the market today does the same thing. It watches the perimeter. It recognises known attack patterns. It raises an alert when something it has seen before happens again.

That is pattern recognition. It works against attacks that have been seen before. Mythos just demonstrated, at scale, that the attacks you now have to defend against are the ones that have never been seen before. AI-assisted research can find novel flaws in weeks. Your patch cycle is measured in months. The gap between the two is the window of risk, and it is widening. Higher walls will not fix a problem that is no longer about walls.

The architecture that does work

The two previous waves of zero trust followed the same pattern. A layer of the stack that used to be implicitly trusted turned out not to be trustworthy, and the industry built verification into it. Zscaler did this for networks. Okta did this for identity.

The third wave is for the data and commands that keep your operation running. It is called Trustworthy Data Infrastructure for IoT/OT, and its principle is data-centric: verify the data and commands themselves, not the environment around them.

Here is how it works, in the simplest terms.

At the moment a sensor produces a reading, a cryptographic fingerprint is taken of that reading and anchored in a secure register. The reading flows on through your historian, your SCADA, your data lake, your AI model, your regulator's archive. At any point, anyone can take a fresh fingerprint and compare it against the register. If they match, the data is exactly what the sensor produced. If they do not, someone altered it, and the alteration is evident.

Setpoint changes work the same way in the opposite direction. When an operator authorises a setpoint adjustment, a fingerprint of the instruction into the register. When the instruction arrives at the controller, the controller verifies the fingerprint before applying it. Altered instructions do not pass verification. Spoofed instructions do not pass verification as well. They do not apply.

Think of the fingerprint of a person. Taken once, kept in a register, used to verify identity later. The check only works because the register sits somewhere the person being verified cannot reach. That separation is what makes the verification meaningful, and what makes the proof survive for years after the data was created.

None of this requires seeing the attack before. No signature database, no behavioural baseline, no threat intel feed. It is a mathematical check against a record taken at the moment of creation. Either the data matches the fingerprint, or it does not.

Why now

Three things have changed at once.

• AI-assisted vulnerability discovery has collapsed the time between a class of flaw existing and a specific exploit being practical. Mythos is one signal. There will be more.

• AI is moving into your operations, reading your telemetry and issuing instructions. If the inputs are unverified, the outputs are faster, more confident, wrong. The value of industrial AI is bounded by the trustworthiness of the data it sees.

• The regulators have decided. The EU Cyber Resilience Act requires manufacturers of products with digital elements to protect the integrity of the data those products process, using state-of-the-art mechanisms, by the end of 2027. NIS2 obliges operators of essential services to maintain data and system integrity. The EU AI Act requires high-risk AI systems to meet data quality and traceability standards. "We think our controls are probably working" is not an acceptable answer under any of these frameworks.

The AI your vendors are already embedding

While your team works out how to deploy AI safely, your existing vendors have already decided. Every major industrial automation, SCADA, historian, and OT security vendor is racing to embed AI into their products. Predictive maintenance agents. Anomaly detection. Autonomous optimisation. Operator copilots. These features land in your environment through routine upgrades and patch cycles, not through procurement decisions you controlled.

Each of those AI features is built on the same unverified data flows the rest of your stack runs on. The vendor assumes the telemetry is accurate. The vendor's AI makes recommendations or takes actions on that assumption. You inherit the consequences.

This is third-party risk with a new dimension. You are no longer just evaluating a vendor's software for vulnerabilities. You are evaluating their architectural trust model, because an AI operating on unverified inputs is an AI making decisions inside your plant without proof of what it saw. The only way to manage that risk at scale is to stop relying on the vendor's assumptions and start verifying the data itself, regardless of which system is consuming it.

What you do now

Stop thinking about cybersecurity for IoT/OT as a wall to patrol. Start thinking about it as a question your data needs to answer: can this reading, this command, this setpoint prove what it is?

Trustworthy Data Infrastructure for IoT/OT is the architecture that lets you answer yes. Deploy it at the middleware layer, where it works today. Push it upstream over time, into your gateways, your firmware, and eventually the silicon itself. Every step closer to the source narrows the window an attacker can operate in, and compounds the value of what has already been deployed.

Closing the last mile

The architecture reaches its full strength when trust is established as close to the data's origin as possible. Middleware and industrial gateways can fingerprint data and commands at ingestion, and that already delivers most of what operators need today. But there is a last mile the middleware cannot reach: the distance between the sensor producing a reading and the first place that reading can be verified. That gap is where manipulation is most valuable to an attacker and hardest for any external layer to catch.

Closing the last mile is work only the manufacturers can do. Industrial OEMs, chipset vendors, and edge gateway makers sit exactly where the data is born. They are uniquely positioned to embed verification into the silicon and the firmware, where every fingerprint is one the attacker had no opportunity to touch. No one else in the stack is.

This is both the aim and the obligation.

The aim: manufacturers who build data-centric verification into their products will ship hardware that is easier for operators to trust, easier for AI systems to safely consume, and easier to certify in every regulated environment they have to operate in. The category is still being named. The first positions in it are still open. The manufacturers that move now define how the next generation of IoT/OT hardware is built.

The obligation is simpler and harder to sidestep. The data has to be trustworthy when it leaves the device, because everyone downstream is building on the assumption that it is. Operators run plants on it. AI systems make decisions from it. Regulators will increasingly require it. Only the manufacturer can make it true at the source. No middleware, no gateway, no cloud platform, no SIEM can reach into the moment a sensor produces a reading. The manufacturer is there. Nobody else is.

Middleware is where the architecture starts. Firmware and silicon are where it completes. Closing the last mile is not somebody else's problem to solve downstream. It is the manufacturer's contribution to making the whole architecture hold.

The bet worth making

The architecture is forming now. The operators that adopt it early, and the manufacturers that build it in, will carry the momentum of the category. The ones that wait will find their auditors, their regulators, their insurers, and their boards arriving with questions they cannot answer.

Mythos told you what is coming - Trustworthy Data Infrastructure for IoT/OT is what you build next.