Scroll to discover
Watch a Demo
Skip to content

IEC 62443 Example 6 - Hardware Security Requirements

62443 4-2 contains specific guidance for various component types. In this exercise a 62443 EDR or NDR component could be selected and secured according to the design.

Example xml: 


The main focus of this exercise is to identify and evaluate hardware security countermeasures principally related to the 2021 CWE Most Important Hardware Weaknesses. Threats and controls will be derived and manually selected as per a typical hardware component arrangement.

62443 4-2 contains specific guidance for various component types. In this exercise a 62443 EDR or NDR component could be selected and secured according to the design.

Example Scenario:

Different hardware types are used as the building blocks for computers, control systems, network devices, medical IoT/Consumer IoT/Industrial IoT devices. Hardware includes modules such as motherboards, programmable logic controllers, microchips, memory (Random Access/Read Only), storage (optical/solid state/magnetic), communications ports, maintenance ports (JTAG) etc. Generally such hardware is selected appropriately and interconnected to form a complete functional system or device. Firmware and software is installed on the hardware to control them independently and/or to allow for a unified functionality between each component, thus forming a purpose designed and built system.  

Hardware is also susceptible to sophisticated attacks initiated through vulnerable code or component features. Attacks can be launched taking advantage of shared resources without proper isolation, improper access control via a test interface or firmware that does not have an option to be updated. Securing each independent system component should be considered as important as securing the software that is embedded on them.

The figure below shows the connection and data flow details of a typical JTAG architecture. JTAG ports have standard security modes, some examples are as follows:

  • No debug; Maximum Security
  • Secure Debug; High Security
  • Debug Enabled; Low Security

JTAG Architecture

JTAG Architecture; Connections, Data Flow & registers



Identify hardware related controls and associate applicable CWE’s for greater visibility of weaknesses, vulnerabilities and relevant mitigating controls.


  1. Select the required SL Trustzone: iec62443-sl2
  2. From the 62443 > CWE mapping identify that an EDR or NDR component has a Hardware related CWE, CWE-1191: On-Chip Debug and Test Interface With Improper Access Control, the Control requirement for mitigation of the CWE corresponds to 62443 4-1 CR 2.13 – Use of physical diagnostic and test interfaces
  3. Select and place the iec62443 4-2 EDR or NDR component in the SL-2 Trustzone.
  4. Click update threat model, once the threat model has been updated, the threats and countermeasures will be automatically generated by the internal IriusRisk rules engine. Then move to the threats & countermeasures tabs to review the applicable threats/controls for the subject device.
  5. Select appropriate CWE’s related to hardware design according to the 2021 CWE Most Important Hardware Weaknesses and apply suitable controls from 62443 4-1. Typical threats and controls will be imported according to the selected CWE. Another example CWE is CWE-1277: Firmware Not Updateable, however, this CWE is not yet associated with a control.
  6. Select the appropriate control from the threat list. E.g. 62443 4-1 EDR or NDR 3.10 – Support for updates and add the weakness to the threat to be considered as a hardware applicable association.

    Note: this is an example case and other CWE’s will have to be appropriately selected and linked to a 62443 3-3 & 4-2 Control Requirements.

    Graphical user interface, application

Description automatically generated
    Weakness selection table for addition to a specific threat

  7. Identified controls EDR 2.13 & 3.10 can be set to required to add visibility of the hardware related controls requirements.

    A picture containing graphical user interface

Description automatically generated
  8. To provide clarity for the EDR 3.10 Threat,  CAPEC-682: Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities is included as a new threat/attack vector in the Use Case.

    A picture containing text

Description automatically generated

    Note: if required, EDR 3.10 Control can be added as a countermeasure on the new threat.

    Graphical user interface

Description automatically generated

Basic Architecture:

A close-up of a circuit board

Threat Model Output:

At SL-2, there are now two threats corresponding to hardware weaknesses, these are shown in the following table:



Inherent Risk

STRIDE Category Flow (Manual origin)


An adversary introduces malware onto the asset via a physical diagnostic or test interface


Tampering > Spoofing (If authentication/authorisation bypassed)


Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities (As per CAPEC-682)


Tampering >
Elevation of Privileges > (If authentication bypassed to root)
Denial of Service (If device used to launch a DoS or DDoS attack)

Example fundamental hardware weakness corresponding to the identified threats:

Considering the original CWE example CWE-1191, this example weakness is related to improper access control of the on-chip Debug and Test Interface. In this example attack scenario the chip does not verify if the user is authorised to access internal registers through the debug/test interface. This weakness could potentially allow an adversary to modify a critical hardware function or access sensitive information like registers containing secrets or keys.

Preventative countermeasure overview:

Two required controls are associated with the exposed vulnerabilities. The controls corresponding to the threats are shown in the following table:

Threat name

Inh. risk


Control name


Res. risk

Proj. risk

Use case: SL2 - Common - 4-2 - EDR2.13

An adversary introduces malware onto the asset via a physical diagnostic or test interface



Embedded devices shall protect against unauthorized use of the physical factory diagnostic and test interface(s)



Very Low

Use case: SL2 - Common - 4-2 - EDR3.10

Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities



The embedded device shall support the ability to be updated and upgraded





Update authenticity and integrity




In IriusRisk, these countermeasures are aligned to IEC 62443 4-2 and include a detailed description of how they should be implemented as well as the implementation status. This example pays special attention to the requirements for hardware threats, weaknesses and corresponding controls for mitigation. This supports the hardware designer, developer or engineer with the implementation of each individual security control down to a component or product level. Identifying threats and weaknesses early on in the design phase will produce hardware with secure functions, code and attributes and hence, a secure by design product even before all the components are unified to form a complete system.


This example shows how IriusRisk can be used to determine what the specific countermeasures for hardware should be; and the importance of taking it into consideration during the design, threat model or risk assessment phases.    

What next?

Take a look at our Operational Technology Landing Page for further information and resources.