SCADA and OT Security: What Office IT Should Do, and What It Must Not Touch

Why office security rules break control systems

Office IT security is built on a priority order: keep data confidential, keep it accurate, keep it available. Operational technology inverts that. A control system exists to keep a process running safely, so availability and safety come first and confidentiality last. That single inversion explains nearly every disagreement between IT and engineering teams.

It is why an IT-standard patch cycle is not simply harder in OT, it is sometimes wrong. Patching a controller may require the process to stop, may void a vendor's certification, and may not be testable in advance. It is why automatic updates are disabled rather than encouraged, why antivirus is often absent from control workstations, and why a device can run an operating system that went out of support a decade ago and still be the correct engineering decision.

Engineers are not being obstructive when they refuse a patch window. They are applying a different and equally valid risk model. The productive conversation starts by accepting that, then asking what protection is possible without touching the system.

There is a second difference worth naming: lifespan. Office equipment is replaced every three to five years, while a controller commissioned with a plant may be expected to run for twenty. That means an OT environment always contains equipment older than any current security model assumes, and it will still be there after the next two refresh cycles of the office estate. Plans that depend on eventually replacing it are not plans.

Where incidents actually come from

The mental picture of an OT incident is a targeted attack on a controller. Those exist and they are serious, but they are not what most organisations face. The ordinary path is far less dramatic: an office network compromise that spreads sideways into an unsegmented plant network, or a vendor remote access connection that was left enabled and forgotten.

Ransomware is the most common version. It is usually not aimed at the control system at all. It encrypts whatever it can reach, and if the plant network is reachable from the office network then engineering workstations, historians and human-machine interfaces are simply more files to encrypt. Production stops as a side effect of an attack that was never aimed at production.

CISA publishes guidance on industrial control systems that reflects this pattern, and it is the reason the highest-value work for a general IT provider is almost always at the boundary rather than inside the control system.

• Office compromise spreading sideways into a flat plant network.
• Vendor remote access enabled permanently and never reviewed.
• An engineering laptop that moves between the office and the plant.
• USB media used to move files where no network path exists.
• Ransomware encrypting OT assets incidentally rather than deliberately.

SCADA cyber security standards worth knowing, briefly

Two references cover most of what a non-specialist needs. The ISA/IEC 62443 series is the sector standard for industrial automation and control system security, and it is what an OT specialist or a serious client audit will reference. Its central idea is worth borrowing even if you never implement the full series: group assets into zones by function and criticality, and control every conduit between those zones.

NIST Special Publication 800-82, the guide to operational technology security, is the more readable companion and is freely available. It covers the same ground in a way a competent IT person can act on, including the architectural patterns for separating enterprise and operational networks.

Neither is something a small firm implements wholesale. Both are useful as a reference point when a client asks what you follow, and as a structure for deciding what to protect first.

Segmentation, which does most of the work

If an organisation does one thing, it should be separating the enterprise network from the operational one, with a controlled boundary between them. The pattern in the standards is a layered one: office systems in their own zone, operational systems in theirs, and a controlled intermediate zone holding the few things that genuinely need to talk to both, such as a historian or a reporting server.

The rule at the boundary is that nothing crosses unless it has been justified. Traffic flows in one direction where possible, on named ports, between named hosts. An operational device should not be able to reach the internet, and an office laptop should not be able to reach a controller. This is ordinary firewall and switching work, which is precisely why a competent IT provider can deliver it without touching the control system.

Document it as you build it. A diagram showing the zones and a rule list explaining each crossing is the artefact every auditor asks for, and reconstructing it later is considerably harder than recording it at the time. Our network security for small business page covers how these segments are built and documented.

Start with the crossings rather than the zones. In most sites there are fewer genuine reasons for traffic to cross between office and plant than anyone expects, often a historian pushing production figures one way and little else. Listing those honestly, then denying everything not on the list, gets a site most of the benefit in an afternoon of firewall work.

