EUD Security Guidance: iOS 9

This guidance is applicable to devices running iOS 9. This guidance was developed following testing performed on iPad Air device running iOS 9.0.

It is important to remember that any guidance points given here are just recommendations. None of the suggestions should be seen as being mandatory. They have been suggested as a way of satisfying the 12 security principles.

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

Risk owners’ summary

We recommend the following architectural choices for iOS 9:

All data should be routed over the native IKEv2 always-on VPN to ensure the confidentiality and integrity of the 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). Developers can then choose whether to opt out of this encryption entirely, or opt in to the highest encryption class (encrypted when locked).

Platform integrity and application sandboxing

By signing them with the same key, developers can allow their application to access a shared storage container, shared preferences and shared keychain. 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).

Administrators should pay particular attention to the extensions installed by whitelisted applications, to ensure it’s not trivial to share managed documents outside of managed 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. This 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 and Bluetooth cannot be controlled by policy.

There are no policy controls available to restrict the external interfaces a user can enable, meaning that external interfaces may be accidentally or deliberately enabled by the end user. Enabling external interfaces means increasing the exposed attack surface, and data could be inadvertently or maliciously leaked without organisation visibility.

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 9’s native IKEv2 VPN client can be configured in an ‘Always On’ mode to guarantee all traffic is routed through the organisational infrastructure for inspection. This can protect data-in-transit and quickly switch between cellular and Wi-Fi networks.

Alternatively, organisations 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 organisation’s services.

TouchID 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, TouchID 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 Serverduring 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 and Bluetooth.

Device Update Policy

Users are free to update applications and firmware when they wish, though the 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.

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.11+ 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. It is important to remember that any guidance points given here are just recommendations. None of the suggestions are mandatory. Risk owners and administrators should agree a configuration which balances business requirements, usability and security. Refer to this guidance for advice where needed.

Configurator settings

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 AirDrop (supervised devices only)


Show Control Centre in Lock screen


Show Today view in Lock screen


Allow Internet results in spotlight


Show notification centre in lock screen


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 set on each device:

Configuration Rule

Recommended Setting

Messages – Show Previews


Mail – Show Previews


On-device restrictions menu

These settings should be set 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 allow 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 is not necessary.

VPN profile

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

Module / Algorithm Type

Algorithm Details






AES-128 in CBC



Diffie Hellman Group

14 (2048 bits)



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 9 devices 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 from artifacts 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. Using Safari, documents downloaded from these domains are then 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.

Read more here:: NCSC Guidance