Cyber

Cybersecurity in critical infrastructure has long centered on keeping adversaries out. But industrial systems operate under a different constraint: a compromised network does not automatically have to become a catastrophic physical event. Cyber-informed engineering asks a different question. Where can physics, engineered design, and existing safety architecture make a high-consequence outcome impossible or survivable regardless of what happens on the network?

The Idaho National Laboratory describes CIE as an approach using engineered controls such as manual overrides, analog redundancy, functional isolation, mechanical interlocks, relief devices, and hardwired trips, positioned so that cyber compromise cannot drive the process to catastrophe. The urgency is real, as SANS already reported that 50% of ICS/OT incidents in its 2025 survey began with unauthorized external access, while nearly one in five took more than a month to remediate. Industrial cybersecurity firm Dragos reported that 25% of the ransomware incidents it investigated resulted in a complete OT site shutdown, illustrating how cyber incidents can cross the boundary from digital compromise into direct operational consequences.

CIE brings cyber risk into established process-hazard analysis and layers-of-protection analysis, treating malicious cyber activity as another potential initiating cause and connects to formalized standards including NIST SP 800-82, IEC 62443, and IEC 61511.

To support utilities in the fight against cyber-enabled sabotage, the INL developed consequence-driven cyber-informed engineering (CCE) on the stark premise that skilled adversaries will penetrate critical infrastructure networks. Here, the goal is to identify core essential processes and functions of critical infrastructure and then selectively reduce or eliminate digital pathways vulnerable to cyberattack.

Clearly, organizations are faced with the challenge of determining which consequences merit engineering out, where existing controls fail, and how process safety, engineering and cybersecurity teams build shared analysis. The work requires security practitioners who understand the process and engineers who see cyber as a genuine hazard. Equally important is honesty limits. Engineered safeguards are not a replacement for network defense. Every vertical has at least one consequence worth engineering out, but not every risk fits this approach.

How engineered controls can limit cyber consequences

Industrial Cyber asked experts where they had applied engineered or analog controls to render high-consequence cyber outcomes impossible or survivable, and how they determined the deployment strategy.

Lance Barnes, controls systems engineer at Idaho National Laboratory, said that he used this approach many times with above-ground oil-water separators. In these installations, an upstream pump delivered influent to the separator, and an overflow could result in the release of oil-contaminated water. The normal digital design used a continuous level transmitter connected to the PLC for control, monitoring, and alarming.

“For the final protective action, however, I used an independent, normally closed high-high liquid-level switch hardwired into the motor-starter control circuit for the upstream pump,” Barnes detailed. “When the separator reached the high-high level, the switch opened, the contactor dropped out, and the influent pump stopped. It stopped because it lost power, not because the PLC told it to. The PLC still received an isolated status signal for indication and alarming, but it did not get a vote in the protective action.”

He observes that this distinction makes the protection resilient to a specific cyber outcome. A stuck PLC output, an incorrect logic download, corrupted firmware, or an unauthorized person manipulating the program could not use the PLC to keep the pump running after the high-high switch actuated. The hardwired trip did not eliminate every possible mechanical or electrical failure, but it removed the PLC, and therefore a remotely accessible digital path, from the final shutdown function.

“A controls engineer from the 1980s or 1990s would probably recognize this as familiar practice, and that is part of the point,” Barnes pointed out to Industrial Cyber. “Over time, many designs consolidated hardwired relays, mechanical interlocks, and independent trips into programmable systems because doing so reduced cost and improved flexibility and diagnostics. Often, that was a reasonable trade. Cyber-informed engineering does not mean removing digital automation. It means deliberately restoring independent engineered backstops for the consequences that cannot be tolerated.”

Additionally, he mentioned, “I decide where to apply those backstops by starting with the consequence. If the hazard analysis identifies an unacceptable outcome, and compromise of one programmable platform could both create the hazardous condition and defeat the protection intended to stop it, then the final protective action should not depend exclusively on that platform. In the right application, the most defensible last line of protection may still be a switch, a contactor, and a wire.”

“We use engineered controls to protect major pieces of equipment such as pumps and electrical equipment in water and wastewater systems ,” Andrew Ohrt, resilience practice area lead at West Yost, told Industrial Cyber. “We have done this for years. We lacked the governance and framework provided by CIE, but preventing the impacts from cyber-physical attacks has been a focus of ours for many years.”

Victor Atkins, director of critical infrastructure security at 1898 & Co. , said that he has seen the greatest value from cyber-informed engineering when organizations focus engineered safeguards on cyber scenarios that could lead to unacceptable safety or business outcomes.

