Two firewall vendors between IT and OT: when the second brand earns its cost, and how to keep two rule bases honest

A Friday afternoon on a sterile filling site. The IT team forwards a vendor bulletin: a critical flaw in the VPN feature of the firewall brand the company uses everywhere, already exploited, patch available. Someone in automation opens the network drawing and goes quiet. The corporate edge firewall, the firewall between the office network and the plant DMZ, and the one between the DMZ and the production network are all the same brand and run the same operating system. The plant pair has not been updated since the line was qualified, because every update is a change to a qualified system and nobody ever scheduled one.

Three firewalls, one weakness. A multi-vendor design is meant to prevent exactly that. It is also a design many sites adopt for the wrong reason, put in the wrong place, and then cannot maintain. This article looks at when a second firewall brand is genuine defence in depth on a GMP or process site, what it really costs, and how to keep two rule bases saying the same thing.

Where the question comes from

In December 2024 Dragos published a short position on the subject. According to Dragos, its incident-response team had seen several OT environments widely compromised over the previous quarter because they relied on vulnerable or end-of-life firewalls from a single vendor, and patching of OT perimeter devices often lags months or years behind the enterprise perimeter. Its conclusion is conditional. A second vendor is a valid layer for mature, well-resourced organisations, provided both products are kept up to date and monitored; for everyone else, one vendor run well is the better choice.

The idea is older than that. NIST SP 800-82 Rev. 2 (2015), describing a pair of firewalls between the corporate and control networks with the shared servers in between, noted that firewalls from two different manufacturers “may offer an advantage”, and in the same paragraph named the price: more cost and more management complexity. Rev. 3 (September 2023) drops the vendor-diversity discussion and concentrates on what the rules must do.

What the second brand actually protects against

A firewall is software exposed to the network it filters. When its own code has a flaw reachable from outside, the rule base stops mattering, because the attacker is on the device rather than passing through it. Two entries in the US Known Exploited Vulnerabilities catalogue from 2024 show the pattern. CVE-2024-21762, an out-of-bounds write in one major vendor’s firewall operating system, was added as exploited on 9 February 2024; CVE-2024-3400, a command injection in another major vendor’s VPN gateway feature, followed on 12 April 2024. Two brands, two flaws, two months apart.

With the same brand on both sides of the DMZ, one of those days opens both doors at once. With two brands, the same exploit opens one, and the second still has to be beaten some other way. That is the entire benefit, and it only holds under three conditions.

1. Both brands stand on the same path. Diversity helps only if an attacker coming in has to cross both products. A remote-access gateway that lands directly in the production network, or a machine builder’s cellular router, is a path that crosses neither. Dragos makes the same point: every way into OT, remote access included, should face both.
2. Both are maintained to the same standard. A second firewall three firmware versions behind adds a weak point rather than a layer.
3. The attack does not start inside. Diversity at the perimeter does nothing against a compromised engineering laptop already sitting at level 3, the operations network between the DMZ and the control cells. Dragos notes that many serious attacks start from trusted devices there, and that risk is dealt with by zoning further down, not by the brand at the top.

The options, side by side

We usually recommend the second row first. It gives the split of responsibility NIST already described in 2015: the office-side firewall belongs to IT and the plant-side one to the automation or OT team, each with its own rules. Changing the brand of one of the two is a later step, worth taking once both are patched on time and their rules are documented.

What the second brand costs

The hardware is the cheap part. The real cost is everything that now comes twice.

Start with the rule languages. Object names, zone concepts, rule order and implicit rules differ between vendors, so the same intent (“the historian in the DMZ may read the plant historian on one port”) is written differently on each side, and every translation is a chance to get it wrong. Then the patch streams: two advisory feeds to watch, two test campaigns, two maintenance windows. On a GMP site each update is a change to qualified infrastructure, which means two change records as well.

Skills double too. The night-shift technician who can find their way round one console may be lost in the other, and in an incident the firewall nobody can operate is the one that stays open. Logs come in two formats; unless both are collected and read centrally, the second firewall’s alerts go nowhere. NIST SP 800-82 Rev. 3 asks for network devices, firewalls included, to log to a central platform for monitoring and incident response.

Troubleshooting gets harder as well. NIST SP 800-41 Rev. 1 warns that several layers of firewalls make it harder to find where a connection is being dropped, and that layered policies are hard to keep coordinated, “particularly likely when firewalls are from different manufacturers”. When a batch report stops reaching the MES at 3 a.m., every minute spent working out which of two firewalls dropped it is a minute the line waits.

The rules must say the same thing: one flow matrix, two rule bases

The failure we meet most often with two brands is drift. Each side was configured once, by different people, then changed separately. Two years on, the office-side firewall allows a flow the plant-side one blocks, nobody knows which is right, and every new request turns into archaeology.

The way out is to stop treating either rule base as the reference. The reference is a vendor-neutral flow matrix, kept under document control, and both firewalls implement it. Each line names a source zone and host, a destination zone and host, the protocol and port, the direction, the business reason, the owner, the change record that approved it, and an end date if the flow is temporary. Each firewall rule carries the identifier of its matrix line in its comment field. NIST SP 800-41 Rev. 1 already asks for this kind of discipline: a log of every policy decision and rule change, a comment on each rule where practical, regular reviews of every change since the last one, and backups of the rule sets in every format the device offers, including a human-readable one an auditor can follow.

