Device security principles for manufacturers

This guideline applies to all devices.

User authentication mechanisms ensure that only an authorised user can gain access to a device’s data and functionality. Authentication mechanisms vary but may include username and password, biometrics or hardware keys. They must be appropriately robust for the device and the level of access required. For example, a stronger form of authentication than a password may be required for an administrator account. The NCSC has guidance for organisations on this topic, including on Privileged Access Workstations (PAWs).

Some devices, such as public information kiosks or smart building technology, may not require all users to authenticate themselves before access. But administrators may still need to authenticate themselves to the device to enrol the device on a network, or to configure it.

Example: A user signing in to a laptop is authenticated with biometrics, a password or a PIN.

If the device can’t authenticate the user, an attacker may be able to access the device and its data and functionality. The risk is heightened if the device is exposed to remote connections. A device that is only accessible to those who need to use it mitigates this risk to some extent. But without user authentication, it isn’t possible to record who is using the device, or to give different users different levels of privilege.

References:

• MITRE: T1078 Valid Account
• NCSC Zero trust architecture principle 2 and principle 5
• NIST SP 800-213A: Device Configuration − Logical Access Privilege Configuration
• NIST SP 800-213A: Logical Access to Interfaces − Authorization Support
• NIST SP 800-213A: Logical Access to Interfaces − Authentication and Identity Management
• NCSC Secure system administration guidance

This guideline applies to all devices that can communicate sensitive or user data.

If a device is communicating sensitive or important data to another device or service, or communicating over a network, it's important that it can establish the identity of the other device, service or network. An attacker could masquerade as a legitimate device and intercept or manipulate the data to access sensitive information or gain control of device functionality.

A suitable authentication method defends against such attacks, and contributes to device defence-in-depth.

Example: A phone communicates to a mobile device management server using TLS, in line with NCSC guidance.

In some cases a device may need to authenticate itself to a communicating party. A device that can’t authenticate itself might be untrusted by other devices, services and networks, and consequently be denied access.

Example: A device supports 802.1X authentication for access to networks.

Without authentication between two communicating parties, an attacker may be able to set up an adversary-in-the-middle (AiTM) attack, tricking both parties to think that the attacker is the other partner. A solution using Public Key Infrastructure (PKI) may be preferable to pairwise authentication with symmetric keys, as it's usually more scalable as the number of devices grows.

References:

• MITRE T1557 Adversary-in-the-Middle
• NCSC Zero trust architecture principle 2 and principle 5
• Using TLS to protect data
• IEEE 802.11X
• NIST SP 800-213A: Device Identification − Device Authentication Support
• NIST SP 800-213A: Device Configuration − Logical Access Privilege Configuration
• NIST SP 800-213A: Logical Access to Interfaces

- Authentication Support
- Authentication Configuration
- External Connections
 

• NIST SP 800-213A: Device Security − Secure Communication

This guideline applies to all devices.

When shipped from the factory, devices often have pre-installed or default credentials common across multiple devices. Once an attacker discovers these credentials, they can be reused against devices running the same default configuration or services, making it trivial for an attacker to authenticate to them. It's therefore important that when a user sets up a new device, the credentials are strong and unique to the user. This can be achieved with user-specified passwords, or randomly generated unique passwords.

Example: For each service or account on a device, the user specifies the passwords on initial device setup. When passwords aren’t specified, the device generates unique passwords.

References:

• EN 303 645 (5.1.1)
• MITRE: T1078 Valid Accounts
• MITRE: T1110 Brute Force and .004 Credential Stuffing
• NCSC Zero trust architecture principle 2
• NIST SP 800-213A: Data Protection − Cryptographic Key Management

This guideline applies to devices that use pre-installed credentials that are unique per device.

When users don’t specify their own passwords, it's recommended that the device randomly generates unique credentials (such as a password, PIN or cryptographic key) at device setup. It's important that credentials are strong, not easily guessable or vulnerable to brute-force attacks. Software is freely available to help attackers guess passwords and if they have low entropy or follow a pattern, they may be compromised.

