EUD Security Guidance: iOS 10

This guidance was developed following testing performed on an iPad Air device running iOS 10.0.2.

It’s important to remember that this guidance has been conceived as a way to satisfy the 12 End User Device Security Principles. As such, it consists of recommendations and should not be seen as a set of mandatory instructions requiring no further thought.

Risk owners and administrators should agree a configuration which balances business requirements, usability and security.

Risk owners’ summary

We recommend the following architectural choices for iOS 10:

All data should be routed over the native IKEv2 always-on VPN to ensure the confidentiality and integrity of traffic. This also allows the devices and data on them to be protected by your organisation’s protective monitoring solutions.
Users should not be permitted to install arbitrary third-party applications on the device. Your organisation’s application catalogue should be used to distribute in-house applications and suitable, assessed, third-party applications.
Unless your organisation decides to use a particular third-party VPN, third-party VPN extensions should not be installed by users. Although VPN extension providers require entitlements to be granted by Apple when developing the extension, it may be possible that a malicious or poorly written VPN extension could be used to capture and log network traffic.
When configured in this way, risk owners should be aware of the following technical risks associated with this platform:

Associated security principle

Explanation of risks

Assured data-in-transit protection

The built-in VPN client has been assured to Foundation Grade.

Assured data-at-rest protection

iOS data encryption has Foundation Grade approval for applications that use Data Protection APIs to protect data when the device is locked.

Applications can choose classes of data encryption on a per-file basis. By default, only a limited number of files remain encrypted whilst the device is locked. This includes email and attachments (within the mail app), managed books and location data. Files belonging to other applications may not be encrypted when the device is locked, and could be extracted without knowledge of the password, using a vulnerability in the platform.

Third-party applications are automatically opted in to the encryption class which protects their data when the device is in a powered-off state (but not when locked). This class protects data from attacks which require a reboot. Developers can then choose whether to opt out of this encryption class into a class which is always available, or opt in to the highest encryption class (encrypted when locked).

Platform integrity and application sandboxing

Sensitive data generated within one application may potentially be accessible to another if those applications are part of an app group. Application whitelisting can help mitigate this.

Application whitelisting

Not all classes of application extension respect managed to unmanaged application restrictions (e.g. a sharing extension may allow sensitive data to be shared to a social network).

To ensure it’s not trivial to share managed documents outside of managed applications, administrators should pay particular attention to the extensions installed by whitelisted applications.

Security policy enforcement

Policy settings applied through Apple Configurator cannot be overridden (when using recommended security settings). However, Mobile Device Management (MDM) profiles can be removed by the user (unless DEP is used – see below).

Apple’s Device Enrolment Program (DEP) can allow devices to be enrolled over-the-air during the device setup process. DEP can be used to limit the time a device is in a potentially hostile environment or configuration, and prevent removal of the MDM profile.

Custom keyboards should not be deployed via MDM. Keyboards deployed via MDM are considered managed and can then be used within other managed applications such as the mail app. If the user allows “full access” to the keyboard extension (which may be required for its correct operation), it is then not restricted from logging and sending keystrokes to external servers.

Procedural controls must be used to achieve some of the requirements where technical controls are not possible. This means that users have to be trusted not to alter certain settings on the device, or perform actions which may impact the security of the device. These controls are discussed in later sections.

External interface protection

Radio interfaces such as Wi-Fi cannot be controlled by policy.

A new MDM policy setting (Allow modifying Bluetooth settings) has been added in iOS 10 to restrict Bluetooth modification. This could be set to further reduce the attack surface, but would prevent legitimate functionality.

Enabling external interfaces means increasing the exposed attack surface, and data could be inadvertently or maliciously leaked without organisation visibility. Therefore a risk based decision should be made to determine if this control is appropriate.

Event collection for enterprise analysis

There is no facility for collecting logs remotely from a device, and collecting forensic log information from a device is very difficult.

Incident response

iOS devices can be remotely locked, wiped, and reconfigured by their MDM.

Administrators’ deployment guide


To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below.

Security Principle

Recommendation and Explanation

Assured data-in-transit protection

iOS 10’s native IKEv2 VPN client can be configured in an ‘Always On’ mode to guarantee all traffic is routed through your organisational infrastructure for inspection. This can protect data-in-transit and quickly switch between cellular and Wi-Fi networks.

