End User Devices: Security Principles

Created:  24 Sep 2016
Updated:  24 Sep 2016
These principles provide the basis for our guidance on the configuration of specific EUDs.

The EUD Security Framework describes twelve principles for securing devices, all of which must be considered when deploying a particular solution. 



Data-in-transit protection

Data should be protected as it transits from the EUD to any services the EUD uses. IPsec VPNs provide the most standards-compliant way of doing this, but TLS VPNs or per-app TLS connections can also be used.


Formal assurance of this function to Foundation Grade against the appropriate Security Characteristic is strongly recommended.

Data-at-rest protection

Data stored on the device should be satisfactorily encrypted when the device is in its “rest” state. For always-­on devices like smartphones, this is when the device is locked.


Formal assurance of this function to Foundation Grade against the appropriate Security Characteristic is strongly recommended.


Each of the three types of authentication described here should be considered:

  • User to device: the user is only granted access to the device after successfully authenticating to the device.
  • User to service: The user is only able to access enterprise services after successfully authenticating to the service, via their device.
  • Device to service: Only devices which can authenticate to the enterprise are granted access.

Each stage of the authentication process should be designed to complement the others, as part of your organisation’s authentication policy. Further guidance on devising an authentication policy can be found below.

Secure boot

An unauthorised entity should not be able to modify the boot process of a device, and any attempt to do so should be detected.

Platform integrity and application sandboxing

The device can continue to operate securely despite potential compromise of an application or component within the platform, and you have the ability to restrict the capabilities of applications on the device.

Application whitelisting

The enterprise can define which applications are able to execute on the device, and these policies are robustly enforced on the device.

Malicious code detection and prevention

The device can detect, isolate and defeat malicious code which is present on the device.

Security policy enforcement

Security policies set by your organisation are robustly implemented across the platform. The organisation can technically enforce a minimal set of security-critical policies on the device. These cannot be overridden by the user.

External interface protection

The device is able to constrain the set of ports (physical and logical) and services exposed to untrusted networks and devices. Any software exposed in this way is robust to malicious attack.

Device update policy

You are able to issue security updates and can remotely validate the patch level of your entire device estate.

Event collection for enterprise analysis

The device reports security-critical events to your audit and monitoring service. The user is prevented from tampering with this reporting.

Incident response

Your organisation has a plan in place to respond to and understand the impact of security incidents. This should be supported by appropriate functionality within the devices and your organisation. In the case of a lost device, this might entail sending a wipe command to the device and revoking credentials.

Was this guidance helpful?

We need your feedback to improve this content.

Yes No