Most plants, compressor stations and process facilities have layers of protection that exist for one reason: to bring a process to a safe state when something goes wrong. Many of those layers are now digital. That raises a question owners and operations managers rarely hear asked out loud: if someone with bad intent, or a careless contractor, touched the digital part of a safety function, what would actually happen?
You do not need to be a controls engineer to ask the right questions. You need to know where the safety systems are, who can change them, and how they connect to everything else. This post gives you a framework for that conversation.
Why safety systems deserve separate attention
Basic process control keeps a process running. Safety systems exist to intervene when the process leaves its safe limits. They are usually built to be independent of the control system, with their own logic solvers, sensors and final elements. That independence is a design principle, and it only holds if the network and the people around it respect it.
Cybersecurity changes the risk picture because an independent design can be undermined by shared networks, shared engineering laptops, shared passwords or a vendor connection that reaches both. Treat any path that could alter safety logic, bypass a trip or silence an alarm as the highest-consequence path in your environment.
Questions to ask your engineers
Sit down with whoever owns controls and safety and ask these in plain language.
- Where are the safety controllers, and what network are they on? You want a clear answer, ideally a diagram. If the answer is "I think they share a switch with the control system," that is a finding.
- Who can modify safety logic? Name the individuals, the laptops and the software. Modification should require a deliberate, logged and approved action.
- Are keyswitch or mode settings used as intended? Many controllers have a physical run or program position. If it is left in program mode permanently for convenience, a network attacker has more freedom.
- How are bypasses and overrides controlled? Bypasses are a normal part of maintenance, but they should be authorized, time-limited and visible.
- What happens if the control network is lost entirely? The honest answer should be that the process fails to a safe state.
Questions to ask your vendors and integrators
Outside parties often built and still support these systems.
- Do you have remote access to our safety systems, and through what path?
- Is your engineering laptop used at other customer sites, and how is it scanned before it connects to our network?
- Can you provide current firmware versions, applicable security advisories and a recommended update path?
- What default accounts or passwords exist, and have they been changed?
Put the answers in writing.
Practical steps that do not require a rebuild
You can reduce risk without redesigning the facility.
Separate and restrict
Keep safety networks segmented from business IT and, where possible, from the basic control network, with a firewall that permits only the traffic that is required. Document the allowed paths so changes are noticed.
Control the engineering workstation
The laptop that holds the programming software is the most valuable target in the building. Dedicate it, keep it patched on a schedule agreed with the vendor, remove email and web browsing from it and store it securely when not in use.
Manage change on purpose
Require a written change request, a second person's review and a recorded before-and-after copy of the logic for any change to safety functions. This is good engineering practice and also gives you something to compare against if something looks wrong.
Keep backups of controller programs
Store known-good copies of safety and control logic offline, and note which version is running. After an incident, a trusted backup is the difference between hours and weeks.
Where compliance fits
If you operate under frameworks such as NERC CIP or TSA security directives for pipelines, you already have expectations around access control, change management and incident response that touch these systems. Even if you are not directly regulated, these frameworks and general guidance from CISA and ISA/IEC 62443 offer a sensible vocabulary for what good looks like. Use them as a checklist, not a burden.
Getting started
Begin with a single page: where the safety systems are, what they connect to and who can touch them. That page alone often surfaces surprises. Ironfield Cyber helps energy and industrial operators build that picture and prioritize the fixes that fit their budget and their outage windows. If you would like a second set of eyes, we are glad to walk through your environment with your engineers.