Skip to main content
Version: 4.0

2.4.4 Device Hardware

This section’s intended audience is those personnel who are responsible for hardware and mechanical quality. Guidance is available from the IoTSF (IOTSF.SD-BPG) regarding Physical Security (part B) Device Secure Boot (part C) and Secure Operating Systems (part D).

Req NoRequirementPrimary KeywordSecondary KeywordCompliance Class And Applicability
2.4.4.1The product’s processor system has an irrevocable hardware Secure Boot process.SystemHardwareMandatory for all classes
2.4.4.2The product’s processor system has an irrevocable “Trusted Root Hardware Secure Boot”.SystemHardwareMandatory for Class 2 and above
2.4.4.3The product’s processor boot process provides an appropriate level of trustworthiness by using a hardware root of trust (RoT) to verify trusted boot or measured boot methods. This may be referred to as 'secure boot', but absolute security cannot be assured.SystemHardwareMandatory for Class 3 and above
2.4.4.4The Secure Boot process is enabled by default.SystemHardwareMandatory for all classes
2.4.4.5Any debug interface only communicates with authorised and authenticated entities on the production devices. (Note: Requirements 2.4.4.6 - 8 should be considered as advisory) The functionality of any interface should be minimised to its essential task(s).SystemHardware SoftwareMandatory for Class 1 and above
2.4.4.6The hardware incorporates protection against tampering and this has been enabled. The level of tamper protection must be determined by the risk assessment.SystemHardwareMandatory for Class 1 and above
2.4.4.7The hardware incorporates physical, electrical and logical protection against tampering to reduce the attack surface. The level of protection must be determined by the risk assessment.SystemHardware PhysicalMandatory for Class 2 and above
2.4.4.8The hardware incorporates physical, electrical & logical protection against reverse engineering. The level of protection must be determined by the risk assessment.SystemHardwareMandatory for Class 3 and above
2.4.4.9All communications port(s) which are not used as part of the product’s normal operation are not physically accessible or only communicate with authorised and authenticated entities.SystemHardware Physical SoftwareMandatory for Class 1 and above
2.4.4.10All the product’s development test points are securely disabled or removed wherever possible in production devices.SystemHardware PhysicalMandatory for Class 2 and above
2.4.4.11Tamper Evident measures have been used to identify any interference to the assembly to the end user.SystemHardwareMandatory for Class 2 and above
2.4.4.12Intentionally left blank to maintain requirement numbering-
2.4.4.13In production devices the microcontroller/ microprocessor(s) shall not allow the firmware to be read out of the products non-volatile [FLASH] memory. Where a separate non-volatile memory device is used the contents shall be encrypted.SystemHardwareMandatory for Class 1 and above
2.4.4.14Where the product's credential/key storage is external to its processor, the storage and processor shall be cryptographically paired to prevent the credential/key storage being used by unauthorised software.SystemHardwareMandatory for Class 1 and above
2.4.4.15Where a production device has a CPU watchdog, it is enabled and will reset the device in the event of any unauthorised attempts to pause or suspend the CPU’s execution.SystemHardwareMandatory for Class 1 and above
2.4.4.16Where the product has a hardware source for generating true random numbers, it is used for all relevant cryptographic operations including nonce, initialisation vector and key generation algorithms.SystemHardware SoftwareMandatory for Class 1 and above
2.4.4.17The product shall have a hardware source for generating true random numbers.SystemHardwareMandatory for Class 2 and above