Remote access, the most common serious finding

Almost every industrial site has remote access for vendors, and in most cases it was created during commissioning and never reviewed. It is frequently always on, often shared between several of the vendor's engineers, occasionally documented nowhere, and it bypasses whatever boundary controls exist because it was installed before anyone thought about them.

The workable arrangement is that vendor access is disabled by default and enabled on request for a specific piece of work, through a route you control rather than one the vendor installed. Sessions are attributable to a named individual rather than a shared account, and they are logged. This is not a hostile position and vendors accustomed to regulated sectors expect it.

The same discipline applies to your own engineers connecting from outside. Access tied to identity with multi-factor authentication, not a port forwarded to an engineering workstation, which is the arrangement attackers scan for continuously.

Monitoring without touching anything

A useful property of operational networks is that their traffic is highly predictable. The same devices talk to the same devices in the same patterns, day after day. That makes anomalies unusually visible, and it means passive monitoring gives real value without any change to the control system itself.

Passive monitoring means observing a copy of the traffic rather than sitting in its path, so there is no risk of interrupting a process. It builds an asset inventory as a by-product, which is valuable in itself because many sites genuinely do not have a complete list of what is connected. And it detects the things that matter: a new device appearing, a controller talking to something it has never talked to before, or traffic attempting to leave for the internet.

For a firm without OT specialists, this is often the most honest first step. It produces an inventory and a baseline, it carries no operational risk, and it gives whoever eventually does the specialist work a factual starting point.

The inventory it produces is frequently the most useful output. Sites that have grown over a decade routinely find devices nobody remembered, installed by a contractor for a project that finished years ago and never removed. You cannot protect what you do not know exists, and passive monitoring is the only way to build that list without touching anything.

Backup and recovery in an OT context

Recovery in operational technology is not the same exercise as in an office. What matters is not only files but configuration: controller programs, HMI projects, historian databases, network device configurations and the licences that let software run at all. A site that has backed up its file server but not its controller logic will find that out at the worst moment.

The recovery objective is also different. The question is not how much data you can afford to lose but how quickly the process can be brought back safely, which often depends on physical steps and vendor involvement rather than on restoring a file. That makes a documented, rehearsed procedure worth more than a fast backup.

Store those backups offline and separately from the office backup system, so a ransomware event that reaches the enterprise network cannot encrypt the means of recovery. Our backup that actually restores guide covers the testing discipline, and it applies with more force here.

What a general IT provider should and should not do

The honest boundary is this, and it is the same one we apply to IoT projects generally. A general IT provider can properly design and maintain the enterprise network, build and document the segmentation between enterprise and operational zones, control the remote access route, run passive monitoring, secure the engineering laptops that move between environments, and produce the evidence an auditor asks for.

A general IT provider should not configure controllers, patch or modify control system software, change HMI or SCADA configuration, or make any change that could affect a safety function. Those belong to the system vendor and the site's engineering authority, under whatever certification regime applies.

We state this plainly because the alternative is worse. A provider who accepts OT work to win a contract, then makes a change that stops a process or invalidates a certification, has caused a far larger problem than the one they were hired to solve. Our IT support for oil and gas companies page sets out where we draw that line, and our cybersecurity service covers the enterprise side we do own.

Vessels are the other operational environment where office rules break things, covered in maritime cyber security and what the IMO expects.

Where we can help is the boundary this post keeps returning to: the office network, remote access and accounts that touch the control environment. We are not an OT specialist and will not change a controller or a historian. What we offer is an IT/OT boundary review: how the office and plant networks are separated, who can reach the control side remotely and how, which shared accounts exist, and whether backups of configuration actually restore. It runs alongside your OT vendor, uses the same approach as our cyber security audit, and you can ask for a scoped review.

Frequently asked questions

Written by Srinivasan Ramachandran, Founder, Listonics · Published Sep 28, 2026 · Last reviewed October 13, 2026 · 2,181 words