Human Machine Interface Cybersecurity: Hardware Boundaries for OEM Design

For HMI assemblies, the security discussion should begin while the panel cutout, connector locations, fastening method, and service concept can change—not after the assembly drawing is released.

HMI hardware security at a glance

Front-panel hardware is a defense-in-depth layer; treat each feature as a control with a stated limit, not as proof that the machine is secure.

The hardware boundary covers access and evidence, not the whole HMI

An HMI is the operator-facing system used to observe process status and initiate permitted control actions; the MITRE ATT&CK HMI asset definition includes dedicated panels as well as software interfaces. For hardware design, that system must be divided into physical layers and responsibility owners. Foundational construction vocabulary appears in What Is an HMI Panel? Hardware and OEM Guide.

The manufacturable boundary includes the overlay, display window, touch sensor, membrane switch or flex circuit, indicator windows and light guides, bezel, gasket, fasteners, seams, service openings, and connector routing immediately behind the panel; it may also include a tamper loop or enclosure switch as a supplied interface. The boundary ends where firmware interprets a signal, identity services authenticate a person, the controller authorizes an action, or the OT network transports and records the event.

That distinction prevents inherited-security claims: a lockable cover does not make the USB protocol safe, and a tamper switch does not create an alarm unless a trusted system powers, supervises, records, and responds to it. A green icon does not independently prove a secure state when the application being evaluated also draws the icon.

A secure HMI stack needs explicit handoff points

The front-panel stack should show where access is slowed or exposed and where system controls take over. A useful drawing marks these handoffs instead of labeling the entire assembly “secure.”

Operator / service technician / unauthorized visitor
                         │
                         ▼
┌──────────────────────────────────────────────────────────┐
│ FRONT SURFACE: overlay, touch, keys, indicator windows  │  ← access and presentation
├──────────────────────────────────────────────────────────┤
│ PHYSICAL BOUNDARY: bezel, gasket, seams, fasteners,     │  ← resistance / evidence
│ controlled service cover, tamper label or switch        │
├──────────────────────────────────────────────────────────┤
│ INTERNAL INTERFACE ZONE: USB, SD, Ethernet, JTAG/SWD,   │  ← eliminate, relocate, restrict
│ UART, flex tails, display and touch connectors          │
└──────────────────────────┬───────────────────────────────┘
                           │ documented electrical handoff
                           ▼
┌──────────────────────────────────────────────────────────┐
│ HMI COMPUTE: firmware, authentication, update checks,   │  ← product security owner
│ event generation, indicator source, local storage       │
└──────────────────────────┬───────────────────────────────┘
                           │ documented system handoff
                           ▼
┌──────────────────────────────────────────────────────────┐
│ OT SYSTEM: PLC/SCADA authorization, zones and conduits, │  ← integrator / asset owner
│ protocol security, logs, monitoring, response           │
└──────────────────────────────────────────────────────────┘

The diagram allocates responsibility; it is not a universal architecture. A passive keypad may have no local compute, while a panel PC may combine several boxes. The RFQ should identify who owns each interface, security function, verification record, and field-service instruction.

Physical ports and debug access should follow an eliminate–relocate–restrict hierarchy

The strongest front-panel decision is to avoid exposing an interface that the shipped product does not need. Remove it. NIST SP 800-53 control CM-7 frames this as least functionality: systems should restrict unnecessary functions, ports, protocols, software, and services. NIST's Logical Access to Interfaces catalog likewise includes disabling unnecessary local and network interfaces.

Classify every opening and connector before layout release:

JTAG, SWD, UART, boot-mode straps, recovery buttons, and programming headers deserve the same classification as external USB; hiding a header behind an overlay is concealment, not access control. Moving it behind a locked cabinet can reduce casual access, but the controller owner still has to define readout protection, debug authorization, production lock state, recovery behavior, and the consequences of opening the cabinet.

Mechanical restrictions affect service. A port door consumes bezel area and adds a gasket, hinge, latch, fastener, and instruction burden. A blocker can be lost. Potting or permanent bonding may prevent authorized repair, inspection, and rework. Use these options only when the threat model justifies the lifecycle cost.

Removable media needs a controlled workflow, not just a covered slot

USB drives and SD cards cross both a physical and a logical boundary. NIST SP 800-82 Rev. 3 states that unauthorized removable media should not be permitted on nodes that are part of or connected to OT and allows procedural or technical controls. The front panel can remove the slot, place it inside a locked area, add a controlled cover, or make access visible. It cannot decide whether a device, file, or update is authorized. A cover is not a policy.

If removable media is required, the design package should identify the permitted media type, user role, access location, cover-opening sequence, expected machine state, and restoration check; the product-security owner must define update authenticity, malware handling, data export rules, rollback behavior, and event records. The asset owner must control media custody and inspection. Leaving those items implicit creates a service path that bypasses the normal network boundary.