Alternatively, you also have the option to use a third-party VPN supporting the VPN Extension Point API. These extensions should be installed from a whitelist, if required by your organisation. This minimises the risk of a malicious or poorly-configured VPN extension finding its way onto a device.

Assured data-at-rest protection

iOS data protection is enabled by default. The Mail application uses Data Protection APIs to encrypt emails and attachments when the device is locked. By default, this level of protection also extends to location data and app launch images. Third-party developers need only request this protection class to gain its benefits.


The user should be required to authenticate to the device in line with your organisation’s authentication policy (see Authentication Policy below).

Authenticating to the device unlocks a key which encrypts certificates and other credentials, giving access to the organisation’s services.

Touch ID permits biometric unlock of devices but the strength of its security is difficult to measure. In cases where there is a requirement to use biometric authentication, and the risks of using biometrics as the sole authentication mechanism are understood, Touch ID can be enabled.

Secure boot

No configuration is required.

Platform integrity and application sandboxing

No configuration is required

Application Whitelisting

An organisation application catalogue can be established to permit users access to an approved list of applications developed in-house, and an approved list on the App Store.

Alternatively, the full App Store can be enabled, and Mobile Device Management (MDM) can be used to monitor which applications a user has installed retrospectively.

Extensions are installed along with a containing application, and cannot be installed alone. It is therefore possible to apply application whitelisting rules that target these applications in order to restrict extensions.

Administrators should be aware of the extensions installed by their whitelisted applications, to ensure that they do not introduce unexpected methods for sharing data outside of managed applications. It is not currently possible to define granular rules that block extensions, but permit the containing application (beyond implementation of managed/unmanaged application boundaries).

Malicious code detection and prevention

The organisation app catalogue should only contain in-house applications and third-party applications which have been approved by an administrator. Content-based attacks can be filtered by scanning on the email server.

Security policy enforcement

A combination of either Configurator+MDM or DEP+MDM should be used to configure users’ devices. Settings applied through Apple Configurator can be configured such that they cannot be removed by the user.

Policy applied through an MDM can be removed completely by an end user through removal of the Remote Management profile. This can be prevented if a Device Enrolment Program (DEP) is used.

However, removing the Remote Management profile will also remove any data stored as part of accounts configured through MDM (e.g. email and credentials). When configuring an MDM, it should be configured such that:

(i) arbitrary devices cannot be enrolled,

(ii) end users are prevented from re-enrolling.

Users should not be allowed to directly re-enrol, as it may be possible for the user to affect the security of the device by:

(i) removing the MDM profile,

(ii) modifying the on-device configuration options,

(iii) re-enrolling the device through a self-service portal.

Apple’s Device Enrolment Program should be considered to enable devices to register with the MDM Server during the setup process, decreasing the risk of a compromised device enrolling.

Email accounts should be provisioned via MDM too, as only email accounts provisioned via MDM will operate correctly with restrictions to disallow opening documents in unmanaged applications (“Managed Open In”). This also means that if the MDM profile is removed, all credentials and data associated with that profile will also be removed.

External interface protection

The Configurator should be used to put the device into supervised mode, after which the user is only able to use the USB interface for charging their device. No technical controls exist to prevent users from enabling Wi-Fi.

Device Update Policy

Users are free to update applications and firmware when they wish, though your organisation can block this at the proxy server if desired. In addition, an MDM can be used to monitor the iOS versions currently installed and access could be revoked if necessary.

Event collection for enterprise analysis

iOS does not support remote or local historic event collection. Limited information regarding device state can be retrieved from the device. The features may depend on the MDM.

Incident Response

iOS devices can be locked, wiped, and configured remotely by their MDM.

Recommended network architecture

All remote or mobile working scenarios should use a typical remote access architecture with a VPN terminating into a DMZ. The following network diagram describes this set up.

iOS10 Recommended Network Architecture

A Mobile Device Management server is required. Apple’s OS X Server with Profile Manager is sufficient for this purpose. Alternatively, many third-party products exist which may offer additional functionality over and above Profile Manager.

Preparation for deployment

The steps below should be followed to prepare your organisational infrastructure to host a deployment of these devices:

