Touch ID or Face ID for accessing secure apps

Two options for accessing secure apps using Touch ID or Face ID are available on the AppConnect global policy:

Touch ID or Face ID with fallback to device passcode
Touch ID or Face ID with fallback to AppConnect passcode

Figure 1. Options for using touch ID or face ID

Comparison of the two Touch ID or Face ID options
Security versus convenience of passcode and Touch ID or Face ID options
Touch ID or Face ID with fallback to device passcode
Touch ID or Face ID with fallback to AppConnect passcode
Configuring Touch ID or Face ID

Comparison of the two Touch ID or Face ID options

The following table lists the differences between the Touch ID or Face D options.

**Table 34.** Differences between the Touch ID or Face ID options
	When using Touch ID or Face ID, fall back to Device Passcode	When using Touch ID or Face ID, fall back to AppConnect Passcode
When prompted for the Touch ID or Face ID, if users fail to provide an accepted entry, they are prompted for:	the device passcode	the AppConnect passcode After too many failures, as controlled by iOS, iOS prompts for the device passcode.
Switches to Mobile@Work are eliminated in some cases when using Touch ID or Face ID.	Yes	No
Require a strong device passcode in the security policy.	Yes	No
Users can use Touch ID or Face ID whenever authenticating to secure apps,	Yes
Users can use Touch ID or Face ID only when authenticating to secure apps due to the AppConnect auto-lock time expiring.	No	Yes
Users can choose whether to use Touch ID or Face ID for future authentications to secure apps.	Yes	Yes, but the choice only applies to future authentications to secure apps due to the AppConnect auto-lock time expiring
When prompted for the Touch ID or Face ID, if users tap Cancel:	Access to AppConnect apps is denied.	Users are prompted to enter the AppConnect passcode.

The following table lists the differences between the Touch ID or Face D options.

**Table 35.** Similarities of Touch ID or Face ID options
	When using Touch ID or Face ID, fall back to Device Passcode	When using Touch ID or Face ID, fall back to AppConnect Passcode
Users must have set a device passcode and added a Touch ID or Face ID on the device.	Yes	Yes
If the device has no Touch ID or Face ID hardware, users authenticates to AppConnect apps using an AppConnect passcode.	Yes	Yes
If the device has no fingerprint or Face ID, or does not have the device passcode enabled, users authenticate to AppConnect apps using an AppConnect passcode.	Yes	Yes
If users choose not to use Touch ID or Face ID, users use an AppConnect passcode to access secure apps	Yes	Yes
In Mobile@Work in Settings > Secure Apps > Authentication, users can at anytime change their choice about whether to use Touch ID/Face ID to access secure apps.	Yes	Yes

Security versus convenience of passcode and Touch ID or Face ID options

AppConnect security involves:

access to AppConnect apps.
encrypting AppConnect-related data such as app configurations and certificates.
encrypting data that the app saves on the device.

The following table lists possible passcode and Touch ID/Face ID choices from most secure to least secure, and discusses the level of device user convenience.

In all cases, stronger passcodes are more secure than weaker passcodes (such as a 4-digit number).