What the matrix allows is set by the zone model. IEC 62443-3-2:2020 asks for the system to be partitioned into zones and conduits, the risk of each assessed and a target security level set for each; IEC 62443-3-3:2013 lists the technical requirements a control system must meet at each level. NIST SP 800-82 Rev. 3 adds two rules that belong in every matrix. Permit connections only between adjacent levels or zones, so the office network never talks straight to a controller. And make outbound rules from the plant as strict as inbound ones, under a deny-all, permit-by-exception policy. Start from the risk, as described in zones and conduits: start from the risk, not from the rules you happen to have.

The GMP side of it

EU GMP Annex 11 never mentions firewalls, but three of its clauses describe what a two-brand design has to survive. Clause 10: “Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.” A firewall rule protecting a qualified system is part of that system’s infrastructure configuration. Clause 11 asks for periodic evaluation, including security and incidents, and the yearly comparison of both rule bases with the matrix is the obvious evidence. Clause 12.1 asks for physical and/or logical controls restricting access to authorised persons, which is what the firewalls between office and plant are.

Two practical consequences follow. A patch on either firewall goes through change control with a risk assessment that says which flows are tested afterwards, so the test list comes from the matrix and not from someone’s memory. And the qualification of the network infrastructure records both rule bases as configuration items, with their version, so that an inspector asking “what changed since the last evaluation?” gets a diff rather than an anecdote.

What is changing in the regulations

NIS2 (Directive (EU) 2022/2555) has applied in national law from 18 October 2024 in the Member States that have transposed it, and manufacturers of basic pharmaceutical products and pharmaceutical preparations are among the entities listed in its Annex I. Article 21(2) asks for measures that include supply chain security and “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. A firewall left unpatched because the second brand has no owner falls squarely under that heading.

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024 and will apply from 11 December 2027, with manufacturers’ reporting of actively exploited vulnerabilities starting earlier, on 11 September 2026. Firewalls and intrusion detection and prevention systems are listed in Annex III as important products of class II, so their manufacturers will have to show conformity through a third-party procedure rather than self-assessment (Article 32(3)). Both vendors’ vulnerability handling then becomes a fair question for the purchase specification.

Eight lines for the decision file

1. The threat it addresses: exploitation of one vendor’s perimeter code, stated in the risk assessment of the conduit, not “best practice”.
2. Placement: which boundary each brand protects, and confirmation that every way into OT, remote access and supplier connections included, crosses both.
3. Ownership: a named team for each firewall, and who decides when the two disagree.
4. Flow matrix: the controlled document both rule bases implement, with the rule-to-line reference in every rule comment.
5. Patch commitment: the maximum delay between a vendor advisory and its assessment, and between assessment and deployment, for each brand.
6. Logging: both firewalls sending to the same central platform, with someone actually reading it.
7. Skills: at least two people per brand able to read, change and restore it, out of hours included.
8. Lifecycle: end-of-support dates for both products, and the budget line that replaces them before those dates.

Where to start

Before buying a second brand, make the one you have trustworthy. List every firewall between office and plant with its firmware version and support date. Write the flow matrix from the current rules and mark every rule nobody can justify. Check that remote access crosses the DMZ instead of going round it; the cellular router tucked away in a machine cabinet is the classic exception, as described in the air gap decays on its own. Then put the two plant-facing firewalls on a patch schedule that survives production planning. If the team can then keep both up to date and read both logs, a second brand on the plant side of the DMZ is a real layer. If it cannot, the money is better spent on monitoring.

Five common mistakes

• Diversity on paper only. Two brands at the DMZ, while a supplier VPN terminates directly on the production network and crosses neither.
• The second brand nobody patches. The plant-side firewall is the one that drops out of the patch cycle, because it sits behind change control and nobody owns its advisories.
• Two rule bases, two truths. Rules changed on one side and not the other, with no reference document to say which is right.
• “Any” rules for commissioning. A broad rule opened for a start-up, never closed, now on both firewalls and justified by neither.
• Diversity instead of the basics. A second brand bought while the network has no monitoring, no tested restore of the firewall configuration and no incident plan. Dragos gives the same warning: the second vendor should not take resources away from monitoring, incident response, architecture or vulnerability management.

Two brands at the door are worth exactly as much as the weaker one is maintained.

References

• Dragos, Multi-Vendor Firewalls in OT Networks: Benefits, Risks, and Best Practices, blog, 9 December 2024: dragos.com
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023, §5.2.3: nvlpubs.nist.gov
• NIST SP 800-82 Rev. 2, Guide to Industrial Control Systems (ICS) Security, May 2015, §5.5.5 (paired firewalls): nvlpubs.nist.gov
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, September 2009, §3.3 and §5.5: nvlpubs.nist.gov
• IEC 62443-3-2:2020, Security risk assessment for system design: webstore.iec.ch
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 32 and 71, Annex III: eur-lex.europa.eu