Hot take: the “web HMI = more insecure” claim is usually an architecture problem, not a technology problem.

Browser-based HMIs don’t magically create new risk. They often expose the risk you already had in thick clients: weak identity, flat networks, slow patching, and unclear ownership.

If you’re evaluating a web HMI, don’t debate web vs. native. Ask what you are actually deploying.

Key design choices that determine real-world risk:

1) Identity and access
– Central IdP, MFA for remote access
– Role-based access, least privilege
– Separate operator vs engineer privileges

2) Session handling
– Short-lived tokens, rotation, timeouts
– No shared accounts, no “always logged in” kiosks without compensating controls

3) Network exposure
– No direct internet path to OT
– DMZ, reverse proxy, allow-listing
– Remote access via VPN/ZTNA with device posture

4) Update and vulnerability cadence
– Who patches what, and how fast
– SBOM, dependency scanning, signed builds
– Documented rollback and maintenance windows

5) Observability
– Central logs, auth events, configuration change trails
– Alerting that someone actually reads

Modernization is not the risky part. Unclear boundaries are.

If you want a quick gut check: show me your auth model, network zones, and update process and I’ll show you your risk.

What’s the hardest part for your team today: identity, network segmentation, or patching?