**Table 36.** Security vs device user convenience of passcode and Touch ID/Face ID options
Passcode and Touch ID/Face ID configuration on MobileIron Core	Security of AppConnect apps	Convenience for device user
Require both: •a device passcode •an AppConnect passcode	Highest	Least convenient for accessing both the device and AppConnect apps.
Require only a device passcode	Very high Once the device is unlocked, unauthorized users can access AppConnect apps.	Convenient for accessing AppConnect apps, but inconvenient for accessing the device. However, the device user can make accessing the device more convenient by setting up Touch ID or Face ID for unlocking the device.
Require only an AppConnect passcode	High Data that the app saves to the device is not encrypted unless the app uses the secure file I/O provided in the AppConnect for iOS SDK.	Convenient for accessing the device but inconvenient for accessing AppConnect apps.
•Require only a device passcode and •Use Touch ID or Face ID with fallback to device passcode	High Other device users who have added fingerprints or Face IDs, such as family members, can also access AppConnect apps.	Very convenient for accessing both the device and AppConnect apps.
•Require an AppConnect passcode and •Use Touch ID or Face ID with fallback to AppConnect passcode	Lower Although this option is intended for customers who cannot require a strong device passcode, the device user must create a device passcode to use Touch ID or Face ID. However, users can choose a weak device passcode. A weak device passcode creates a security risk. The risk is that an unauthorized user can guess the device passcode, create a fingerprint or Face ID, and then access AppConnect apps.	Very convenient for accessing both the device and AppConnect apps.
No passcodes required	Lowest Note the following: •Unauthorized users can access the device and AppConnect apps. •AppConnect-related data, such as app configurations and certificates, is encrypted but the encryption key is not protected by a passcode. •Data that the app saves on the device is encrypted but the encryption key is not protected by a passcode.	Most convenient for accessing both the device and AppConnect apps.

Touch ID or Face ID with fallback to device passcode

Touch ID or Face ID with fallback to device passcode allows device users to enter their Touch ID (fingerprint) or Face ID instead of an AppConnect passcode to access secure apps. An AppConnect passcode is not required. If entering the Touch ID or Face ID fails, users enter (falls back to) the device passcode to access secure apps. When you use this option, a strong device passcode is required. Make sure the security policy for the applicable devices requires a strong device passcode. Most customers typically choose the Touch ID or Face ID with fallback to device passcode option.

Users can use Touch ID or Face ID to access secure apps if:

You configure the Touch ID or Face ID option in the AppConnect global policy.
You require strong device code in the security policy.
The device has Touch ID or Face ID capability.
The device has a device passcode and Touch ID or Face ID is enabled.

When all of the above are true, Mobile@Work gives users the choice whether to use Touch ID or Face ID. If users do not set up Touch ID or Face ID, they can authenticate using the device passcode.

Configuring the security policy for strong device passcode

A strong device passcode is required for Touch ID or Face ID to provide security for AppConnect apps. Make sure the security policy for the applicable devices requires a strong device passcode.

Procedure

Go to Policies & Configs > Policies in the MobileIron Core Admin Portal.
Select the security policy for the applicable devices.
Click Edit.
In the Password section, select Mandatory.
Select options for a strong password.
These options include Alphanumeric, Minimum Password Length, and Minimum Number of Complex Characters.
Click Save.

Switches to Mobile@Work eliminated with Touch ID or Face ID with fallback to device passcode

AppConnect apps prompt for the Touch ID or Face ID without switching to Mobile@Work, in the following cases:

The device user launched or switched to an AppConnect app after the auto-lock timeout expired.
The auto-lock timeout expired while the device user was running an AppConnect app.

When these apps prompt for the Touch ID or Face ID, the prompt does not cover the entire screen. The apps, therefore, make sure sensitive data on the app’s screen is not readable until the device user enters the Touch ID or Face ID. The following table summarizes this behavior:

**Table 37.** Behavior of wrapped versus SDK apps when displaying Touch ID/Face ID prompt
Type of app	Behavior when displaying Touch ID/Face ID prompt
Wrapped apps	Blurs the visible parts of the screen.
SDK apps	Hides sensitive data according to the app’s own requirements and user interface strategies

Some situations other than the auto-lock timeout cause the app to switch to Mobile@Work. Some of these situations are:

The first time an app is launched.
When the app check-in interval expires while an AppConnect app is running. Mobile@Work gets AppConnect policy updates for all the AppConnect apps, and then control switches back to the app that was running.
After the device is powered on and the device user first launches an AppConnect app.
After the device user logs out of secure apps in Mobile@Work, and then relaunches an AppConnect app.
Device users relaunch an app after they or iOS terminated it.

However, these other reasons for switching are less frequent than the switch due to the auto-lock timeout.

Improved user experience

Using Touch ID or Face ID with fallback to device passcode to access secure apps improves the user experience as follows:

Users no longer needs to create, remember, and enter a secure apps passcode to access secure apps.
Switching to Mobile@Work due to the auto-lock timeout is eliminated. Instead the app itself prompts for the Touch ID or Face ID, resulting in a simpler experience for users. This switch to Mobile@Work is eliminated for apps as described in Switches to Mobile@Work eliminated with Touch ID or Face ID with fallback to device passcode.
Mobile@Work gives users the choice to use Touch ID/Face ID or a secure apps passcode to access secure apps. This choice is useful when a device is shared among multiple users, such as co-workers or even a family, each of whom uses a fingerprint or Face ID to access the device. Although all the users can access the device with Touch ID/Face ID, sometimes only one of those users should be allowed to access AppConnect apps. That user can choose to use the AppConnect passcode instead of Touch ID/Face ID for accessing AppConnect apps. This feature therefore ensures that only an appropriate device user accesses AppConnect apps.

Device user impact in Mobile@Work

Mobile@Work gives the device user the choice to use Touch ID or Face ID or to use the AppConnect passcode for accessing secure apps.

Mobile@Work prompts the device user to make the choice when:

You have selected the option to use Touch ID or Face ID with fallback to device passcode on the AppConnect global policy.
The device user has enabled both Touch ID / Face ID and the device passcode on the device in Settings > Touch ID & Passcode.
The device user has registered a device and then either
- Accesses secure apps for the first time or
- Taps Log In (to secure apps) on the Mobile@Work home screen

If the device user chooses Touch ID or Face ID, he will use Touch ID/Face ID for all further authentications to secure apps. If the device user does not choose Touch ID or Face ID, he will use the AppConnect passcode for all further authentications to secure apps.

The device user can change the authentication method using Settings > Secure Apps > Authentication in Mobile@Work.

Less common device user scenarios

These scenarios describe the user experience in less common situations when using Touch ID.

**Table 38.** Less common device user scenarios involving Touch ID
On the AppConnect global policy	On the device	Behavior
Touch ID enabled	Fingerprint available Device passcode turned off	Consider the case when the device user had accessed secure apps using Touch ID before turning off the device passcode. When the device user attempts to access secure apps, the user is prompted to turn on the device passcode. Now consider the case when the device user had never accessed secure apps before turning off the device passcode. The device user will be prompted to create a secure apps passcode.
Touch ID enabled	No fingerprint available	Regardless whether the device passcode is turned on or off on the device, the device user is prompted to create a secure apps passcode when first trying to access secure apps. The device user then uses that secure apps passcode for all secure apps access. If the device user later adds a fingerprint and turns on the device passcode, he continues to use the secure apps passcode.
Touch ID enabled	Fingerprint available, then deleted. Device passcode turned on.	Consider the case when the device user deletes the fingerprint after accessing secure apps with Touch ID. The device user will use the device passcode to access secure apps.
Touch ID enabled	Fingerprint available, then deleted. Device passcode turned on, then turned off.	Consider the case when the device user deletes the fingerprint and turns off the device passcode after accessing secure apps with Touch ID. The device user must turn on the device passcode, and optionally add a fingerprint, to access secure apps.
Touch ID enabled then disabled	Fingerprint available. Device passcode turned on.	Consider the case when you disable Touch ID on the AppConnect global policy after the device user has accessed secure apps using Touch ID. The next time the device user accesses a secure app, he is prompted to create a secure apps passcode.
Touch ID enabled, then passcode requirement removed	Fingerprint available. Device passcode turned on.	Consider the case when you remove the passcode requirement on the AppConnect global policy after device user accessed secure apps with Touch ID. The next time the user accesses a secure app, they use Touch ID one last time. After that, they can access secure apps without a passcode.
Touch ID not enabled, then enabled	Fingerprint available Device passcode turned on	Consider the case when you select the Touch ID option on the AppConnect global policy after the device user accessed secure apps using a secure apps passcode. The device user continues to use the secure apps passcode.
Touch ID enabled	Multiple fingerprints available Device passcode turned on	Any fingerprint available on the device can be used to access secure apps. A device user often chooses to use a secure apps passcode instead of Touch ID in this case. Using a secure apps passcode ensures other users of the device do not have access to secure apps.