NIST also notes that a locked cabinet can compensate when a legacy USB port cannot be logically disabled, while warning that wireless or network paths may bypass that physical control. The engineering implication is direct: document every parallel path. Securing the front opening while leaving an internal Ethernet jack, wireless maintenance mode, or exposed rear connector unmanaged does not close the boundary.

Tamper evidence, resistance, and detection are different controls

Tamper evidence shows that access may have occurred. Tamper resistance increases the work, tools, time, or damage required to gain access. Tamper detection produces a signal. Evidence is not prevention. These functions can coexist, but one term must not replace another.

The UK National Protective Security Authority describes tamper indication as physical evidence of unauthorized access and ties detection to an alert and response; for an OEM panel, the drawing should identify the protected seam, application surface, inspection view, allowable service removal, and replacement process. Validation must use production-intent surfaces after the specified environmental and cleaning exposures; appearance on an untreated coupon is not enough.

Avoid “tamper-proof.” Even a well-designed feature covers only stated paths and attack conditions. NIST SP 800-53 PE-3 distinguishes lockable casings from anti-tamper technologies and allows organizations to select detection, prevention, or both. The OEM must therefore define the adversary capability, allowed tools, access time, acceptable evidence, and required post-event action before choosing construction.

A trusted indicator needs a trusted source, path, and failure definition

A security indicator is credible only when its claim is narrow and its signal path is documented. NIST's Cybersecurity State Awareness catalog covers state data, event monitoring, alerts, logs, and physical indicators in context. It does not imply that any illuminated icon is trustworthy.

For each indicator, define the state asserted, source component, electrical path, startup and communication-loss behavior, stale-data timeout, lamp or pixel test, and reaction to an open or short circuit. Test the failure state. A dedicated LED driven by a supervised controller output can provide a more independent path than an icon rendered by the application under evaluation. Whether that path is sufficiently trusted remains a system risk decision.

Physical key switches, guarded buttons, and badge-reader cutouts follow the same rule. Hardware supplies an input and may constrain who can physically actuate it. The controller must still authenticate the credential where applicable, authorize the requested action, apply machine-state interlocks, and record the event. A key possession claim is not automatically a user identity claim.

Human machine interface cybersecurity hands off to component and system security

IEC 62443 makes the split explicit. Scope always matters. IEC 62443-4-2 defines technical security requirements for IACS components across seven foundational requirements, while IEC 62443-3-3 addresses control-system requirements and security levels. A bezel, overlay, seal, or port cover may support that design, but it does not inherit the compliance status of a controller, cryptographic module, or completed IACS.

The same caution applies to adjacent ratings. IEC 60529 classifies enclosure protection using the IP Code; IEC 62262 addresses protection against external mechanical impacts using the IK Code. Those tests can support environmental reliability and physical robustness. They do not verify authentication, interface restriction, tamper response, secure boot, or network segmentation. FIPS 140-3 is similarly bounded to cryptographic modules, not the complete HMI panel.

Use Industrial HMI Standards and Hardware Compliance to organize broader hardware compliance inputs, and Industrial HMI Communication Protocols and Hardware Interfaces to allocate connector and protocol responsibilities. PLC/SCADA programming remains outside JASPER's manufacturing scope.

Choose controls from the threat path, not from a feature list

An engineering decision table should connect each credible action to a hardware measure, a system control, and an acknowledged limit.

Panel-level controls are not suitable when they obstruct emergency operation, create unacceptable cleanability or ingress risks, prevent required repair, or encourage technicians to defeat the feature. They are also inadequate when the dominant path is remote, wireless, supply-chain, firmware, credential, or network based. In those cases the hardware may still support defense in depth, but it cannot be the primary control.

Validation must test the boundary and its handoffs

Security-related hardware validation should use production-intent parts, assembly processes, drawings, and service actions. Add the work to the HMI Panel Assembly Design Checklist and align it with testing and validation planning.

Prototype reviews should include the actual service technician motions and inspection sight lines, not only CAD clearance. Use prototyping and sample approval to resolve access, sealing, visibility, and replacement issues before production tooling locks the geometry.

Put these security-boundary inputs in the drawing and RFQ

Provide enough information for the HMI manufacturer to build and verify the physical boundary without asking it to infer the system threat model.

• Display active area, overall panel envelope, cutout, bezel, stack thickness, and rear-clearance limits.
• Front-panel drawing with every operator, maintenance, factory, reserved, and unused interface classified.
• Interface stack: display, touch, switch circuit, indicators, controller, flex tails, connectors, and enclosure handoffs.
• Required service operations, authorized access method, replaceable parts, and restoration evidence.
• Protected seams, fasteners, labels, switches, conductive loops, indicator windows, and inspection locations.
• Operating and storage environment, cleaning agents, ingress target, impact target, and environmental conditioning required before security-feature checks.
• Threat assumptions, allowed tools, intended evidence or delay, alarm owner, response owner, and acceptance criteria.
• Prototype quantity, validation responsibilities, change-control records, and annual volume.