“Controls vary by process and may include hardwired shutdowns, mechanical protective devices, independent sensing and alarms, and local operator controls that remain effective even if digital systems are compromised,” Atkins said. “By adding independent layers of protection, organizations create barriers that a cyber attack must overcome before causing harm. CIE controls are most effective when identified during planning and design, where they can be evaluated alongside safety, operational, and business requirements.”

Andrew Ginter, vice president for industrial security at Waterfall Security Solutions , told Industrial Cyber that his company “does not use these tools ourselves, but we do see them used in critical infrastructure and heavy industry: oil and gas installations (all of upstream, midstream and downstream), power generation, rail systems and mining.”

He added, “Public examples: Nuvation and Fluence Energy announced their use of CIE to increase resilience of their battery products and the Idaho Dept. of Environmental Quality’s State Revolving Loan Fund reports that, after they offered incentives, 85% of selected applications for 2027 applied CIE controls.”

Putting cyber risks into process hazard analysis

The executives look into how they bring cyber into existing process-hazard or layers-of-protection analysis as an initiating cause.

“Earlier in my career, I never considered cyber manipulation as an initiating cause in a process hazard analysis. I was focused on making the control system function, keeping the process operating, and delivering product,” Barnes said. “If the system met its functional requirements and responded correctly to the equipment failures and process upsets we anticipated, I considered the job done. Looking back, that left an important question unasked: What if someone deliberately used the control system to create the failure?”

Barnes noted that the most important change was simple: when evaluating a critical process, I now assume for analytical purposes that a capable adversary has gained access to the digital control environment. “That does not mean preventive cybersecurity controls are unimportant or that every system is already compromised. It means I cannot guarantee that access controls, segmentation, and monitoring will stop every capable adversary, so I do not want the safety of the process to depend entirely on that guarantee.”

“From there, I use the existing hazard analysis structure and treat deliberate cyber manipulation as a credible initiating cause,” he added. “Could someone manipulate a measurement, change a setpoint, force an output, alter control logic, suppress an alarm, or make the operator see a false process condition? Then I ask the more important question: Could that same access also defeat the protection layers intended to stop the event?”

He mentioned that the second question is critical in a layers-of-protection analysis. “A control function, an alarm, an interlock, and a shutdown may appear to be separate layers, but if they all depend on the same PLC, network, engineering workstation, or supporting infrastructure, they may be vulnerable to the same compromise. I do not automatically credit a protection layer as independent until I understand whether the same cyber access that creates the hazardous condition could also disable or manipulate that protection.”

“I still believe strongly in keeping adversaries out through access control, segmentation, monitoring, and defense in depth,” Barnes identified. “The change is that I no longer treat those measures as a guarantee. I work from the assumption that access may eventually occur, then ask how the system can be designed so that an adversary still cannot create an unacceptable physical consequence. For the highest consequence scenarios, that may mean an independent protection layer, reduced digital authority, a hardwired shutdown, or another engineered limit that remains effective even when the primary control system cannot be trusted.”

Ohrt said that they largely do it naturally within their business and engineering design practices. “Our team has been aware of cyber risks for going on 20 years now. Over that time, we have refined our understanding of the risks and engineering/cybersecurity best practices to protect against or mitigate those risks.”

He added, “Even if our clients don’t specifically ask for it at this point, they are getting it. Sometimes we have to work through the value engineering process to retain our protections. While we experienced headwinds from that group in the past, many of our clients do not consider CIE and cyber protections as optional now.”

“We bring cyber into process-hazard and layers-of-protection analysis by treating compromise of a digital system as another potential cause of a hazardous condition, alongside equipment failures, human error, loss of communications, and other process upsets,” Atkins detailed to Industrial Cyber. “ Cyber risk to process controls is basically just another engineering challenge. Rather than treating cyber events as a separate category of risk, we evaluate how cyber-induced failures could affect the process and whether existing safeguards would still prevent unacceptable outcomes.”

He added that adoption improves when cyber-induced failures are incorporated into the same engineering reviews and risk management decisions used to manage safety, reliability, and operational performance.

Ginter sees customers using the Kenexis / ISA Security PHA Review methodology, or a variation. “In addition, INL and MITRE document how to apply CIE to traditional hazard methodologies including HAZOP, PRA, FMEA, STPA, HAZCADS and LOPA methodologies.”

He pointed to especially confusing concepts to beware of, particularly the need to account for cyber attacks as common cause failures of apparently redundant digital defenses. They must understand that probabilistic calculation of initiating events is not reliable for cyber attacks, because initiation and targeting are not random, but rather deliberate acts of an intelligent adversary.