Touch ID or Face ID with fallback to AppConnect passcode

With this option, when the auto-lock time for AppConnect apps expires, the device user uses Touch ID or Face ID rather than the AppConnect passcode to re-access AppConnect apps. If entering the fingerprint or Face ID fails, users enter (falls back to) the AppConnect passcode to access secure apps. The device user also uses the AppConnect passcode for other situations requiring AppConnect authentication such as the first time an AppConnect app is launched or when users logs out of secure apps in Mobile@Work.

Therefore, with this option, users must create both a device passcode and an AppConnect passcode. The AppConnect passcode is necessary for all AppConnect authentications except the auto-lock time expiry. The device passcode is necessary because iOS requires it for Touch ID to be available. However, the device passcode does not have to be strong.

Use this option only if you have a compelling reason to not require your device users to have a strong device passcode. A weak device passcode creates a security risk. The risk is that an unauthorized user can guess the device passcode, create a fingerprint or Face ID, and then access AppConnect apps.

One situation for choosing this option is if you are required by law to not require a strong device passcode on employee-owned devices. If you have such a requirement, but still want to give device users the convenience of using Touch ID to access AppConnect apps, choose this option.

Improved user experience

The user experience is improved similarly to when using the option to use Touch ID or Face ID with fallback to device passcode. The improved user experience includes:

Improved device user convenience compared with always entering the AppConnect passcode
When using this option, device users can use Touch ID or Face ID to access AppConnect apps when the auto-lock time expires. For other situations such as when Mobile@Work had been terminated or when a user used Mobile@Work to log out of secure apps, the user still must enter an AppConnect passcode. However, since the auto-lock time expiry is the most frequent situation that requires AppConnect authentication, the device user’s experience is improved.
Device user choice to use Touch ID or Face ID or to always use a secure apps passcode
Mobile@Work gives the user the choice to use Touch ID or Face ID or an AppConnect passcode to access secure apps when the auto-lock time expires. This choice is useful when a device is shared among multiple users, such as co-workers or even a family, each of whom uses a fingerprint or Face ID to unlock the device. Although all the users can access the device with Touch ID/Face ID, sometimes only one of those users should be allowed to access AppConnect apps. That user can choose to use the AppConnect passcode instead of Touch ID/Face ID for accessing AppConnect apps when the auto-lock time expires.

Device User impact of Touch ID or Face ID with fallback to AppConnect passcode

The following is the device user experience for a newly registered user:

After the device user registers with Mobile@Work, Mobile@Work prompts the device user to create an AppConnect passcode.
After creating the AppConnect passcode, Mobile@Work gives the user the option to use Touch ID/Face ID to access secure apps.
If users choose the Touch ID/Face ID option, they can use Touch ID or Face ID when accessing secure apps after the auto-lock time has expired.
The device user can later use Mobile@Work settings to change his choice about using Touch or Face ID.

Configuring Touch ID or Face ID

Do the following to configure the AppConnect global policy to use Touch ID for accessing secure apps.

Procedure

In the Admin Portal, go to Policies & Configs > Policies.
Select the appropriate AppConnect global policy.
Click Edit.
The AppConnect global policy displays.
Select Passcode is required for iOS devices.
Select Use Touch ID or Face ID when supported.

The option When using Touch ID or Face ID, fall back to: appears:
Select Device passcode or AppConnect passcode.
Click Save.

If you selected fall back to device passcode and you are using an iOS restrictions setting, make sure that it allows Touch ID to unlock a device. If you are not using an iOS restrictions setting, Touch ID is allowed. You can skip the following steps.

In the Admin Portal, go to Policies & Configs > Configurations.
Select the appropriate iOS restrictions setting.
Click Edit.
The iOS restrictions setting displays.
Make sure that Allow Touch ID to unlock device is selected.
Click Save.