What If the Firewall Fails? Cyber-Informed Engineering and the Return to Engineering Judgment

Almost every OT security control assumes it will work. Segmentation assumes the firewall rules hold. Access control assumes credentials are not stolen. Monitoring assumes the alert is seen and acted on. Each is reasonable, and collectively they describe a defense that depends entirely on the controls performing as designed.

Cyber-Informed Engineering starts from the opposite assumption. It asks what the process does when those controls fail, and whether the engineering itself can be arranged so that a cyber failure cannot produce an unacceptable consequence in the first place.

Engineers who work in functional safety will recognize the reasoning immediately, because it is the same one. We do not design safety instrumented systems on the assumption that the control system will behave. We design them for the case where it does not.

 

Where CIE Came From

The National Cyber-Informed Engineering Strategy was published by the US Department of Energy in June 2022, developed under congressional direction in the National Defense Authorization Act for FY2020 and built on foundational work at Idaho National Laboratory.

Its premise is that cybersecurity is introduced too late. By the time a control system is commissioned, the consequential decisions about architecture, redundancy and failure behavior are already fixed, and security is reduced to protecting whatever was built. CIE moves the question earlier, into design, where the cheapest and most effective option is available: engineering the risk out rather than defending it.

INL and NREL now lead a standards working group incorporating CIE principles into engineering standards. That is the detail worth noticing, because it signals CIE is heading toward the same place functional safety already occupies.

 

The Questions CIE Asks

CIE is framed as a set of principles rather than a control list. Applied practically in an industrial environment, they converge on a small number of questions that most security assessments never ask.

• What is the worst consequence this system could cause? Not the worst breach. The worst physical outcome, expressed in process terms.
• Can that consequence be engineered out? A mechanical relief device cannot be reprogrammed remotely. A physically limited valve stroke cannot be commanded past its limit. Engineered controls are not subject to credential theft.
• Does this system need to be digital, or connected, at all? Design simplification reduces attack surface more reliably than any control added afterwards.
• What depends on what? Interdependency evaluation asks which systems share power, communications, timing or infrastructure, and what fails together.
• If this is compromised, can we still operate safely? Planned resilience treats compromise as a design condition rather than an incident to be avoided.

 

Where CIE and functional safety meet The second question is the one that makes CIE recognizable to process engineers. It is the logic behind independent protection layers. A relief valve provides risk reduction that does not depend on the control system being correct, which is exactly why it can be credited in LOPA. CIE generalizes that reasoning from process hazards to cyber-initiated ones: prefer protection that cannot be defeated by compromising software, because software will eventually be compromised.

 

Why This Matters More Than It Did Five Years Ago

Two developments have made the CIE argument harder to dismiss. Industrial ransomware is now routinely stopping production without attackers reaching a control system at all, which means the perimeter model was defending the wrong boundary. And IEC 61511 Clause 8.2.4 requires a cybersecurity risk assessment within the safety lifecycle, which formally connects the two disciplines rather than leaving them to coordinate informally.

The TRITON malware made the same point in the most direct way available. It did not target the process. It targeted the safety instrumented system, so that the protection layer would fail when it was eventually needed. A defense strategy that assumes the safety system is a given rather than a target is incomplete.

 

Applying CIE Without Rebuilding the Plant

CIE reads as a greenfield discipline, and it is strongest there. But most of its value in existing facilities comes from changing which questions get asked in work already happening.

 

Existing Activity	CIE Question to Add
Process hazard analysis	Could a cyber event initiate this deviation, and does the safeguard depend on software?
LOPA and protection layer review	Which credited layers could be defeated by compromising a digital system?
Management of change	Does this modification introduce a digital dependency where none existed?
Capital project design review	What is the worst consequence, and can it be engineered out before detailed design?
Spares and obsolescence planning	Are we replacing a non-digital component with a connected one, and is that necessary?

 

None of these require a new program. They require the hazard study and the security assessment to be informed by each other, which in most organizations they are not, because different people run them at different times for different audiences.

 

Why Choose Arista Cyber

CIE requires both disciplines in the same room, and that is uncommon. Most cybersecurity consultancies cannot assess whether a protection layer is defensible in process terms. Most functional safety consultancies cannot assess whether it is defensible against a cyber initiator.

Arista Cyber operates across both. Our practitioners are TUV Rheinland certified in functional safety and work daily in IEC 62443 environments. That lets us run consequence-driven analysis where the cyber scenario and the process scenario are evaluated together, extend HAZOP and LOPA to include cyber initiators, and design architecture where the protection that matters most does not depend on software integrity.

 

Next Steps

If your hazard studies and your security assessments have never been in the same conversation, that gap is where CIE starts. Explore our functional safety services, read about how IEC 61511 and IEC 62443 work together, or contact the Arista Cyber team.

 

Common Questions

Is Cyber-Informed Engineering a standard we have to comply with?

No. CIE is a design philosophy set out in a US Department of Energy national strategy, not a mandatory standard. There is no CIE certification and no compliance obligation. INL and NREL are leading work to incorporate CIE principles into engineering standards, so elements may appear in standards over time, but today it is a way of thinking rather than a requirement. See the INL CIE resources for the published guidance.

How is CIE different from IEC 62443?

IEC 62443 specifies how to secure an industrial control system: zones, conduits, security levels, access control. CIE asks a prior question, which is whether the system needs to be built that way at all, and whether the consequence can be engineered out before security controls become the only defense. They are complementary. Our guide to functional safety standards covers where each framework sits.

Can CIE be applied to an existing plant?

Yes, though the leverage is smaller than in new design. The practical route is adding CIE questions to activities already running: cyber initiators in process hazard analysis, protection layer review that examines software dependency, and management of change that flags new digital dependencies. Capital projects and major modifications are where existing facilities get the greatest benefit, because the design is still open.

 

Are your hazard studies and security assessments talking to each other? Arista Cyber runs consequence-driven analysis across both disciplines, with TUV Rheinland certified practitioners working in IEC 62443 environments. Book a Free Consultation