If an attacker successfully guesses a password, they may be able to take on the role and privilege level of the account or service. If the password is a serial number or another physically available attribute, an attacker with physical access may easily guess it and gain access.

As alternative mitigations, if a device can’t securely generate unique passwords, it must be enforced that the user changes passwords on first use and that remote interaction with the device isn’t possible until setup is complete.

References:

• NCSC Zero trust architecture principle 2
• ETSI EN 303 645 (5.1.2)
• NIST SP 800-213A: Data Protection – Cryptographic Key Management

This guideline applies to all devices.

Authentication protocols and mechanisms for users, devices, networks and services must be sufficiently robust to ensure that access is authorised, and where necessary all parties know with whom they are communicating. Using protocols and mechanisms that adhere to current best practice is key here. Some older protocols or non-standard protocols that haven’t been peer reviewed or otherwise verified may contain exploitable flaws that could allow an attacker unauthorised access to a device, system or network.

One way to achieve current best practice is to use authentication protocols based on standardised technologies.

Example: A device supports hardware-backed authentication methods, allowing a user to log in to a device using a physical token or biometric verification instead of a password. The physical token might be a hardware security key using FIDO2 or PIV authentication. Biometric verification methods may include built-in fingerprint sensors or facial recognition from a built-in camera.

Example: A device can authenticate to networks and services using a protocol such as OpenID Connect or SAML. This might also include a FIDO2 or PIV authentication token that is bound to the device's trusted platform module (TPM) to provide another factor of authentication.

Example: The IPsec protocol is used to establish a VPN, in line with NCSC guidance.

By ensuring use of authentication protocols that follow current best practice, users can also make use of services like Single Sign-On (SSO), which provide a better user experience and mitigate attacks such as phishing.

References:

• NCSC Zero trust architecture principle 5
• Using IPsec to protect data
• NIST SP 800-213A: Data Protection – Cryptographic Capabilities and Support
• NIST SP 800-213A: Logical Access to Interfaces – Authentication Support
• NIST SP 800-213A: Logical Access to Interfaces – Authentication and Identity Management

This guideline applies to all devices.

If an attacker accesses keys, passwords or other credentials on the device, it's possible they might use them to authenticate to the device or other services more easily. If this data is stored in secure hardware that can’t be easily compromised, the attacker can’t use this to authenticate and carry out further activity, such as moving laterally around the network.

Example: Login data for a laptop is protected by a TPM.

Example: A certificate used for authentication is stored on a hardware authentication token that uses the FIDO2 protocol.

Example: A fingerprint template used for biometric authentication is stored on the secure element of the processor in a device.

If authentication material isn’t stored on secure hardware, an attacker with access to the storage or operating system may be able to access cryptographic keys, password hashes, biometric data and other items that could facilitate further attack. Using a TPM ensures that key material can’t be exported, and provides isolation between cryptographic operations and the operating system.

References:

• NCSC Zero trust architecture principle 2 and principle 5
• Trusted Platform Module (TPM) Summary | Trusted Computing Group
• NIST SP 800-213A: Device Identification - Device Authentication Support

This guideline applies to all devices.

Individual devices will often require unique identities to separate them from other devices of the same type. When device identity is bound to a physical component of the device, in such a way that it is non-exportable or hardware-backed, an attacker can’t masquerade as that device without compromising that identity.

Information not tied to a physical identity is more likely to be successfully spoofed by an attacker who is able either to access other devices of the same type, or observe device traffic and behaviour.

Example: Certificates used to authenticate to a VPN are generated and stored in a hardware-backed secure enclave, such as a TPM or other dedicated security component. This prevents an attacker extracting the certificate from the device and using it to authenticate from a device they fully control.

In some cases, it may not be possible to tie device identity to a hardware backed source. This can be mitigated to some extent by combining multiple sensor sources for detection of falsified endpoints such as user agents, users, IP addresses and locations (see principle 5).

References:

• MITRE: T1199 Trusted Relationship, T1550 User Alternate Authentication Material
• NCSC Zero trust architecture principle 1, principle 2 and principle 5
• NIST SP 800-213A: Device Identification − Identifier Management Support