OT Cybersecurity Is Simpler Than You Are Being Told. Here Is the Trick.

The following examples are composites built from recurring patterns across industrial assessments. They do not describe a single customer, site or incident.

In one composite scenario, a packaged system retains a commissioning connection long after its original purpose has ended. The path is absent from current drawings, ownership is unclear and no active service agreement governs it.

In another, a legacy DCS retains a default administrative credential. The weakness is easy to identify, but changing it safely requires dependency analysis, engineering testing, an approved operating window and a recovery plan.

A third composite combines an undocumented network connection with a path around the intended industrial firewall. The lesson is not about one cable or one organization; it is that temporary arrangements can become unowned architecture when drawings, approvals and reviews fall behind.

These composite examples deliberately generalize details to protect organizations and individuals while preserving the recurring control lessons.

None of these weaknesses required an advanced threat model to understand.

The connection was uncontrolled. The credential was unchanged. The firewall was bypassed. The risk was visible.

Here is the trick: finding the weakness is often simple. Removing it safely is difficult. Getting someone to own the decision can be even harder.

The principles are not complicated

OT cybersecurity is often presented as if every problem requires another specialized platform, a new technology category, or a highly complex transformation program.

The language changes. The products evolve. Threat actors develop new capabilities. AI is lowering the effort required to research products, write scripts, and adapt existing attack techniques.

But the foundational questions remain familiar:

• Do we know what assets we have?
• Do we understand their operational functions?
• Do we know how they communicate and with whom?
• Can an untrusted system reach a critical asset?
• Who is authorized to access or change the process?
• Can we detect a meaningful operational change?
• Can we respond without creating a safety or production event?
• Can we recover trusted configurations and restore the operation?

These questions are not complicated. Answering them accurately across a live industrial organization is.

Knowing that an organization owns 10,000 assets is not enough. We need to know which assets control production, which provide safety functions, which are operating, which are in standby, which are unsupported, which have remote access, and which depend on systems outside the facility.

Seeing network traffic is not the same as understanding why the traffic exists.

Finding a vulnerability is not the same as determining whether it is exploitable, whether the affected asset is operationally critical, or whether the proposed remediation could introduce greater risk than the vulnerability itself.

The principles are simple. The operating model is hard.

A product capability is not an operational outcome

This is not an argument against cybersecurity products.

Asset visibility, network monitoring, secure remote access, identity controls, vulnerability management, and incident detection technologies can provide significant value. Industrial organizations need capable tools.

The problem begins when a product capability is presented as if it were the final security outcome.

• Asset discovery is not asset ownership
• Visibility is not risk understanding.
• A remote-access platform is not access governance.
• An alert is not an incident response capability.
• A backup is not a proven recovery.
• A vulnerability report is not a remediation.

A product may discover the compressor connection. It cannot determine why it was installed, whether the vendor still requires it, who should own it, or how to remove it without affecting maintenance support.

A monitoring platform may identify an insecure DCS credential. It cannot understand every application dependency, coordinate the engineering change, obtain an operating window, or verify that the process can recover if the change fails.

A network sensor may identify the firewall bypass. It cannot force the organization to close it.

Technology can show us the problem. It cannot replace engineering judgment, operational governance, or management accountability.

The tool may perform exactly as designed, while the cybersecurity program still fails to reduce risk.

OT is not a PLC demonstration

There is another form of oversimplification appearing across social media.

OT is sometimes reduced to a PLC, an HMI, a small network, and a few basic control operations. These demonstrations can be useful for introducing industrial protocols, control logic, and common attack techniques.

But a training environment is the starting point for learning OT. It is not the complete operating reality.

Production is not the colorful process graphic displayed on an HMI.

Production is rotating equipment, electrical systems, instrumentation, process chemistry, changing feed conditions, maintenance activity, temporary configurations, environmental limits, safety layers, production commitments, and people working around the clock to keep the operation stable.

A screen may show that a pump is stopped. An operator may know that the pump is in standby because another unit is unavailable for maintenance.

A cybersecurity engineer may see two apparently redundant network paths. The controls engineer may know that one path has been unreliable for months.

A vulnerability assessment may recommend isolating a server. Operations may know that the server supports the only functioning interface to a critical package unit.

Without that context, a technically correct security recommendation can become an operationally dangerous decision.

Understand the process before trying to secure it

Before conducting cybersecurity work in a process environment where you lack direct experience, spend time with the operations team.

Walk the facility when permitted. Sit with the operators. Speak with controls, instrumentation, electrical, maintenance, process, and safety engineers.

Understand what the facility produces and how the process works. Learn what is operating, what is in standby, what is under maintenance, and what has been temporarily bypassed.

Ask what happens when communications are lost. Ask which operations can continue manually. Ask which systems must fail safely and which failures could stop production.

Understand startup, shutdown, abnormal operations, and recovery. These conditions often reveal dependencies that are invisible during normal production.

A strong OT cybersecurity professional does not need to have worked in every industrial sector. Nobody has experience in every process.