Breaking down cyber and process safety silos

The executives examined what it would take organizationally to get security practitioners and process engineers working from a shared hazard analysis.

Barnes said that he believes the first organizational requirement is understanding why each discipline approaches the system the way it does. Process and controls engineers are usually measured by whether the process works, whether production targets are met, and whether the system can operate continuously for years with minimal interruptions. Security practitioners are responsible for controlling access because they understand that access can lead to manipulation, loss of visibility, and unwanted physical outcomes. Both perspectives are legitimate, and each directly affects the other.

The problem is that technical disciplines often work within their own boundaries. If a security requirement interferes with operations, a controls engineer may see it only as an obstacle unless someone explains how the exposure could affect the process. Likewise, a security practitioner may see an open port, remote connection, or shared account as an unacceptable vulnerability without understanding why that capability exists or what operational function would be lost by removing it.

“A shared hazard analysis has to begin with the physical consequence, not with a security control or a production requirement,” Barnes detailed. “Process engineers, controls engineers, operators, and security practitioners need to sit together and define what must not happen. The process and operations personnel explain how the system functions, how it can fail, and what constraints are necessary to keep it running. The security practitioners explain how digital access, trusted functionality, or shared dependencies could be used to create or conceal those failures.”

Organizationally, he added that it requires leadership to make the analysis a shared responsibility, involve security early enough to influence the design, and give the team time and authority to address what it finds. If security is brought in only at the end to approve a completed design, the discussion is likely to become a compliance exercise or a negotiation over restrictions. If everyone begins with the same unacceptable consequence, the conversation becomes an engineering problem that the team can solve together.

Neither group needs to become expert in the other group’s profession. They do need enough understanding to recognize how their decisions affect the other side. The shared purpose is not simply to lock down the system or keep production running at any cost. It is to operate the process safely, reliably, and securely, even when something goes wrong.

“Even a few years ago, this was a real challenge. However, with the various incidents in the water sector, the more sophisticated organizations with internal resources have largely addressed this,” Ohrt said. “Many people have an appreciation for cyber-physical consequences.”

“I do worry organizations that outsource most of their cybersecurity and process engineering services,” he added. “Oftentimes. these service providers are not contracted in a manner that incentivizes meaningful collaboration. There are ongoing efforts to help utilities procure improved services, so hopefully this helps. But individual organizations need to take it upon themselves to scope and contract work correctly.”

Atkins highlighted that organizational change starts with leadership. “Most organizations will not adopt design approaches that introduce cost, complexity, or operational constraints unless executives and risk leaders make cyber-informed engineering an explicit expectation. Progress accelerates when cybersecurity teams develop a working understanding of the process and its hazards, while engineers understand how compromise of digital systems can contribute to hazardous conditions and undermine existing protections.”

He added that effective organizations bring engineering , operations, safety, and cybersecurity personnel into the same hazard reviews, design discussions, and risk assessments, creating a shared framework for discussing consequences, safeguards, and risk tradeoffs.

“Shared understanding of each otherʼs domains and expertise,” Ginter said. Cyber people need to understand that engineers are experts on deployed safety, protection, automation and network engineering mitigations, which determine which physical consequences of cyber attacks are credible.”

He added that engineers need to understand that cybersecurity people are the experts on attack techniques and the limitations of cybersecurity tools, both of which are essential to evaluating residual risk. “Both must understand that when credible consequences are more serious in OT than IT, OT security must be materially stronger than IT. Leadership can encourage and reward collaboration. INL is actively developing additional adoption insights.”

Cyber-informed engineering and controls gap

The executives addressed where cyber-informed engineering is oversold and where network and monitoring controls remain irreplaceable.

Barnes said that cyber-informed engineering is oversold when it is presented as a replacement for traditional cybersecurity or as a way to engineer every cyber risk out of a system. Engineered protections are most effective when they are applied to specific, well-understood physical consequences. They can limit the authority of a control system, provide an independent shutdown, or prevent a particular hazardous state. They cannot protect every function, detect every intrusion, preserve every piece of data, or tell an operator whether an adversary is still present in the environment.

Network controls and monitoring therefore remain irreplaceable. Segmentation, access control, secure remote-access practices, and system hardening reduce the number of paths an adversary can use and limit how far a compromise can spread. Those controls may stop or contain many attempts before they ever reach the process. The fact that some capable adversaries may eventually get through does not make the controls unsuccessful. Every attack that is blocked, slowed, or confined is one less opportunity to manipulate the system.

