Does IEC 62443 require us to obfuscate our HMI JavaScript?
No. Like every other standard covered on this site, it does not name the technique at all. The 62443 series asks about a development process, a system architecture and a set of technical capabilities: how you identify and authenticate users, how you control what they may do, how you protect integrity, how you handle events, how you keep the system available. The form your source takes is not a subject of the standard. Where protection can contribute is indirect and worth stating precisely: it supports the integrity and tamper-evidence story for code that leaves your premises, and it supports nothing at all in the authentication or use-control requirements, which are met by the system rather than by the browser.
What actually changes when the standard is 62443 rather than an IT one?
The priority order inverts, and that single fact changes which options are safe. Ordinary information security ranks confidentiality first. Operational technology ranks safety and availability first, because the system is controlling a physical process and stopping it has consequences that a data breach does not. Once availability outranks confidentiality, any control that can fail closed on an operator console has to be justified against the harm of that console going blank during an upset. That reasoning removes most of the runtime defenses from consideration on an HMI, and it is the opposite of the conclusion you would reach on a public web page.
Why are runtime guards a poor fit for an operator console?
Because their failure behaviour is designed for a web page, where failing closed is cautious, and on a control system it is the hazard. Every one of the failure actions this engine offers ends by throwing, with a single exception. Blanking the page needs a document element, reloading needs a location object, redirecting needs a location, and all of them throw as well. Only the degrade action, which raises an event and sets a flag for your own code to react to, does not. On an operator screen the difference between raising a flag your application handles and blanking the display is the difference between a logged anomaly and an operator who has lost their process view. If a guard is used here at all, degrade is the only defensible action.
Our HMI is reached by IP address on an isolated network. Does the domain lock work?
It works in the literal sense and it is usually the wrong control. The guard reads the browser's hostname and compares it against your allowlist, so on a system reached at an address rather than a name, the value it compares is that address string, and your allowlist has to contain every address any client might use. That list changes whenever addressing changes, which on a control network is an ordinary maintenance event rather than a rare one. Worse, if the interface is opened in a context with no meaningful hostname, such as a local file or an embedded panel viewer, the guard treats the empty value as failure and fires the failure action before consulting your allowlist at all. On an air-gapped system the control that matters is the network segmentation you already have, not a check running inside the browser.
Which part of 62443 does a protected build actually help with?
The lifecycle part, and mostly through record-keeping rather than through the transformation. A secure development lifecycle asks you to define your process, threat model the product, verify what you built, and be able to service it after delivery. A build that is reproducible from a recorded seed, that emits a manifest of source and output hashes per file, and whose symbol map is archived against the released version, produces exactly the evidence that lifecycle wants: this artifact came from this source, here is how to reproduce it, and here is how to diagnose a report from the field. That is a real contribution and it is worth claiming. Transforming the identifiers is not.
How do we keep an obfuscated build serviceable across a long support life?
By archiving the inputs, not just the outputs, and by treating that archive as part of the deliverable. Industrial products are supported for a decade or more, often by engineers who were not present when the code was written, on installed systems that are updated rarely and reluctantly. If a fault report arrives against a release from six years ago, you need the exact source, the exact configuration including the seed, the symbol map, and a way to rebuild that release and confirm you reproduced it. Without those, protection has made a long-lived product harder to support, which is a genuine engineering cost rather than a theoretical one. Set the retention policy to the support life of the product, not to the retention default of your build system.
Does protection interfere with the software inventory we have to provide?
It should not, provided the inventory is produced from the source side of the build rather than from the shipped artifact. Composition analysis works by recognising known code, and transformed output is much harder to recognise, so a scanner pointed at a protected bundle will under-report. Generate the component inventory from your dependency manifests and lock files before the protection step, attach it to the release, and keep the two in the same record. This is the same rule that applies to every scanner: everything that works by reading code runs before the step that makes code hard to read.
Where should the logic that matters actually live?
On the controller and the server, which is also what the architecture the standard describes already assumes. An HMI is a view onto a process, and the authority for interlocks, permissive conditions, setpoint limits and command authorisation belongs to the equipment that enforces them. A limit checked only in the browser is a limit an operator or anyone with access to that workstation can remove, and no build setting alters where the decision is being made. Treating the panel as a renderer, with every consequential check enforced by the controller or the supervisory service, is both better engineering and a far easier position to defend in an assessment.
Can protecting the HMI code help against an attacker who is already on the control network?
Marginally, and it is important not to oversell it. Someone with a foothold on the network is in a position to observe traffic, replay commands and interact with services directly, none of which involves reading your JavaScript. What protection does address is the narrower case of a copied panel: an integrator, a subcontractor or a customer who takes the interface you delivered and reuses or modifies it. That is a commercial and integrity concern rather than an intrusion one, and it is where a watermark that attributes a copy to a release earns its place. Detection and segmentation address the intruder; protection addresses the copy.
What should we put in the assessment file about this?
State the position plainly rather than implying more. A defensible entry says what the protection step is, that it is applied to the operator interface bundle, that it is not relied upon as a security control for any requirement in the standard, and that the security requirements are met by the system controls you list separately. Then attach the evidence that is genuinely yours: the reproducible build record, the component inventory generated pre-transformation, the archived symbol map and retention period, and the rationale for whichever runtime options you enabled or deliberately left off. An assessor is far more comfortable with a documented decision to leave a guard disabled on availability grounds than with an undocumented one to switch it on.