The Control Room Test: When Cybersecurity Best Practice Meets Operational Reality

Cybersecurity frameworks tell us what good security should look like.

The control room tells us whether it can actually be implemented without compromising availability, process integrity, maintainability, or the operator’s ability to recover.

Those perspectives should reinforce one another. Too often, they meet only after a recommendation has already been approved.

Over the years, I have seen technically sound cybersecurity recommendations become difficult to implement, ineffective, or even introduce new operational risks when applied in a live industrial environment.

A critical asset may have no redundancy. A remote connection may be the only way to reach the specialist who can troubleshoot a system. A security update may require a firmware change, a restart, an engineering dependency, or a maintenance window that has never been tested against the current process configuration.

The cybersecurity objective may be completely valid.

That does not automatically make the proposed implementation complete.

Before approving a significant cybersecurity change in OT, I ask one question:

Would I still make this recommendation if I were personally accountable for keeping the process safe, available, and running?

I call it The Control Room Test.

A decision lens, not another framework

The Control Room Test is not a replacement for cybersecurity frameworks, engineering standards, or regulatory requirements.

It is not a justification for accepting unnecessary risk. It shouldn't be used as an excuse to avoid difficult changes, as operations prefer the status quo.

It is a decision discipline for translating a cybersecurity objective into a change that the operation can understand, implement, validate, recover from, and sustain.

The test moves the conversation beyond:

“Is this recognized cybersecurity practice?”

It adds a second question:

“How do we achieve the objective without creating an unmanaged operational consequence?”

A recent industrial advisory provides a useful example.

A critical flaw, and an architectural question

On August 13, 2026, CISA published https://www.cisa.gov/news-events/ics-advisories/icsa-26-225-02 concerning the Haiwell IoT Cloud HMI Gateway.

The advisory covers https://nvd.nist.gov/vuln/detail/CVE-2026-19188, an operating-system command-injection vulnerability in the product’s network diagnostic function. User-supplied input could be passed to the underlying operating system without proper sanitization, potentially allowing arbitrary commands to run with root privileges.

The vulnerability received a CVSS v3.1 score of 10.0. The published record identifies version 3.40.1.12 as affected and version 3.50.1.19 as unaffected. CISA reported no known public exploitation at the time of publication.

Those are the confirmed facts.

The operational consequence cannot be determined from the score alone.

Root-level command execution on a gateway is serious, but it does not automatically mean an attacker can manipulate a controller or change a physical process. That depends on the deployed architecture: how the gateway is reached, which interfaces are exposed, where authentication occurs, what routes exist, which credentials are available, and what downstream systems trust the device.

That distinction is not minimization. It is how operators move from a vulnerability alert to a defensible engineering response. The device name can hide the boundary

An HMI was once understood primarily as an operator interface. It displayed process conditions and allowed an authorized operator to interact with the control system.

In a connected architecture, a device described as an HMI or HMI gateway may also support cloud connectivity, remote maintenance, data exchange, vendor diagnostics, centralized monitoring, or communication toward Level 1 and Level 2 assets. Functionally, people may still call it “the HMI.”

Architecturally, it may sit at the intersection of:

• operator access;
• control-system communications;
• internet or cloud connectivity;
• remote support;
• authentication and administration;
• engineering activity; and
• A possible path toward physical control.

At that point, it is no longer only a screen.

It has become part of the security boundary.

That is why an asset inventory that records only the product name, IP address, and firmware version is not enough. The organization also needs to understand the device’s operational function, communication paths, trust relationships, remote dependencies, and safe failure mode.

“Patch it” may be correct, but incomplete

For an affected deployment, updating to the vendor-supported fixed version may be the correct technical action.

The Control Room Test does not challenge the need to remediate. It determines how remediation should be executed responsibly.

Before the change, operators and engineers should establish:

• What process function depends on the device;
• whether another operator interface or local control capability is available;
• whether the update has been tested with the installed application, drivers, communications, and controller versions;
• whether a restart or loss of visibility will occur;
• whether current configuration files and licenses are available;
• whether the backup can actually be restored;
• How rollback will be performed; and
• What will the process consequence be if the device does not return to service?

None of these questions argues against patching. They turn patching from an instruction into a controlled operational change.

“Disconnect it” may also be correct, but incomplete

If a gateway is directly exposed or an external pathway is unnecessary, removing that exposure should be urgent. But the organization still needs to understand why the connection exists.

