Two advisories published on October 13 make a useful pair.

Rockwell Automation disclosed that its 1732E ArmorBlock I/O modules running software version 3.012 and earlier contain a flaw that lets an unauthenticated attacker change the device's webserver password (CVE-2026-12655). The correction is version 3.013.

The same day, Siemens published a bulletin clarifying that the per-variable "Accessible from HMI/OPC UA/Web API" and "Writable from HMI/OPC UA/Web API" attributes on SIMATIC S7 PLCs apply to OPC UA and Web API traffic only. They are not enforced on PG/HMI communication, which is governed by PLC protection levels. Siemens is updating its documentation to make that scope clear.

One is a product flaw. The other is a gap between what a setting appears to do and what it enforces. Both teach the same lesson. A password on a device, or a checkbox in an engineering tool, does not prove that every path to that device is protected. When an advisory lands, the owner needs to learn what the control actually enforces, what is still reachable, and what a safe correction requires.

Start With Your Installation

Rockwell rates CVE-2026-12655 at 9.1 under CVSS 3.1. That number describes the flaw in general. It cannot tell you what the flaw means at your site. Three questions get you there.

• Do we run it? Confirm the model, catalog number, and firmware against the advisory. Records drift, so check the devices.
• Who can reach the vulnerable function? For the ArmorBlock, that is the web server. List the networks, workstations, and vendor connections that can reach it.
• What could they change? A hijacked admin account can alter configuration. Know what the process does when that module's I/O misbehaves.

A 9.1 on a module inside a tightly restricted cell can carry less operating risk than a 7.5 on a device reachable from the business network. We made a similar point in From Finding to Funding: leadership can act on a consequence they understand far more readily than on a score.

Walk It Through a Pump Station

Take a hypothetical water utility with a remote booster pump station. An ArmorBlock module carries pump run status and valve position. An S7-1500 runs the control logic, and the engineers marked key setpoints as not writable from HMI/OPC UA/Web API, assuming that locked them down.

Operations and engineering sit down together and work through three items.

• Process consequence. If someone changed the module's configuration or wrote a setpoint over PG/HMI, what happens? Depending on the configuration and independent safeguards, misuse could disrupt pump operation, pressure, or the status operators rely on.
• Required support access. The integrator connects remotely to troubleshoot. Which path does that session use, and does it reach the web server or the PG/HMI channel?
• What the correction takes. Can the firmware update happen remotely, or does it need a truck roll? Does it need bench testing first, vendor coordination, or an outage during low demand? On the Siemens side, tightening protection levels or function rights can break HMI or integrator tools if nobody tests it.

That conversation should end with a plan, a date, and a name next to each step.

Protect the Site While the Fix Waits

Firmware rarely goes in the day an advisory posts. In the meantime:

• Restrict access to the affected function. Limit webserver access to named engineering workstations. For the S7, use protection levels or function rights to control PG/HMI access, as Siemens recommends.
• Tighten remote access. If vendors reach the station through a standing tunnel, this is the moment to broker and time-bound those sessions. Our piece on killing always-on vendor access lays out how.
• Watch for the activity you care about. Where device logs or network visibility support it, alert on webserver logins, password changes, configuration downloads, and writes from unexpected hosts.
• Apply the vendor's guidance. Rockwell points to its security best practices; Siemens to its system manuals.

Give every interim measure an owner and a review date. Reducing exposure does not remove the flaw. Until the corrected release is installed, the module still accepts an unauthenticated password change from anyone who can reach it. Interim protections that nobody owns tend to become permanent ones.

Verify Before You Close It

• Confirm the correction worked. Every affected module runs the vendor-confirmed corrected release, 3.013, or a later release Rockwell confirms addresses the issue. In a planned test window, an unauthorized station attempting a PG/HMI write to a protected S7 is refused.
• Confirm operations still work. SCADA polling, the HMI writes operators rely on, and the integrator's support path all function.
• Update the records. Asset inventory, network drawings, and the change record reflect what was done. This is where solid OT change management pays off.
• Name who accepts the result. Operations signs off on the process. Engineering owns any remaining work, such as a module that has to wait for the next outage.

Do This Now

Pick one current advisory, either of these or one from your own vendors, and write a single page that covers:

1. Affected equipment: model, catalog number, firmware, and location.
2. Access path: every network, account, and vendor connection that can reach the vulnerable function.
3. Operating consequence: what the process does if that function is misused.
4. Immediate protection: what reduces exposure today, with an owner and review date.
5. Permanent correction: the fix, plus any testing, vendor coordination, or outage it needs.
6. Owner: one name accountable for closing it.
7. Acceptance check: the test that proves it worked and who signs off.

If you cannot fill in a line, you have found your next piece of work. Do it once, and the next advisory becomes a routine task instead of a scramble.

Want more practical OT and ICS guidance? Subscribe to The Catch, Koniag Cyber's weekly LinkedIn newsletter on real-world cybersecurity in highly regulated industries.