DEF CON 34 — Part 11 of 13

OT, automotive and the return of physical consequence

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For most of cybersecurity’s history, the consequences of compromise remained inside the information system.

Data was stolen.

Accounts were taken over.

Servers were encrypted.

Applications became unavailable.

Transactions were manipulated.

The consequences could be severe. But the cyber incident and the physical world were still separated by a meaningful boundary.

DEF CON 34 offered another reminder that this boundary is disappearing.

Industrial controllers regulate temperature, pressure, electricity and mechanical processes.

Building-management systems control cooling, power, elevators and physical access.

Vehicles increasingly depend on interconnected software-defined systems.

Energy infrastructure is orchestrated through digital control systems.

Data centers depend on digitally managed power and cooling infrastructure.

And increasingly, AI systems can reason about these environments and interact with the tools used to control them.

Once software controls physical reality, cybersecurity stops being exclusively about information.

It becomes partly about safety engineering.

That distinction should change how CISOs think about cyber-physical risk.

The CIA Triad Changes When Computers Control Machines

The classic information-security model is familiar:

Confidentiality → Integrity → Availability

All three matter.

But their relative importance changes dramatically when the protected system controls a physical process.

Consider an industrial controller regulating pressure inside a chemical process.

An attacker learning the current pressure may constitute a confidentiality failure.

An attacker preventing operators from seeing the pressure may become an availability problem.

But an attacker changing the pressure reading — or changing the physical pressure while making the monitoring system report that everything remains normal — is something fundamentally different.

It is an integrity failure capable of producing a safety consequence.

The hierarchy increasingly becomes:

Integrity → Availability → Safety

And in some environments, safety ultimately dominates all three.

That changes the security question.

Instead of asking:

Can an attacker compromise the PLC?

we need to ask:

What physical state can an attacker cause the process to enter?

That is a very different threat model.

The Most Important OT Demonstration Was Not About a Vulnerability

One of the most revealing DEF CON 34 demonstrations came from the ICS Village.

Researchers presenting Give an AI Industrial Protocol Tools and Watch What It Destroys demonstrated an attack-emulation environment spanning industrial protocols and multiple simulated PLC-controlled processes.

The framework reconstructed complete industrial attack chains rather than merely executing isolated exploits.

Windows compromise could lead to an engineering workstation.

The engineering workstation could reach industrial protocols.

Those protocols could manipulate physical processes.

And an AI agent could orchestrate the actions by reading process state and selecting industrial-protocol operations dynamically. (⁠ICS Village)

The demonstration culminated in something deliberately theatrical but conceptually important:

three simulated centrifuges were destroyed while a compromised HMI continued presenting apparently normal operating conditions. (⁠ICS Village)

The important lesson is not that AI can destroy centrifuges.

That would be an unnecessarily sensational interpretation.

The important lesson is the composition of the attack path:

IT compromise
↓
Engineering workstation
↓
Industrial protocol
↓
PLC
↓
Process manipulation
↓
Operator deception
↓
Physical consequence

Every transition matters.

And this is exactly the thesis running through this DEF CON series:

the attack surface is becoming the system.

A PLC Does Not Understand Intent

Industrial systems contain a particularly uncomfortable security property.

Many industrial protocols were designed for environments in which network access itself implied trust.

If a legitimate controller issued a command, the receiving device was expected to execute it.

The security model was often effectively:

Reachability = Authority

Modern enterprise security has spent decades trying to eliminate that assumption.

Yet substantial portions of operational technology still depend on architectures developed when industrial networks were isolated, specialized and physically difficult to reach.

DEF CON’s ICS Village highlighted this directly: its 2026 program included exploitation of Common Industrial Protocol as well as demonstrations across Modbus/TCP, DNP3, S7comm, IEC-104, OPC UA, EtherNet/IP, BACnet/IP, MQTT, GOOSE and PROFINET DCP. (⁠ICS Village)