However, humility and operational curiosity are non-negotiable.

Previous industry experience is a significant advantage. If you are securing a utility, experience in utility operations helps you understand protection, redundancy, restoration, and service continuity. If you are assessing a refinery, knowledge of process control, rotating equipment, utilities, safety systems, and operational dependencies improves the quality of every recommendation.

If you do not have that experience, work closely with the people who do.

A good OT cybersecurity professional knows when to lead, when to ask, and when to listen.

You cannot secure an operation you have not taken the time to understand.

OT cannot be secured in isolation

Industrial operations are increasingly connected to enterprise IT, corporate identity services, cloud platforms, remote vendors, managed service providers, and corporate security operations centers.

These connections can improve visibility, support, and response. They can also introduce dependencies and new pathways into the operation.

In my recent article, “The Future of OT Is IT. But OT Must Not Become IT,” I argued that convergence is already happening at the technology layer.

Windows, Linux, virtualization, enterprise identity, remote access, cloud connectivity, data platforms, and AI are already part of industrial environments.

The leadership challenge is to gain the benefits of convergence without allowing enterprise practices to override engineering judgment or operational accountability.

Connecting OT monitoring to the corporate SOC does not automatically create an OT incident response capability.

The SOC may see the alert, but the control room understands the consequence.

An enterprise analyst may identify suspicious communication with a controller. The analyst may not know whether it represents unauthorized activity, approved maintenance, a temporary operating condition, or part of a startup sequence.

More importantly, the SOC should not isolate an OT asset using an enterprise response playbook without understanding what that asset controls.

This is where meaningful convergence becomes essential.

Not convergence that allows IT to take control of OT.

Not convergence that treats a PLC, protection relay, or DCS server as another enterprise endpoint.

OT cybersecurity requires convergence across three areas.

Teams

Cybersecurity, IT, operations, engineering, safety, maintenance, vendors, and service providers must understand their respective responsibilities.

The corporate SOC needs access to OT expertise. Operations needs a reliable way to engage in cybersecurity. Engineering must be involved when a containment or remediation decision could affect the process.

Processes

Incident response, remote access, vulnerability management, change management, escalation, recovery, and risk acceptance must work across organizational boundaries.

A corporate incident response plan that stops at the IT-OT boundary is incomplete. An OT procedure that assumes enterprise systems will always be available is equally incomplete.

Technology

Telemetry, identity, monitoring, case management, and secure access may require integration.

That integration must preserve segmentation, least privilege, and operational authority.

OT data may flow northbound to a corporate SOC or managed service provider. That should not silently create uncontrolled southbound authority over the process.

Technology should support coordinated decisions, not bypass them.

A managed service must understand what it is managing

Managed security services can help industrial organizations overcome skills shortages, extend monitoring coverage, and gain access to specialized capabilities.

But connecting an OT sensor to an external platform is not the same as establishing an effective managed OT security service.

The service agreement must define more than availability and alert acknowledgment.

It should establish:

• Who validates the operational context of an alert?
• Who contacts the facility, and through which channel?
• Who has the authority to investigate further?.
• Which containment actions require engineering approval?
• What the provider may do independently.
• How the provider coordinates with the corporate SOC.
• How critical events are escalated to operations and leadership.
• How does the service continue if enterprise connectivity is unavailable?
• How will performance be measured against operational outcomes?

An alert that sits in a provider’s queue has not protected the operation.

An alert forwarded to a corporate SOC without process context may only transfer confusion from one team to another.

The provider may recognize malicious behavior. The corporate SOC may understand the wider enterprise incident. The plant team understands the operational consequence.

All three perspectives may be required to make the right decision.

This is why the most important managed-service integration is not always technological. It is the integration of SLA, decision rights, escalation paths, operating procedures, and accountability.

If those elements are undefined, the organization has connected its monitoring technology without converging its operating model.

Temporary connections become permanent architecture

Many OT weaknesses begin as reasonable operational decisions.

A vendor needs temporary access during commissioning. A direct cable is installed to troubleshoot an application. A shared credential is retained until system stabilization is complete. A firewall rule is opened for a project. An IIoT gateway is connected to send performance data to a cloud platform.

The original decision may have been justified.

The failure is allowing temporary access to remain without an owner, an expiration date, a monitoring requirement, or a documented review.

Projects finish. Contractors leave. Service agreements change. Drawings are not updated. The system moves into normal operation, but the commissioning pathway remains in place.

Ten years later, someone finds it during an assessment.

Every temporary OT connection should have:

• A documented operational purpose.
• A responsible owner from the asset operator.
• Defined vendor responsibilities.
• An approved communication path.
• Monitoring is appropriate to the potential consequence.
• An expiration or formal review date.
• Evidence that the connection was removed when it was no longer required.

Temporary should never become an undocumented category in the architecture.

Finding risk is easier than owning it

The most concerning part of the composite firewall-bypass scenario was not the cable's existence.

It was the absence of accountable ownership after the weakness became known.

