Executive Summary
A BIOS vendor test key is present in the UEFI Secure Boot key database of several Siemens SIMATIC IPC models, allowing a local attacker with physical or administrative access to boot an operating system or UEFI application signed with that key while Secure Boot remains enabled. On an industrial PC that serves as an HMI, SCADA node, batch controller, or engineering workstation, this turns the boot trust anchor into a decoration and opens the door to persistent, firmware-level compromise.
Technical Exposure Breakdown
The defect is not a parsing bug or a memory corruption flaw. It is a configuration error in the platform's root of trust. UEFI Secure Boot works by validating that every bootloader and option ROM is signed by a key in the authorized signature database (db). The design assumption is that only trusted production keys live in that database. In this case a vendor test key, intended for engineering and manufacturing validation, was shipped in the production image's key store.
The consequence is direct. Any attacker who can present a bootloader or UEFI application signed with that test key passes signature validation. Secure Boot reports itself as enabled and healthy, yet the chain of trust has a side door. The grounding data identifies the affected firmware for the SIMATIC IPC227G, IPC277G, IPC327G, and IPC377G as versions before V28.01.15. The advisory also references the SIMATIC IPC BX-21A and IPC RW-543A. Assigned CVSS is 7.7.
The attack requires local physical or administrative access. That requirement is what keeps this below critical scoring, but in OT it is a weak boundary. Industrial PCs sit on plant floors, in substations, in unmanned remote enclosures, and in control rooms with shared operator logins and cached domain credentials. The administrative-access path is often a password on a sticky note or a technician's laptop. The physical path is often an unlocked cabinet. Neither condition is theoretical in a real plant.
OT Impact and Compliance Risk
Defeating Secure Boot allows a bootkit to load before the operating system, before endpoint protection, and before any integrity monitoring the asset owner deployed. The attacker gains confidentiality, integrity, and availability loss at a layer that survives OS reinstall and most forensic triage. On a device driving a physical process, that means an operator can be shown trusted HMI values while the underlying setpoints, interlocks, or logging are manipulated beneath the view layer.
For NERC CIP environments, this intersects CIP-010 configuration and integrity monitoring and CIP-005 and CIP-007 system security controls, because the baseline you are monitoring can no longer be trusted below the OS. For IEC 62443, this is a failure of the hardware root-of-trust assumptions behind SL-2 and higher system requirements, specifically the component security requirements for use of cryptography and secure boot integrity. For pipeline and water operators under TSA SD-02C and AWIA 2018 obligations, a compromised industrial PC that cannot be trusted at the firmware level undermines the integrity of the monitoring and control architecture those programs are built to protect.
Compensating Controls
Patch status for these models is not confirmed in our source data, so treat remediation as a staged process rather than a single firmware flash. Do not active-scan these devices to confirm versions. Credentialed banner checks and probing against an industrial PC in a running process cell can cause instability, and this flaw is not detectable over the network in any case.
- Physical lockdown first. This is a local-access vulnerability. Enclosure locks, cabinet keys, and door sensors on IPC locations are the most immediate mitigation while firmware is validated.
- Harden the boot path. Set a BIOS or UEFI setup password, disable boot from USB and network where operationally possible, and enable boot order locking to deny an attacker a trivial path to present signed test-key payloads.
- Remove credential reuse. Eliminate shared local administrator accounts and cached domain credentials on these IPCs, since the administrative path is an equal enabler to the physical one.
- Monitor for boot anomalies. Where measured boot or TPM attestation is available, record and alert on PCR changes. A Suricata rule will not catch this, but asset-management logging that flags unexpected firmware version regressions or boot configuration changes gives you a detection surface.
- Validate before patching. When Siemens confirms a fixed firmware, stage it in a test cell. Firmware updates on live process controllers carry their own availability risk.
BreachSpider tracks CVE-2026-72895 and the associated Siemens SIMATIC IPC firmware advisories, and monitors for patch availability and exploitation signals across the industrial PC fleet.