This creates a fundamental difference between IT and OT compromise.

In IT, a malicious command may change a database.

In OT, a syntactically legitimate command can change reality.

A PLC does not necessarily know whether:

SET TEMPERATURE = 90

represents normal production,

an engineering mistake,

a compromised workstation,

malicious automation,

or an attacker.

It sees a valid instruction.

This is why cyber-physical security cannot end with authentication.

The question is not merely:

Who issued the command?

It must increasingly become:

Is the resulting physical state permissible?

The Safety Boundary Must Become Independent

DEF CON 34 contained an interesting counterexample.

The NICSSIM project demonstrated a simulated environment for distributed small modular nuclear reactors using multiple AI agents.

Its architecture deliberately separated analysis from execution.

A supervisory agent coordinated other agents.

A vulnerability-analysis agent operated read-only.

A remediation agent was separately controlled.

An independent safety auditor evaluated actions.

And deterministic guardrails constrained physical operations. (⁠ICS Village)

One demonstration involved an attempted command that would push primary coolant outlet temperature beyond a predefined safety threshold.

The system rejected the command. (⁠ICS Village)

That architecture points toward an important principle for cyber-physical systems:

Safety constraints should not depend on the correctness of the system requesting the action.

If an AI agent controls the process, the safety boundary should not live only inside the agent.

If an engineering workstation controls the process, safety should not depend solely on the workstation.

If a cloud platform issues instructions, the cloud identity should not automatically override physical constraints.

Instead:

Controller proposes action
↓
Independent safety logic evaluates consequence
↓
Physical limits are enforced
↓
Process executes

This is runtime policy enforcement applied to physical reality.

And it may become one of the most important architectural patterns of cyber-physical security.

Automotive Security Shows the Same Problem at Human Scale

The Car Hacking Village provided another illustration.

Modern vehicles are distributed computing platforms connected to physical actuators.

The consequences are therefore no longer abstract.

One DEF CON 34 presentation demonstrated attacks against Automotive Ethernet using rogue DHCP behavior through an OBD Ethernet interface.

According to the researchers, sufficiently intense network flooding affected safety-relevant vehicle functions including wipers and headlights and could cause abrupt stopping when the vehicle was shifted into Drive or Reverse. At higher packet rates, the infotainment display could black out until the vehicle was fully powered down. (⁠Car Hacking Village)

The interesting issue is not the specific flooding technique.

It is what the attack reveals about architectural dependency.

A networking behavior can become:

Network disturbance
↓
Gateway disruption
↓
ECU communication failure
↓
Vehicle-function degradation
↓
Physical behavior

The vulnerability does not remain inside the network.

The network has become part of the machine.

That distinction will become increasingly important as vehicles, industrial machinery, medical systems, robotics and building infrastructure become software-defined.

Even Proximity Has Become a Digital Trust Relationship

Another Car Hacking Village presentation examined real-world relay attacks against Passive Keyless Entry and Start systems.

The underlying security assumption is elegantly simple:

If the key is nearby, the person possessing the key is probably nearby.

Therefore:

Proximity → Legitimacy

Relay attacks break that relationship.

An attacker does not necessarily defeat the cryptography.

Instead, the attacker manipulates the relationship between distance and trust by relaying communication between the vehicle and a legitimate key elsewhere. (⁠Car Hacking Village)

This is compositional security in miniature.

The cryptographic component can work.

The key can be genuine.

The vehicle can authenticate the correct credential.

And the system can still reach the wrong security conclusion.

Because the vulnerable component is not necessarily the cryptography.

It is the assumption connecting:

Authentication → Proximity → Authorization

That is precisely the kind of relationship CISOs increasingly need to identify.

Buildings Are Now Cyber-Physical Systems

There is another category CISOs should pay far more attention to:

buildings themselves.

At DEF CON 34, researchers examining data-center infrastructure reported identifying 6,300 high-confidence exposed industrial-control systems associated with 1,063 US data centers.