He noted that monitoring serves a different but equally important purpose. An engineered backstop may prevent one unacceptable physical outcome, but it does not necessarily reveal that someone attempted to cause it. Without network and system visibility, an adversary could remain undetected, learn the process, establish persistence, or move to another function that does not have the same engineered protection. Monitoring helps identify abnormal communications, unauthorized configuration changes, suspicious commands, and other indications that the control environment may no longer be trustworthy. It also provides the information needed to understand the scope of an incident and recover safely.

“The right approach is not a choice between cyber-informed engineering and cybersecurity controls,” according to Barnes. “We should design critical physical functions to remain safe when digital defenses fail, while still making access difficult, limiting what an intruder can reach, detecting malicious activity, and removing the adversary from the environment. Engineering provides resilience against selected consequences. Network controls and monitoring provide prevention, containment, visibility, and response. We need both.”

“CIE doesn’t displace the need for network and monitoring controls,” Ohrt said. “My concern is that device and software vendors grab CIE and oversell customers on the CIE-ness and thus protectiveness of their ‘solution.’ I’ve observed it occasionally that the latest AI cybersecurity tool does CIE.”

He added, “We definitely benefit from working with the device and software vendors; we can’t do business without some of them. But we need to be realistic the protections that their goods provide.”

Atkins identified that cyber-informed engineering is oversold when it purports to replace cybersecurity. The converse is also true when cybersecurity claims to address all operational technology risk. Managing risk in process control systems requires both disciplines.

“Organizations need cybersecurity controls that protect system integrity, enforce access controls, monitor networks, and provide visibility into the environment,” he assessed. “They also need engineering controls that help prevent catastrophic failures or other unacceptable consequences if those protections are bypassed or fail. The strongest security programs combine both approaches and recognize that neither is sufficient on its own.”

“Software safeties are cheaper to deploy, test and repair, and thus arguably safer than analog, if we ignore cyber risk. But ‘oversold’ is a misnomer,” according to Ginter. “CIE includes practically all of cybersecurity in the body of knowledge. We are not choosing engineering over cybersecurity – CIE embraces both.”

He added that as to network controls , the single most universally applicable mitigation in the CIE engineering-grade mitigations DB is network engineering : deterministic prevention of attacks pivoting through consequence boundaries, such as unidirectional gateways, analog signalling and hardware-enforced remote access. “And, while not all cyber risk can be eliminated, we must remember that monitoring eng controls solve different problems. The best defenses use both.”

Prioritizing consequences for cyber resilience

The executives unpacked how organizations prioritize which consequences to engineer out versus manage through cyber controls.

“For an existing process, my best source of insight is usually the people who operate and maintain it. They know how the system actually behaves, not just how the drawings and procedures say it should behave,” Barnes said. “They know which alarms matter, which failures develop quickly, which operating conditions are difficult to recover from, and which seemingly minor problem can become a serious event. That practical knowledge is often the fastest way to identify the functions that deserve additional engineering protection.”

In one case, someone with direct operational experience recognized that a critical supporting function was not being confirmed before a major piece of equipment was allowed to start. That observation exposed a failure path that could have caused significant equipment damage and an extended outage. It was not obvious from the design documentation alone, but it was apparent to someone who understood how the system behaved in operation.

Operators should not make the prioritization decision alone, but their knowledge is essential. The strongest assessment combines their experience with process engineering, controls, maintenance, safety, security, and organizational leadership. The team should begin by identifying the consequences the organization truly cannot tolerate. Those might involve harm to personnel, an environmental release, damage to critical equipment, loss of an essential mission, or an outage from which recovery would be unusually difficult.

He added that once the consequences are identified, “I ask which process functions could cause, prevent, or limit them. Then I look at whether it’s possible to manipulate those functions can be manipulated digitally and whether the same compromise could defeat the protection layers intended to stop the event. I favor an engineered mitigation when the consequence is intolerable, develops too quickly for detection and human response, is difficult or impossible to reverse, or can be created and sustained through a single digital control path. The engineered solution should also be practical, testable, maintainable, and genuinely independent of the system it is protecting against.”

Barnes indicated that not every consequence meets that threshold. “If the outcome is limited, recoverable, or can be detected and contained before serious harm occurs, then network segmentation, access control, monitoring, incident response, and recovery measures may be the more appropriate investment. Engineering changes can introduce cost, complexity, nuisance trips, and new failure modes, so adding hardware is not automatically the safer choice.”

Ohrt characterizes it as fundamentally a discussion of tradeoffs. “Sometimes it is just less resource intensive and more convenient to take a cyber-control approach. For example, if you include a protective relay, then a licensed electrician needs to be available to do maintenance instead of something that can be maintained remotely by unlicensed staff.”