Deploy OS X 10.12+ and Apple Configurator 2 onto a dedicated provisioning terminal.
Procure, deploy and configure other network components, including an approved IPsec VPN Gateway.
Set up the MDM and create policies for users and groups in accordance with the settings later in this section.

Device provisioning steps

The steps below should be followed to provision each end user device onto your organisation’s network, preparing it for distribution to end users:

Use Configurator 2 to supervise the iOS devices (this is necessary for the “supervised only” restrictions enforced via the MDM to be effective).
Enrol the devices into the MDM deployed earlier and install the predefined configuration profile.
Apply any additional, required security controls by using the Restrictions menu locally on the device.
Alternatively, devices can be purchased through the Device Enrolment Program which means that the devices will be supervised ‘out of the box’, and can be configured to automatically enrol with the MDM server when first activated.

Recommended policies and settings

This section details important security policy settings which are recommended for an iOS deployment. Other settings (e.g. server address) should be chosen according to the relevant network configuration.

Remember, any guidance points given here are recommendations – they are not mandatory. Risk owners and administrators should agree a configuration which balances business requirements, usability and the security of the platform.

Configurator settings

In cases where Device Enrollment Program (DEP) is being used to enrol devices into the MDM server, this step can be omitted. In other cases, these settings should be applied to the device by creating profiles in the Configurator utility:

General Group

Security (user can remove profile)


Automatically Remove Profile




Allow devices to connect to other Macs


If not using the always-on IKEv2 VPN, the Global HTTP Proxy settings should also be set to match the network configuration for when the device is connected to the VPN.

MDM settings

These settings should be applied to the device by creating profiles on the MDM server:

Security & Privacy

Privacy: Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics with app developers


Restrictions Group

Allow installing apps


Allow screenshots


Allow installing configuration profiles (supervised devices only)


Allow iCloud backup


Allow iCloud documents & data


Allow iCloud keychain


Allow iCloud photo sharing


Allow backup of enterprise books


Allow managed apps to store data in iCloud


Allow Handoff


Allow notes and highlights sync for enterprise books


Force encrypted backups


Allow users to accept untrusted TLS certificates


Allow Siri whilst device is locked


Allow modifying account settings (supervised devices only)


Allow documents from managed sources in unmanaged destinations


Allow sending diagnostic and usage data to Apple


Allow pairing with non-Configurator hosts (supervised devices only)


Allow AirDrop (supervised devices only)


Show Control Centre in Lock screen


Show Today view in Lock screen


Show Notification Centre in Lock screen


Allow Internet results in spotlight


If using Profile Manager, ensure that the option to sign configuration profiles is selected. Other MDMs may have a similar option which should be selected.

On-device notifications menu

To prevent sensitive data appearing on the lock screen, the following settings should be applied on each device:

Configuration Rule

Recommended Setting

Messages – Show Previews


Mail – Show Previews


On-device restrictions menu

These settings should be applied on each device.

Configuration Rule

Recommended Setting

Contacts – Don’t allow changes


Calendars – Don’t allow changes


Photos – Don’t allow changes

As per organisational policy

Share My Location – Don’t allow changes


Bluetooth Sharing – Don’t allow changes


Allowing changes to these restrictions will enable applications on the device to request access to the named data store. Any that are not required should be disabled.

To make the provisioning steps less onerous, the risks mitigated by these settings could also be met in other ways. Contacts, Calendars, Photos and Bluetooth permissions are only risky if third-party applications which use these permissions are installed on the device. Some users’ locations may not be sensitive, in which case Location Services may be enabled.

But where the user’s location is sensitive, Location Services should be disabled. In these scenarios, the use of the above restrictions settings are not necessary.

VPN profile

The deployed VPN should be configured according to the PRIME profile for IPSEC.

The recommended IPsec cipher suite profile for protecting information is called PRIME. A non-authoritative summary is provided in the table below:




AES-128 in GCM-128 (and optionally CBC)

Pseudo-random function


Diffie-Hellman Group

256bit random ECP (RFC5903)

Group 19 Authentication

ECDSA-256 with SHA256 on P-256 curve




AES-128 in GCM-128

VPN Settings


Dead peer detection interval


Enable perfect forward secrecy


Disable redirects