The exposed infrastructure included systems related to building automation and energy supply. The researchers reported that 964 of the identified systems had vulnerabilities with CVSS scores of 9.0 or above. (⁠ICS Village)

Consider the attack path this creates.

An attacker may not need to compromise the servers inside the data center.

Instead:

Internet
↓
Building automation
↓
Cooling / power infrastructure
↓
Environmental condition
↓
Compute infrastructure
↓
Service outage

The attacker bypasses the logical security architecture by attacking the physical dependencies underneath it.

A perfectly hardened Kubernetes cluster still requires electricity.

A Zero Trust architecture still requires cooling.

An encrypted database still requires functioning hardware.

Cybersecurity therefore has an uncomfortable dependency:

Every digital service ultimately rests on physical systems that software increasingly controls.

Those systems belong inside the threat model.

The Data Center Has a Physical Dependency Graph

This suggests a useful extension of attack-path analysis.

Most organizations model logical dependencies:

Application → Database → Identity Provider → Cloud Platform

But critical services also possess a physical dependency graph:

Application
↓
Compute
↓
Power
↓
Cooling
↓
Building Management System
↓
Industrial Controller
↓
Sensors / Actuators

Attackers do not have to traverse this graph from top to bottom.

They can enter from underneath.

This produces what might be called a reverse infrastructure attack.

Instead of:

Compromise application → disrupt service

the attacker achieves:

Compromise supporting physical system → disrupt application

For critical organizations, that makes facilities technology part of cybersecurity architecture.

Not adjacent to it.

Part of it.

Physical Safeguards Are Cyber Controls

This is where OT security becomes particularly interesting.

Cybersecurity programs traditionally favor digital controls:

firewalls,

identity management,

EDR,

SIEM,

network segmentation,

vulnerability management.

But the DEF CON discussion of attacks against the Polish electricity sector emphasized something cybersecurity programs sometimes undervalue:

physical safeguards can limit cyber consequences.

Analysis presented at the ICS Village noted that attackers still face difficulty overcoming physical protections and operational controls designed to preserve continuous operations. (⁠ICS Village)

This matters enormously.

A pressure-relief valve does not care whether the unsafe pressure was caused by:

equipment failure,

operator error,

malware,

an AI agent,

or a nation-state attacker.

It responds to the physical condition.

That makes certain traditional engineering controls surprisingly powerful cybersecurity controls.

Mechanical interlocks.

Independent sensors.

Fail-safe states.

Pressure-relief systems.

Emergency shutdown systems.

Safety instrumented systems.

Manual overrides.

Physical isolation.

Independent control channels.

Cybersecurity architects should learn to appreciate an unusual property of these mechanisms:

They can remain effective even when the cyber system has become untrustworthy.

This Is Why IT Thinking Alone Fails in OT

Traditional cybersecurity frequently assumes that stronger security controls are desirable.

OT introduces a constraint:

A security control can itself create operational risk.

Aggressive scanning can destabilize fragile devices.

Automatic isolation can interrupt production.

A patch can change deterministic behavior.

Endpoint software may be unsupported by the equipment manufacturer.

Rebooting can be operationally impossible.

Credential rotation can interfere with industrial applications.

Network segmentation can break undocumented dependencies.

DEF CON’s OT segmentation discussions explicitly emphasized limited maintenance windows, fragile legacy systems, vendor-controlled architectures and the operational preference for reliability and uptime during production events. (⁠ICS Village)

This changes the optimization problem.

IT security often asks:

How do we reduce cyber risk?

OT security must ask:

How do we reduce cyber risk without increasing process risk beyond an acceptable level?

That requires engineering.

Not merely security tooling.

The CISO Cannot Own This Alone

Cyber-physical risk therefore creates an organizational problem.

Responsibility is usually distributed.

The CISO owns cybersecurity governance.

Engineering understands the process.