Use this package to send drawings for engineering review. JASPER can review the manufacturable panel boundary—display size, front-panel drawing, interface stack, environment, and annual volume—while the OEM retains responsibility for controller, PLC/SCADA, identity, network, and incident-response security. When the boundary and validation inputs are defined, request an engineering quote.

Frequently Asked Questions

What can HMI hardware secure?

HMI hardware can remove or restrict physical access paths, place service interfaces behind controlled barriers, provide visible tamper evidence, carry a tamper-sensor signal, and present a dedicated indicator or keyed input. It cannot authenticate users, authorize PLC commands, validate firmware, encrypt communications, or create trustworthy logs without controller and system controls.

Should an OEM remove external USB ports from an HMI?

Remove the external opening when USB is not required in normal or authorized service. If USB is necessary, classify its users and purpose, place it behind an appropriate controlled access feature, and define the service state and restoration check. Logical disablement, media authorization, scanning, update validation, and logging still belong to the product and OT system.

How should JTAG, SWD, UART, and programming headers be handled in production?

Treat each debug interface as factory-only, authorized-maintenance, or required-use access. Factory-only access usually favors internal test pads or an unpopulated production footprint. If field access remains, document the enclosure path and service procedure. The electronics and firmware owners must define debug locks, readout protection, recovery authorization, and production-state verification.

Is tamper-evident design the same as tamper-resistant design?

No. Tamper evidence reveals a defined physical change after access. Tamper resistance makes a defined access path harder to open under stated conditions. Tamper detection generates a signal, and tamper response acts on that signal. An OEM may combine them, but each needs separate acceptance criteria, validation evidence, and an assigned response owner.

Does an IP or IK rating mean an HMI is cybersecure?

No. IEC 60529 IP ratings classify enclosure protection against ingress, while IEC 62262 IK ratings address external mechanical impact protection. Either can support a durable physical design, but neither verifies authentication, port restriction, firmware integrity, tamper response, secure communications, logging, or network segmentation.

Can a physical key switch authenticate an HMI operator?

A key switch proves only that the switch was actuated with a compatible key or mechanism under the defined construction. It does not necessarily identify the person holding it. The controller or identity system must authorize the requested action, enforce role and machine-state rules, and record the event when accountability is required.

What makes an HMI security indicator trustworthy?

A trustworthy indicator has a narrowly defined meaning, an identified state source, a documented signal path, freshness and failure behavior, and a validation method. A separate, supervised indicator path may offer stronger independence than an application-rendered icon. The system design must still protect the state source, handle faults, restrict access, and correlate the indication with logs.

What cybersecurity information belongs in an HMI assembly RFQ?

Include the panel drawing, interface inventory and classifications, protected seams, service workflow, threat assumptions, allowed tools, expected tamper evidence or delay, indicator source and state table, environment and cleaning exposures, validation methods, acceptance criteria, responsibility matrix, prototype plan, and annual volume. Keep controller, PLC/SCADA, network, identity, and response requirements explicitly assigned.

References

1. MITRE ATT&CK, Human-Machine Interface (HMI), Asset A0002.
2. National Institute of Standards and Technology, NIST SP 800-82 Rev. 3: Guide to Operational Technology Security, September 2023.
3. National Institute of Standards and Technology, NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline, May 2020.
4. National Institute of Standards and Technology, IoT Cybersecurity Capabilities Catalog: Logical Access to Interfaces.
5. National Institute of Standards and Technology, IoT Cybersecurity Capabilities Catalog: Cybersecurity State Awareness.
6. National Institute of Standards and Technology, NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations.
7. International Electrotechnical Commission, IEC 62443-4-2:2019, Technical security requirements for IACS components.
8. International Electrotechnical Commission, IEC 62443-3-3:2013, System security requirements and security levels.
9. International Electrotechnical Commission, IEC 60529 consolidated edition, Degrees of protection provided by enclosures (IP Code).
10. International Electrotechnical Commission, IEC 62262:2002 + AMD1:2021, External mechanical impact protection (IK Code).
11. UK National Protective Security Authority, Tamper Indication.
12. Cybersecurity and Infrastructure Security Agency, ICSA-20-014-04: Siemens SINAMICS PERFECT HARMONY GH180, January 14, 2020.
13. National Institute of Standards and Technology, FIPS 140-3: Security Requirements for Cryptographic Modules, March 2019.

This engineering guide was prepared by JASPER, a custom HMI assembly manufacturer. The technical boundaries apply to OEM HMI designs from any qualified manufacturer; the JASPER links identify optional manufacturing and review services, not system-security certification.