Skip to main content

2.4.8 Authentication & Authorisation

This section's intended audience is for those personnel who are responsible for the security of the IoT systems interfaces and authentication processes. Guidance is available from the IoTSF Best Practice Guides [ref 44]1 regarding Credential Management (part F).

Req NoRequirementCompliance Class And ApplicabilityPrimary KeywordSecondary Keyword
2.4.8.1The product contains a unique and tamper-resistant device identifier. E.g.: the chip serial number or other unique silicon identifier, for example to bind code and data to a specific device hardware. This is to mitigate threats from cloning and also to ensure authentication may be done assuredly using the device identifier e.g. using a device certificate containing the device identifier.Mandatory for all classesSystemHardware
2.4.8.2Where the product has a secure source of time there is a method of validating its integrity.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.3Where a user interface password is used for login authentication, the factory issued or reset password is randomly unique for every device in the product family. If a password-less authentication is used the same principles of uniqueness apply.Mandatory for all classesSystemSoftware
2.4.8.4The product does not accept the use of null or blank passwords.Mandatory for all classesSystemSoftware
2.4.8.5The product will not allow new passwords containing the user account name with which the user account is associated.Mandatory for all classesSystemSoftware
2.4.8.6Password entry follows industry standard practice on password length, characters from the groupings and special characters.Mandatory for all classesSystemSoftware
2.4.8.7The product has defence against brute force repeated login attempts, such as exponentially increasing retry attempt delays.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.8The product securely stores any passwords using an industry standard cryptographic algorithm, compliant with an industry standard.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.9The product supports access control measures to the root/highest privilege account to restrict access to sensitive information or system processes.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.10The access control privileges are defined, justified and documented.Mandatory for Class 1 and aboveBusinessProcess
2.4.8.11The product only allows controlled user account access; access using anonymous or guest user accounts is not supported without justification.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.12The product allows the factory issued or OEM login accounts to be disabled or erased or renamed when installed or commissioned.Advisory for all classesSystemSoftware
2.4.8.13The product supports having any or all of the factory default user login passwords altered when installed or commissioned.Mandatory for all classesBusinessProcess
2.4.8.14If the product has a password recovery or reset mechanism, an assessment has been made to confirm that this mechanism cannot readily be abused by an unauthorised party.Mandatory for Class 1 and aboveBusinessProcess
2.4.8.15Where passwords are entered on a user interface, the actual pass phrase is obscured by default.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.16The product allows an authorised and complete factory reset of all of the device’s authorisation information.Advisory for all classesSystemSoftware
2.4.8.17Where the product has the ability to remotely recover from attack, it should rely on a known good state, to enable safe recovery and updating of the device, but should limit access to sensitive assets until the devices is in a known secure condition.Mandatory for Class 1 and aboveSystemSoftware
2.4.8.18Devices are provided with a RoT-backed unique authenticable logical identity.Mandatory for Class 1 and aboveSystemSoftware

Footnotes​

  1. Enhanced Privacy standard for Anonymous Signatures ISO/IEC20008 [https://www.iso.org/standard/57018.html] ↩