Facilities operates building infrastructure.

Safety defines acceptable physical conditions.

Product Security understands embedded systems.

Operations understands production consequences.

Risk Management evaluates business impact.

Vendors may control maintenance access.

No single function sees the complete attack path.

That is dangerous.

Because the attacker does.

A useful cyber-physical governance model therefore looks less like a hierarchy and more like a shared control system:

CISO
+
Engineering
+
Facilities
+
Safety
+
Product Security
+
Operational Risk

The objective is not to transfer OT security to the CISO.

It is to ensure that nobody can declare a system secure while understanding only one layer of it.

CISOs Need a Physical Consequence Model

The traditional risk register is often poorly suited to this environment.

A vulnerability entry might say:

Asset: PLC-1742
Vulnerability: Unauthenticated Modbus write
CVSS: 9.8

Technically correct.

Operationally incomplete.

The more important questions are:

What does PLC-1742 control?

Which physical variables can it change?

What are their safe operating ranges?

Can the controller override those ranges?

Can the safety system be manipulated through the same trust path?

Can operators independently observe the actual physical state?

What happens if the HMI lies?

What is the maximum credible physical consequence?

This turns vulnerability management into consequence management.

The resulting model becomes:

Cyber Entry Point
↓
Digital Authority
↓
Control System
↓
Physical Process
↓
Safety Barrier
↓
Consequence

That final arrow is the one conventional vulnerability management frequently fails to model.

Protect the Observation Layer

The centrifuge demonstration also highlights another lesson.

Manipulating a process is powerful.

Manipulating the process and the operator’s perception of it is far more powerful.

If attackers can alter the physical process while making monitoring systems display normal conditions, human intervention becomes much less reliable.

Therefore cyber-physical architectures should separate:

Control

from

Observation

wherever feasible.

The system that says:

Increase temperature

should not necessarily be the sole system telling operators:

Temperature is normal.

Independent sensors, independent telemetry paths and physically diverse measurement mechanisms can make deception substantially harder.

The principle is simple:

Never allow the system capable of causing the dangerous state to be the sole authority describing that state.

This is the physical equivalent of independent transaction verification discussed earlier in this series.

Recovery Becomes More Difficult Too

Cyber-physical compromise also changes incident response.

In IT, recovery often follows a familiar pattern:

Isolate → Eradicate → Rebuild → Restore

But after an attack capable of manipulating machinery, another question appears:

Can we trust the physical system?

Did the attacker change PLC logic?

Was firmware modified?

Were calibration values changed?

Were safety thresholds altered?

Were sensors manipulated?

Was an engineering workstation compromised?

Were safety controllers affected?

Did the attack create physical wear or damage that persists after malware removal?

The recovery process therefore becomes:

Cyber recovery
+
Control-system validation
+
Engineering inspection
+
Safety verification
+
Physical integrity confirmation

A green EDR console cannot answer those questions.

From Cyber Incident Response to Cyber-Physical Incident Response

For organizations operating industrial systems, buildings, vehicles or other connected physical infrastructure, incident response should therefore include an explicit cyber-physical branch.

When compromise reaches an operational system, the decision structure should change.

The SOC should not independently decide whether a PLC should be disconnected.

Engineering should not independently decide whether suspicious network activity can be ignored.

Operations should not restart equipment simply because IT reports that malware has been removed.

The incident command structure needs representatives capable of answering three different questions:

Security:
What has the attacker controlled?

Engineering:
What could that control have changed?

Safety:
What must be independently verified before operation resumes?

Only when those answers converge should recovery be considered complete.

A New CISO Question: What Can This System Physically Cause?

There is a simple exercise every organization can perform.

Take every critical cyber-physical environment and ask:

What can this system physically cause?

Not:

What data does it contain?

Not:

What vulnerabilities does it have?

Not even:

Who has administrator access?

Instead:

What can happen in the physical world if this system behaves maliciously?