That being said, he added, “I have had conversations tradeoffs with clients that their engineering, integration, and cybersecurity service providers didn’t recognize or have the ability to articulate. The clients become pretty frustrated but often feel trapped by the contract vehicles that they have available to them. Improving procurement can help ameliorate these issues.”

“Ultimately, it is a risk management decision that is highly dependent on the system, process, and operating environment,” Atkins weighed in. “Not every cyber risk justifies an engineering solution, and attempting to engineer out every bad outcome is neither practical nor cost-effective. We prioritize the consequences an organization determines are unacceptable from a safety, operational, environmental, or business perspective. Those events deserve the greatest scrutiny when evaluating additional engineered safeguards.”

He added that cyber-informed engineering is most valuable when the consequence is severe enough that the organization wants more than a firewall standing between a cyber compromise and a physical outcome.

“Our customers choose engineering-grade mitigations when they are cheaper, more effective, or when software-based tools cannot reduce risk acceptably,” Ginter said. “Begin by identifying credible impacts which would be unacceptable for the organization: high-priority candidates for both engineering and cyber controls.”

He estimates that the most critical consequences are ideally protected by both cybersecurity and engineering. “Lesser consequences can be addressed with remaining budget and cyber or engineering tools, whichever are most cost-effective. But again, do not confuse monitoring with protection. ‘Hoping’ we can detect an attack before it results in catastrophe is not what we expect of engineers designing subways, nor automating critical infrastructures .”

Starting a cyber-informed engineering program

The executives discussed what advice would be most critical for operators beginning their cyber-informed engineering implementation.

“I would tell an operator to start with the product, not the PLC,” Barnes said. “I learned this while designing, operating, and maintaining chemical dosing systems used in potato warehouses. The organization’s mission was straightforward: deliver marketable potatoes that would remain stable through packaging, shipping, and storage. The process required washing the potatoes and applying the correct chemical treatment under a wide range of product and operating conditions.”

He added that “Once the mission was clear, we could identify the critical enabling function: apply the correct treatment at the correct rate. Too little treatment could allow the potatoes to spoil before reaching the market. Too much treatment could create product-quality and compliance problems. The operation was audited monthly, and the automatically generated dosing and process-variable logs were compared against independent testing.”

“First, define what the organization must accomplish. , identify the process function that is essential to that outcome and establish what the function must always do and what it must never be allowed to do,” according to Barnes. “Then trace everything that supports it, including the operators, procedures, chemical supply, pumps, valves, instruments, calibration practices, product flow, PLC logic, HMI settings, power, maintenance activities, and recordkeeping.”

The step he mentioned is to ask what happens if the digital system cannot be trusted. In this case, the control system both managed the dosing process and automatically generated the records used to demonstrate compliance. That is an important shared dependency. If the system produced an incorrect dose, could it also produce records indicating that the process was normal? The independent testing mattered because it provided a way to compare the control system’s digital record against a separate measure of the physical result.

“An organization does not need to analyze the entire facility at once,” Barnes added. “Select one critical function, walk it down from beginning to end, involve the people who operate and maintain it, identify the consequences of losing control, and challenge every digital assumption supporting it. Then implement a practical improvement, verify that it works, and repeat the process with the critical function.”

He noted that cyber-informed engineering begins with understanding what must be protected and why. Once that is clear, the network, control system , and security questions become much easier to focus on the things that actually matter.

“Consider which are the worst possible days that you can cause for your utility. Then assume an adversary can cause those same bad days,” Ohrt said. “How can you build resilience into your system through active defensive measures and improved resilience planning? Then go and implement those while preferably bringing your colleagues from IT, OT and engineering along with you.”

Atkins suggests starting with the outcomes organizations consider unacceptable. “Operators already understand the process, the equipment, and the conditions that can lead to safety incidents, environmental releases, equipment damage, or operational disruptions. From there, consider whether a digital system failure or compromise could contribute to those same outcomes.”

He added that the goal is not to turn operators into cybersecurity experts. It is to help them recognize that cyber events can influence the same process risks they manage every day. Most organizations do not need to apply cyber-informed engineering everywhere. Start with a few critical functions and the consequences that matter most, then build from there.

Ginter said that the CIE begins with two questions: What are the organization’s critical functions? What are the unacceptable consequences of compromise?

“Operators then identify engineered and cyber controls that might eliminate or mitigate harms caused by attacks,” he concluded. “Eg: West Yost has developed a book for the water sector showing how ‘a day without SCADA’ exercises can identify the most critical functions deserving engineered controls.”