Verified Files, Real Risk: OT File Integrity Must Hold Through Deployment
According to OPSWAT, scanning a file once at the OT boundary is not enough: integrity must be verified all the way to the PLC or HMI. Beyond the product itself, it raises a useful audit question for multi-site plants.
On November 9, 2026, IIoT World published an article marked "Sponsored by Opswat" that draws on a post from OPSWAT's blog. Its thesis: checking files once at the entry point to the OT network leaves the most sensitive stretch uncovered, the one between approval and installation on a PLC or HMI. Because this is commercial content, with no incident data, statistics or independent validation, it should be read as a vendor's argument, not as market evidence.
The gap between scan and deploy
In practice, at many industrial sites vendor firmware, contractor patches and configuration updates are scanned at the point of entry and the approval is logged. From then on, however, security teams lose visibility until the file reaches its destination.
If the file is modified in the meantime, whether by mistake or through tampering, it is indistinguishable from an intact one: the scan report remains valid and the approval stays on record. A scan shows that the file was clean at a given moment, not that it is the same file at the moment it is installed.
Why legacy systems cannot close it alone
Older PLCs, HMIs and engineering workstations cannot run EDR agents and cannot verify that an incoming file matches the approved one. Once the device is connected, files are accessible by default. The article sums it up this way:
Relying on every operator to follow every step at every site is a process assumption, not a security control.
The proposed solution
OPSWAT proposes MetaDefender Drive with Smart Touch and Secure File Storage. Files copied from vendor or contractor devices stay isolated until they pass verification at a MetaDefender Kiosk. If a verified file is modified before deployment, it is automatically blocked and hidden until it is verified again. The model thus shifts from "scan once and deploy" to "verify continuously through deployment." The product's claimed performance has not been independently verified.
Other requirements listed in the article:
- scan contractor and supply chain devices before they connect to OT;
- apply consistent inspection policies across distributed sites, with centralized management;
- handle secure firmware distribution in air-gapped environments;
- maintain centralized visibility and audit-ready logs.
Key takeaways
The risk is concentrated in the handoff between approval and deployment. For multi-site manufacturers, especially in regulated sectors where you must show that a file stayed unchanged from approval to installation, this is a concrete audit question: today, at each of our sites, how do we prove that the installed file is the approved one?
The principle does not depend on any single product: integrity controls, such as hash or signature verification at deployment time, enforced by the system rather than left to individual operators' discipline. A pragmatic starting point is to record the file's hash at approval, store it separately from the transfer media, and compare it before installation, then assess whether dedicated tools, from this vendor or others, are needed to make the process uniformly enforceable.