For an office building:

doors,

elevators,

cooling,

fire systems,

power.

For a data center:

cooling,

power distribution,

generators,

environmental controls.

For manufacturing:

motors,

robotics,

temperature,

pressure,

chemical mixtures.

For transportation:

steering,

braking,

propulsion,

charging,

access.

For energy:

generation,

distribution,

switching,

load.

That inventory may reveal cyber risks that never appeared in the CMDB.

The CISO Control Model for Cyber-Physical Systems

DEF CON 34 suggests at least six principles.

1. Map physical consequences, not only cyber assets

Every critical OT asset should connect to the process it controls and the maximum credible consequence of malicious manipulation.

2. Separate control from observation

Independent telemetry makes process deception harder.

3. Preserve independent safety barriers

Safety controls should survive compromise of normal control infrastructure wherever technically possible.

4. Treat engineering workstations as privileged systems

They may possess authority capable of changing physical reality.

Their security classification should reflect that.

5. Test attack paths safely

Simulation, digital twins and realistic protocol emulation can validate detection without experimenting on production equipment.

DEF CON’s ICSForge work, for example, was designed around safe generation of realistic industrial traffic rather than exploitation of live operational systems. (⁠ICS Village)

6. Make cyber-physical recovery multidisciplinary

Restoring the network is not equivalent to restoring trust in the process.

The Bigger Transition

There is a deeper reason this matters.

For years we described digital transformation as though physical businesses were becoming more digital.

Something slightly different has happened.

The physical world itself is becoming software-addressable.

Vehicles.

Factories.

Buildings.

Energy systems.

Warehouses.

Robotics.

Medical equipment.

Agriculture.

Transportation.

Critical infrastructure.

Increasingly, these are physical systems whose behavior can be changed through digital instructions.

That creates enormous efficiency.

It also creates something attackers have historically struggled to obtain:

remote leverage over physical reality.

And AI may eventually make those environments easier to reason about.

An attacker no longer necessarily needs to manually understand every industrial protocol and every process interaction.

Agentic systems can potentially inspect state, select tools, generate hypotheses and compose actions.

The cyber-physical attack path could therefore become:

Attacker
↓
AI reasoning
↓
Engineering tool
↓
Industrial protocol
↓
Controller
↓
Physical process
↓
Human consequence

The AI is not the central problem.

The composition is.

Cybersecurity Becomes Safety Engineering

This leads to the central conclusion.

The traditional CISO protects information systems.

The emerging CISO increasingly protects systems whose failure can change the physical world.

That does not mean the CISO becomes a safety engineer.

It means cybersecurity can no longer be designed independently from safety engineering.

The security boundary must extend through the complete chain:

Identity
↓
Software
↓
Network
↓
Controller
↓
Actuator
↓
Physical process
↓
Human consequence

At DEF CON 34, industrial systems, automotive networks, exposed building infrastructure and AI-assisted attack emulation all pointed toward the same architectural reality.

The computer is no longer where the attack necessarily ends.

It may only be where the attack begins.

And that creates perhaps the most consequential version of compositional security:

A compromised digital relationship can produce a physical consequence.

For CISOs, the implication is straightforward.

We can no longer define cyber risk exclusively by what an attacker can read, steal, encrypt or execute.

We must add another question:

What can the attacker cause to happen in the real world?

Because once software controls physical reality, cybersecurity becomes safety engineering.

CISO Takeaway

Traditional IT security asks whether the system can be compromised.

Cyber-physical security asks what happens after it is.

That distinction changes architecture, detection, incident response, recovery and governance.

And it leads directly to the next question in this series.

If AI can increasingly reason about these systems, experiment with attack hypotheses and orchestrate tools autonomously, what happens to the defender’s most precious resource?

Time.

Next: Part 12 — Autonomous Offensive Research Changes the Defender’s ClockWhy AI-driven experimentation may compress the time from idea to exploit.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.