Cybersecurity expected engineers to resolve it. Engineering expected IT to manage the network. Operations was concerned about disruption. The vendor’s responsibility was unclear. Management assumed someone else was handling it.

Everyone was involved, but nobody was accountable.

Eventually, the exception became normal.

This is how known weaknesses become accepted risks without anyone formally accepting them.

A serious OT finding should have one accountable owner, even when multiple teams are required to resolve it.

That owner should be responsible for developing the corrective plan, coordinating engineering validation, obtaining funding, documenting interim controls, and providing evidence of closure.

If remediation must be deferred, the decision should be visible to the executive accountable for the operational consequence.

A finding without ownership is not being managed. It is waiting to become part of an incident.

Remediation is an engineering change

In enterprise IT, changing a password or blocking a connection may be a routine administrative action.

In OT, the same action may affect communications between servers, controllers, operator stations, historians, packaged equipment, safety systems, and vendor applications.

That does not mean the weakness should remain.

It means remediation must be managed as an engineering change.

The process should include:

• Confirm the affected assets and operational dependencies.
• Determine the potential safety, reliability, and production consequences.
• Identify interim controls while the permanent solution is prepared.
• Test the change in a representative environment where possible.
• Prepare rollback and recovery procedures.
• Schedule the work around operating conditions.
• Verify that the weakness was removed.
• Update drawings, inventories, and operating procedures.

This is where cybersecurity, IT, automation, operations, safety, maintenance, and vendors must work as one team.

Cybersecurity defines the exposure and helps establish the required control. Engineering determines how the change can be made safely. Operations validates the effect on the process. Leadership ensures that accountability and resources are present.

Every recommendation must pass the Control Room Test

I use a simple question when evaluating an OT cybersecurity recommendation:

Would I still make this recommendation if I were personally accountable for keeping the process safe, available, and running?

This is the Control Room Test.

It does not mean that operations can use production concerns to avoid every security improvement. It does not mean accepting uncontrolled connections, default credentials, unsupported systems, or firewall bypasses.

It means completing the engineering work required to remediate them responsibly.

Before changing the DCS password, identify the dependencies.

Before blocking the connection, confirm its operational purpose.

Before isolating the server, understand what the operators will lose.

Before applying the patch, test compatibility and prepare a rollback.

Before deploying monitoring, decide who will investigate the alert and what action they are authorized to take.

Before integrating with a managed service provider, define how the provider, corporate SOC, engineering team, and control room will make decisions together.

The Control Room Test connects cybersecurity intent with operational accountability.

Measure closure, not activity

Executives should be careful when interpreting OT cybersecurity metrics.

A growing asset inventory may demonstrate improving visibility. More alerts may indicate increased monitoring coverage. A longer vulnerability list may show that assessments are becoming more comprehensive.

None of those measurements proves that operational risk is decreasing.

Leaders should also ask:

• How many uncontrolled connections were removed?
• How many temporary vendor pathways have owners and expiration dates?
• How many critical credentials were changed and validated safely?
• How many firewall exceptions were reviewed against operational need?
• How many known-good configurations were successfully restored?
• How quickly can the SOC reach the responsible operator or engineer?
• How many incident-response procedures have been tested jointly?
• How long do critical findings remain unresolved?
• Who is accountable when remediation is deferred?

These questions move the discussion from product deployment to operational resilience.

What the OT CISO must lead

The OT CISO should not become another product buyer or another source of technical findings.

The role is to establish an enterprise operating model that connects the boardroom, corporate cybersecurity, IT, engineering, operations, safety, vendors, and managed service providers.

That means creating a common risk language without erasing operational differences.

It means defining decision rights before an incident.

It means ensuring that technology investments support clear processes and measurable outcomes.

It also means challenging both sides.

Cybersecurity cannot apply enterprise controls without understanding physical consequences. Operations cannot use complexity as a permanent reason to leave known exposure unresolved.

The OT CISO must be able to stand in both rooms.

In the boardroom, the discussion is about risk, accountability, investment, and resilience.

In the control room, the discussion is about process dependencies, safe implementation, recovery, and keeping the operation running.

The program succeeds when those discussions lead to the same priorities.

The real trick

In “AI Is Closing the Exploitation Gap. OT Must Close the Basics Gap First.” I argued that new attacker capabilities increase the urgency of foundational OT security.

That remains true.

But “secure the basics” should never be interpreted as “apply simple changes without understanding the operation.”

The basics are straightforward to describe. They are demanding that it be implemented well.

Advanced technology will continue to play an important role. AI-assisted analysis, asset visibility, threat detection, identity management, secure remote access, and automated workflows can help organizations move faster.

But no tool can replace walking the plant, understanding the process, listening to the operator, integrating the right teams, assigning accountability, and completing the difficult work of closing known weaknesses safely.

• A dashboard can show the connection.
• A managed service provider can monitor it.
• The corporate SOC can investigate it.
• Engineering can explain its dependencies.
• Operations can describe their consequences.

Leadership must ensure that someone owns the decision and completes the action.

OT cybersecurity is simpler than marketing noise. The operation is not. That is the trick.