Device security principles for manufacturers

This guideline applies to all devices.

The ability to configure devices either locally or remotely (via a device management service) allows administrators to ensure that connected devices consistently meet the minimum security standards they define in their policies (while also allowing end users to customise a device to their requirements). Permissible configurations will depend on the intended use case for the device. In some cases, only a subset of configurations will be more appropriate for exposing locally.

In zero trust architectures, remote device management configuration allows for a baseline for a given device and the ability to assess if it deviates from this known state in line with an organisation’s policy, with the exception of some limited on-device configuration features configurable for usability.

Example: A device is configurable both remotely by an organisation through Mobile Device Management and on the device by the user (to the extent permitted). This includes the ability for features to be turned on/off, or limited where appropriate.

References:

• ETSI EN 303 645: Make installation and maintenance of devices easy
• MITRE: T1078 Valid Accounts
• NCSC Zero trust architecture principles 2, 3, 4
• NIST SP 800-213A: Device Identification − Actions Based on Device Identity
• NIST SP 800-213A: Device Configuration − Device Configuration Control
• NIST SP 800-213A: Logical Access to Interfaces − Interface Control

This guideline applies to all devices.

An organisation needs to be able to configure devices in a manner suitable for their requirements and risk appetite. End users should be prevented from removing these configurations unless they are explicitly authorised to do so.

Example: A device is configured by an administrator in line with an organisation’s policy. The end user can’t modify these settings from the device, which ensures that the device is controlled and appropriately restricted by the organisation.

References:

• ETSI EN 303 645: Minimise exposed attack surfaces
• MITRE: T1553 Subvert Trust Controls
• NCSC Zero trust architecture principles 2, 3, 4, 5
• NIST SP 800-213A: Device Configuration − Authentication and Authorization Configuration
• NIST SP 800-213A: Device Security − Device Integrity

This guideline applies to all devices.

Automated enrolment and onboarding technologies (sometimes referred to as zero touch enrolment) allow for the automatic provision of devices, and automates much of the traditional device enrolment flow. Organisations can supply devices directly to users without an administrator needing to manually set up (or enrol each device to a management service) in advance. This means that devices are hardened, or configured, before they gain access to potentially sensitive information. In addition, it makes the deployment of devices simpler to perform at scale, preventing an organisation using shortcuts (such as password reuse) which could lead to reduced security.

Example: A brand new device not manually configured by an administrator is shipped to an end user and automatically set up with the required configurations. It's enrolled into the enterprise’s chosen device management solution, even if its initial boot-up is occurring on an untrusted network.

Example: An IoT device supports FIDO’s Device Onboard and EAP-NOOB specification.

References:

• ETSI EN 303 645: Make installation and maintenance of devices easy
• MITRE: T1087.001 Local Account
• MITRE: T1059 Command and Scripting Interpreter
• NCSC Zero trust architecture principles 2, 3, 4, 5
• NIST SP 800-213A: Device Identification − Actions Based on Device Identity
• NIST SP 800-213A: Device Configuration − Authentication and Authorization Configuration
• NIST SP 800-213A: Device Security − Secure Network Onboarding Support

This guideline applies to all devices.

Device management platforms can be used to recognise and relay a change in device state and health that may be used to access corporate resources. Using open standards and mechanisms to do this allows administrators to choose a preferred device management platform.

Example: A device can be configured using Google Workspace, Jamf, Microsoft Endpoint Manager and many more. This doesn’t limit the user and so allows an organisation to use a single device management platform across their enterprise devices, regardless of the manufacturer.

References:

• ETSI EN 303 645: Make installation and maintenance of devices easy
• MITRE: T1018 Remote System Discovery
• MITRE: T1437 Standard Application Layer Protocol
• NCSC Zero trust architecture principles 2, 3
• NIST SP 800-213A: Device Security − Secure Network Onboarding Support

This guideline applies to all devices.

If device configurations are exportable and importable, ideally in a documented format, it enables configurations as code. This allows an organisation to define, standardise and automate configuration of a device’s operating system. It minimises the chance of errors where security mitigations aren’t enabled, by reducing the number of configurations an administrator needs to carry out manually, and provides a way to restore to a ‘known state’ across multiple devices in the event of extreme situations. This also makes it simpler for organisations such as the NCSC that provide guidance for easy-to-deploy configurations.

Example: An organisation's range of IP phones has configurations that are XML based and therefore exportable in a standard format. If the IP phones no longer meet the organisation’s policy, changes can be made to a single configuration and deployed across the range of IP phones to enable compliance with the new policy.

References:

• NCSC Zero trust architecture principles 2, 3