Does it support the only available specialist? Is it required for maintenance, monitoring, or regulatory reporting? Can the same requirement be met through a brokered, identity-controlled, time-limited, and monitored access path? Can administrative access be separated from operator functions? Can the connection be revoked quickly without impairing safe local operation?

The choice is not limited to leaving the pathway open or removing it without preparation.

The better engineering response may combine immediate containment with a planned permanent architecture:

• Eliminate direct public reachability;
• Restrict management access to authorized sources;
• Segment the gateway from systems it does not need to reach;
• separate operator, administrative, and vendor-support privileges;
• Time-limit and monitor remote sessions;
• Retain the logs required to investigate suspicious activity;
• verify that the gateway cannot become an uncontrolled bridge; and
• Preserve a tested local operating and recovery capability.

The security objective should remain firm. The implementation path should be engineered.

The five questions behind The Control Room Test

For any significant OT cybersecurity recommendation, leaders should ask five questions.

1. What operational function could this change affect?

Start with the process, not the CVE, firewall rule, or compliance requirement. What does the system actually do? Which safety, production, quality, environmental, or reliability functions depend on it?

2. What is the complete trust path?

Map the connection end-to-end. Include identities, cloud services, remote-support infrastructure, gateways, management interfaces, engineering workstations, controllers, shared credentials, and alternate routes. A diagram is useful only if it reflects the deployed environment.

3. What happens if implementation fails?

Security teams are trained to consider the risk of doing nothing. OT must also consider the risk introduced by the change. Can the operator still see and control what matters? Could the change remove the last layer of redundancy or disrupt a recovery dependency?

4. Can we test, reverse, and recover?

A rollback statement in a procedure is not a recovery capability. The organization needs verified backups, compatible firmware, configuration files, licenses, engineering tools, competent personnel, and a realistic restoration time.

5. Who owns the consequence, and what evidence closes the decision?

Cybersecurity may identify the exposure, but a change affecting production, safety, maintenance, or recovery cannot remain solely inside the cybersecurity function. Operations, engineering, system ownership, and cybersecurity need clear decision rights, success criteria, residual-risk ownership, and post-change verification.

The boardroom needs operational evidence

Executives do not need to approve every firewall rule or firmware update. They do need evidence that the organization can make security changes without losing control of the process. Useful measures include:

• The percentage of remote-capable OT assets with a named operational and architectural owner;
• the number of externally reachable OT management interfaces;
• The time required to revoke or isolate a remote-access path;
• The percentage of critical changes with a verified rollback method;
• The tested restoration time for critical HMI and gateway configurations; and
• Whether the facility can continue safe local operation when a cloud or remote-support service is unavailable.

These measures connect cybersecurity investment to operational resilience. They also expose whether the organization has purchased security technology without building the engineering and operating capability required to use it effectively.

One test, several recurring decisions

The Control Room Test brings together a principle running through my recent articles.

In "A Protection Relay Is Not Another Endpoint," I argued that a severity score cannot determine the response to a field-level vulnerability without understanding operational function, reachability, dependencies, and remediation risk.

In Private Connectivity, Public Consequences, I argued that private connectivity is not automatically a security boundary. Trust must be earned through verified isolation, explicit pathways, monitoring, and accountability.

In "Before an AI Agent Enters the Control Room, Find Where It Fails", I argued that authority must be matched by assurance. The closer an AI system moves toward operational decisions, the more rigorously its limits, permissions, failure behavior, and human oversight must be tested.

The technologies differ. The leadership discipline is the same.

Understand the function. Map the trust path. Limit authority. Test the change. Preserve safe operation. Verify recovery. Make accountability explicit.

Make cybersecurity executable

The lesson from a cloud-connected HMI is not that every HMI should be disconnected from the cloud. It is not that every update should be delayed. It is not that operational constraints should overrule necessary security action.

The lesson is that cybersecurity recommendations in industrial environments must be translated through architecture, engineering, operations, recovery, and business accountability.

A protection relay is not another endpoint. Private connectivity is not automatically trusted connectivity.

An AI agent should not receive operational authority that has not been tested and governed. And a connected HMI is no longer only a screen.

Before approving the next significant cybersecurity change in OT, ask:

• If the answer is yes, proceed with evidence.
• If the answer is no, the cybersecurity objective may still be correct.
• It probably means the engineering work is not finished yet.

The Control Room Test does not weaken cybersecurity. It makes cybersecurity executable in the environment it is intended to protect.