Disable mobility and multihoming


Enable certificate revocation check


VPN On Demand


The deployed VPN solution should be configured to negotiate the parameters below. Not all of these settings can be configured on the device or MDM VPN profile, therefore the configuration also needs to be enforced from the VPN server.

Note that for an iOS device to verify the VPN server certificate, the certificate must have a Subject Alternative Name (SAN) entry that matches the common name. Further information on the supported server configurations can be found at

Authentication policy

Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use the published password guidance to help inform any password policy.

An administrator should configure the relevant on-device settings in line with your authentication policy.

For further guidance on authentication policies, see the NCSC EUD Authentication guidance.

To enforce this policy on iOS devices, the following settings are available, and should be set according to the policy:

Allow simple value
Require alphanumeric value
Minimum passcode length
Minimum number of complex characters
Maximum Auto-Lock
Passcode history
Maximum grace period for device lock
Maximum number of failed attempts
Allow Touch ID to unlock device
Hardware strengthening

All devices since the iPhone 5S have a Secure Enclave Processor (SEP) which handles secure storage of cryptographic keys. A successful authentication against the SEP is required to grant access to the device and its data. This prevents offline, brute force attacks against data-at-rest keys. Online brute-force attacks are also prevented by the SEP, which locks after 10 unsuccessful attempts.


iOS 10 devices can use Touch ID for biometric authentication which happens within the Secure Enclave Processor. This means that a physical attack on a locked device should not result in compromise of data.

The fingerprint reader has a 0.002% false acceptance rate for a random fingerprint, but there have been published attacks on the feature using artefacts taken from the device. Using such attacks, a targeted physical attack on a specific user could result in the attacker gaining access to the device. You should consider these limitations when devising an authentication policy which permits the use of biometrics.

Other considerations

The following points are in addition to the common organisation considerations, and contain specific issues for iOS deployments.

Cloud integration

iOS devices do not need to be associated with an Apple ID to operate as required within an organisation. For example, it is still possible to receive push notifications, and to install organisation applications without an associated account. In addition, in iOS 9 Apple has removed the need for an Apple ID when installing applications using the Volume Purchase Program (VPP), further reducing the requirement for each user to have a provisioned Apple ID.

If an Apple ID is used to enable iCloud services on the device, then documents and other sensitive data may be inadvertently synchronised with iCloud. As a mitigation, organisations that wish to prevent this should implement controls to prevent users from enabling unneeded iCloud services on their device, thereby preventing organisation data from being synchronised with iCloud servers.

App groups

Apps and extensions that are produced by the same developer can potentially share content when configured as part of an ‘app group’. Sensitive application data could therefore be made available to another application on the device, potentially being shared from managed to unmanaged applications. Third-party applications should be reviewed to identify membership of an app group, and appropriate whitelisting should be applied where necessary.

Unmarked email domains

As with iOS 8+, “unmarked” email domains can now be configured. When a user is composing an email using the system email client, any email address entered which does not match the configured domains will be highlighted (marked) in red. Administrators should consider using this functionality, to warn users who may be inadvertently attempting to send sensitive information to untrusted email addresses.

Managed Safari web domains

In iOS 8+ a list of domains can now be configured that the device will treat as “managed” in the Safari web browser. When using Safari, documents downloaded from these domains are subject to “Managed Open In” rules and should not be accessible to unmanaged applications. Configuring these domains can help to stop sensitive documents from being trivially shared to other applications.

iOS 10 Lock screen widgets

A widget is an extension which can display content or information provided by an application. On iOS 10 a number of widgets are turned on by default and can expose information to the lock screen. In order to prevent data leakage via the lock screen, it is important that widgets are disabled. This can be enforced via MDM policies. It should be ensured that the “Show Today view in Lock screen” option is unticked to prevent this behaviour.

iOS 10 Universal Clipboard

iOS 10 Universal Clipboard allows sharing clipboard data between multiple devices registered on an iCloud account. Ensuring that handoff is disallowed in the MDM settings prevents the functionality of Universal Clipboard. As noted in the earlier section on iCloud integration, it is recommended that all iCloud settings are reviewed to ensure they are configured to prevent inadvertent synchronisation of data to iCloud.

Read more here:: NCSC Guidance