Your CISO just handed you responsibility for operational technology security. The industrial control systems are decades old, some devices haven't been patched in years, and the engineers running the plant don't particularly want you touching anything.
For an IT security professional, the instinct is to start fixing things. Identify vulnerabilities, deploy monitoring tools, tighten firewall rules, enforce patching schedules and bring everything into compliance with corporate security policies.
That instinct could get you into trouble.
Operational technology (OT) environments operate under a different set of priorities, where a routine security change can interrupt production, damage equipment or put lives at risk. The technology may look familiar, but the consequences of getting something wrong are profoundly different.
That's the message Aaron C. Crow delivered during his CYBR.SEC.CON. 2026 presentation, OT is Not Hard. It's Different. Drawing on more than 30 years working across IT, manufacturing, utilities and industrial cybersecurity, Crow offered a practical field guide for security professionals who find themselves responsible for environments they don't fully understand.
His central argument: IT security professionals already possess many of the skills needed to protect OT. What they need to change is how they evaluate risk, communicate with engineers and implement security controls.
Watch the full talk:
In OT security, availability and safety come first
Traditional IT cybersecurity revolves around the confidentiality, integrity and availability (CIA) triad. While all three remain important in industrial environments, Crow explained that OT effectively reverses the priorities.
Availability, with physical safety alongside it, generally takes precedence.
A compromised corporate workstation might expose sensitive information or interrupt an employee's work. A poorly executed change to an industrial control system could shut down a manufacturing line, interrupt electricity generation or create dangerous conditions involving high voltage, pressure or industrial machinery.
"If I make it so secure, but the plant doesn't work, what's the point?" Crow asked.
That difference explains why practices considered unacceptable in corporate IT remain common in industrial environments.
Older operating systems, unencrypted industrial protocols and equipment that has remained in service for decades aren't necessarily signs of negligence. In many cases, they reflect engineering decisions designed to preserve reliability, timing requirements and operational continuity.
Crow pointed to industrial protocols that transmit information without encryption. While such designs would raise immediate concerns in an internet-facing application, industrial networks may operate within tightly controlled physical and network boundaries.
That doesn't eliminate the security risk. It changes how the risk must be assessed and mitigated.
The same reasoning applies to patching.
Crow compared updating industrial control systems during production to updating an aircraft's control systems while it's flying at 30,000 feet. Even a necessary security improvement can become dangerous if implemented at the wrong time.
Industrial systems frequently require testing, coordination with engineers and scheduled outages before changes can be deployed safely.
For security teams accustomed to Patch Tuesday, that's a significant adjustment.
The biggest OT security obstacle may be trust
Crow spent considerable time addressing something cybersecurity frameworks don't always capture: the relationship between IT security teams and the engineers responsible for keeping industrial operations running.
Those relationships can be strained.
An IT team might arrive with vulnerability reports, compliance requirements and demands for immediate remediation. Plant engineers, meanwhile, are responsible for equipment that must continue operating regardless of corporate security initiatives.
They may have good reasons to resist changes that appear straightforward from an IT perspective.
Crow illustrated the problem with an incident involving a power plant control room.
A corporate group policy change automatically locked a workstation after five minutes of inactivity. Ordinarily, that would be considered a reasonable security control.
But the workstation displayed operational information used by plant personnel. It had no accessible keyboard, and the operators couldn't unlock it.
The change didn't cause a plant shutdown, but it prevented operators from accessing information they needed to perform their jobs.
The policy wasn't inherently wrong. The problem was that nobody implementing it understood the workstation's operational role.
Crow's advice was straightforward: Listen before prescribing solutions.
Visit the facility. Meet the engineers. Understand what equipment does, why it operates the way it does and what could happen if something changes.
And don't underestimate the value of building relationships. Crow joked that he rarely visits an OT facility without bringing doughnuts, preferably good ones.
The larger lesson is that trust opens doors that compliance mandates often cannot.
Five OT security fundamentals that matter most
Rather than introduce another elaborate security framework, Crow pointed attendees to the SANS five critical controls for industrial control system security.
These fundamentals offer a practical starting point for organizations that may lack even basic visibility into their operational environments.
1. Build incident response plans with plant engineers.
Corporate incident response procedures rarely account for the operational realities of industrial facilities.
Crow recommended conducting tabletop exercises at the plant, with the engineers and operators who understand how systems actually function.
They can explain what happens when equipment fails, how systems can be shut down safely and which recovery procedures are operationally realistic.
An incident response plan developed without those people may look complete on paper but fail when the plant needs it.
2. Establish an accurate OT asset inventory.
Many industrial organizations lack a reliable inventory of their equipment.
Information may be scattered across spreadsheets, engineering diagrams, vendor documentation and the institutional knowledge of employees who have maintained the facility for years.
Crow recommended combining existing documentation with passive network monitoring and physical walkthroughs.
The objective is to identify what's actually connected, what each device does and how it supports operations.
He described finding unexpected equipment during assessments, including network-connected cameras that facility personnel didn't realize were present.
A critical lesson is that inventories must be maintained continuously. A perfectly accurate inventory today can become outdated after the next equipment replacement or configuration change.
3. Establish meaningful network visibility.
Visibility tools can help security teams understand industrial communications and identify suspicious behavior.
But installing a product isn't the same as establishing a security capability.
Crow urged IT teams to work with plant personnel to determine where monitoring equipment belongs, which systems are most critical and who will analyze the resulting data.
Security leaders must also establish responsibility for maintaining the tools and responding to findings.
Plant engineers already have demanding operational responsibilities. Handing them another dashboard without additional support isn't a solution.
4. Secure remote access without disrupting operations.
Remote connectivity is essential for many industrial facilities, particularly those supported by outside vendors and equipment manufacturers.
Crow emphasized the importance of knowing who connects to industrial systems, how long they remain connected and what changes they make.
That requires appropriate access controls, monitoring and coordination with operational personnel.
Existing vendor contracts may complicate the process. Some manufacturers require continuous remote connectivity to monitor or support equipment.
Security teams must understand those dependencies before changing access policies and, when necessary, address security requirements through vendor agreements.
5. Make vulnerability management operationally realistic.
Crow wasn't suggesting that OT organizations ignore vulnerabilities.
He was arguing that vulnerability management must reflect the consequences of changing industrial systems.
A vulnerability affecting a workstation used for routine administrative tasks doesn't necessarily carry the same business risk as an identical vulnerability in equipment supporting a safety-critical process.
Security teams need to evaluate the affected system's function, exposure, available compensating controls and the operational risks associated with remediation.
Where immediate patching isn't feasible, network segmentation and other protective measures may reduce exposure until a safe maintenance window becomes available.
The goal is risk reduction, not simply closing vulnerability tickets.
A practical 90-day OT security plan
Crow's recommendations for the first 90 days were deliberately modest.
Rather than attempt a sweeping security transformation, he encouraged IT teams to establish relationships, identify gaps and deliver an early operational improvement.
The approach can be organized into three phases.
Days 1–30: Listen and learn.
Identify the people responsible for industrial systems and visit the facilities they operate.
Ask what keeps them awake at night, which equipment causes recurring problems and where they lack technical resources.
Review existing documentation, network diagrams, asset inventories and remote access arrangements. Most importantly, understand the operational consequences of potential security changes.
Days 31–60: Map the gaps.
Work with engineers to document weaknesses in asset visibility, network segmentation, incident response, remote access and vulnerability management.
Compare existing inventories against available network evidence and operational knowledge.
Identify areas where corporate IT capabilities could help solve problems the plant has struggled to address.
Days 61–90: Solve one meaningful problem.
Crow encouraged security professionals to find a specific issue they can help plant personnel resolve.
That might mean improving network troubleshooting, automating a manual documentation process, clarifying remote access arrangements or helping maintain an accurate equipment inventory.
The objective isn't to demonstrate how much IT knows. It's to prove that cybersecurity can make the plant more reliable and easier to operate.
These phases are a practical way to implement Crow's 90-day guidance, rather than a rigid timetable he prescribed.
Cybersecurity needs to deliver operational value
One of Crow's most revealing examples came during the audience discussion.
He described working with a power plant that resisted corporate cybersecurity initiatives. The engineers saw little value in the logging and monitoring tools he wanted to deploy.
Then a vendor-related equipment failure occurred.
The plant couldn't establish what had gone wrong. Crow examined the logs, identified the vendor's actions and helped determine the cause.
Suddenly, the monitoring technology had value beyond cybersecurity compliance.
It helped the plant solve an operational problem.
That experience changed the relationship.
For Crow, the lesson was that security teams often gain more support by demonstrating how their tools improve troubleshooting, reliability and operational decision-making than by presenting another list of vulnerabilities.
It's also an argument for stronger collaboration around cybersecurity funding. When security investments help protect production and improve operations, they become easier to justify as business investments rather than isolated IT expenses.
IT and OT security need to become one team
Crow's presentation ultimately challenged the idea that industrial cybersecurity requires IT professionals to abandon everything they know.
Firewalls, network segmentation, identity management, multifactor authentication, logging and incident response remain relevant. The fundamentals of cybersecurity still apply.
What changes is the context.
Industrial environments involve physical processes, specialized equipment, long technology lifecycles and operational teams whose first responsibility is keeping facilities running safely.
Security teams that ignore those realities risk becoming part of the problem they're trying to solve.
Crow's message is particularly relevant as more CISOs inherit responsibility for industrial systems, building automation and other operational technologies that historically sat outside traditional enterprise security programs.
The starting point isn't another tool, another mandate or another frightening presentation about industrial cyberattacks.
It's walking into the plant, listening to the people who keep it running and finding a way to help.
OT security isn't harder than IT security. But treating them as though they're identical is a good way to fail.
