Multi-factor authentication for your corporate online services
Page 3 of 7
Recommended types of MFA
The previous examples illustrate that choosing the type of MFA to implement means balancing competing demands that sit within your organisation’s risk appetite. However, where possible you should adopt the type of MFA in the order presented below. The NCSC have chosen this order based on the strength of authentication provided, including the assurance, accessibility, and usability that they provide. For each one, we've also outlined scenarios where the method is particularly appropriate (or less appropriate):
- FIDO2 credentials (on trusted 'platform' devices or 'roaming' keys)
- Challenge-based authenticator apps
- App-based code generators
- Hardware-based code generators
- Message-based methods (email, SMS and call-based)
1. FIDO2 credentials (on trusted 'platform' devices or ‘roaming’ keys)
FIDO2 authentication is one of the most secure, yet usable methods of MFA. It uses standardised public-key cryptography to verify that the user possesses a trusted key-based credential. This key is protected by software on a user’s trusted ‘platform’ device, such as their laptop or smartphone, or on a ‘roaming’ FIDO2 security key, such as some YubiKeys. To achieve MFA, this software should additionally require established local user verification, such as a PIN or biometric (i.e. options enforced by Microsoft’s Windows Hello for Business or Apple’s Touch ID/Face ID systems), before the key-based credential can be used.
Summary: This method provides strong, password-less MFA using possession of the key-based credential plus local verification of the user. It can also strengthen existing password-based authentication. FIDO2 MFA provides guessing resistance, phishing resistance, and theft resistance.
| FIDO2 MFA is likely to be appropriate when: | FIDO2 MFA is less likely to be appropriate when: | Example use case |
|---|---|---|
The user is provided with an individual trusted device or security key that supports FIDO2 authentication. The user often works in a location where mobile network connectivity is unavailable or unreliable. The user often works in a location where mobile devices are not permitted. You can enable FIDO2 for federated single sign-on to the online service (if it does not natively support it). | You are unable to procure or effectively risk manage a trusted device or security token for a user. The online service does not support FIDO2 authentication, either directly or via federated single sign-on. | A user has a corporately managed device with Windows Hello for Business or Touch ID enabled. A user uses a roaming security key to authenticate to online services on the corporate shared workstation they are using that day. All IT administrators are issued with a hardware security key that must be used when accessing administrative interfaces. |
2. Challenge-based authenticator apps
Challenge-based authentication is a key-based authentication method that often uses a proprietary software app on a trusted user device to receive a challenge request directly from the service. The user must correctly interact with the app to send a confirmation back to the service that they are in possession of a trusted device. For example, Push Notification approval through a trusted smartphone app, like Google prompts and Microsoft Authenticator number matching.
Summary: This method can provide strong, password-less authentication on its own, or strengthen existing password-based authentication. It provides guessing resistance and theft resistance, but only provides partial phishing resistance because it is vulnerable to the ‘prompt fatigue’ attack. This method is recommended if FIDO2 authentication is not appropriate.
| Challenge-based authenticator apps are likely to be appropriate when: | Challenge-based authenticator apps are less likely to be appropriate when: | Example us case |
|---|---|---|
The user has a trusted mobile device and app that is trustworthy enough to protect the key and receive and respond to the challenge securely. You can enable challenge-based MFA for federated single sign-on to the online service, even if it does not natively support it. | The user does not have a trusted device that can receive or respond to the challenge. The online service does not support challenge-based authentication directly or via federated single sign-on. The user often works in locations where mobile network connectivity is unavailable or unreliable. The user often works in a location where mobile devices are not permitted. | A user that has a trusted mobile device with an app that can approve their login request to access a shared workstation in their office. A user has a corporately managed smartphone that can approve login requests for a Bring Your Own Device (BYOD) laptop. |
3. App-based code generators
App-based code generation is a common method of authentication that uses a verified software app on a trusted user device to generate OTP codes. The code is derived from a secret generated by the online service and registered by both the service and an app on the user’s device (usually via a QR code) when the method is first set up and verified by the user.
Summary: This method can strengthen password-based authentication by requiring the user to enter the OTP, suggesting access to the verified software app and, by extension, possession of a trusted user device. It also provides password guessing resistance. However, they are known to be vulnerable to the OTP interception phishing attack, and are not theft resistant (as the shared secret is stored by the online service, often alongside the password). This method is recommended if previous methods are not appropriate.
| App-based code generators are likely to be appropriate when: | App-based code generators are less likely to be appropriate when: | Example use case |
|---|---|---|
The user has a trusted mobile device and app on it that can protect the code generation secret. The user is outside of your organisation’s technical control or federation of direct trust. | The user does not have an individual trusted device that can protect the code generation secret. The user often works in a location where mobile devices are not permitted. | A user from outside your organisation must enter a code if they have not already performed verifiable, stronger authentication using another method. |
4. Hardware-based code generators
Hardware-based code generation is a method of authentication that uses a verified physical token to generate an OTP code. Unlike app-based generators, these tokens usually have no way of receiving a generated secret from an online service. Instead, it is most common for organisations to receive a printed or electronic list mapping the ‘burned-in’ secret to token serial number that can be imported into the online service.
This means that all secrets for an organisation’s users will be available in the clear in one place. It is therefore arguable that the use of such a hardware token is weaker than when using a software equivalent on a trusted user device. This method is often less usable as these hardware tokens commonly only generate one set of codes, meaning they can only protect one account (or are forced to use the same code across multiple accounts and services, increasing the impact of phishing).
Summary: This method can strengthen password-based authentication by suggesting possession of the verified physical token. This method can provide guessing-resistance, but is known to be vulnerable to OTP interception phishing and is not theft-resistant as the ‘seed’ secret also needs to be stored alongside the password. This method is recommended if all previous methods are not appropriate.
| Hardware-based code generators are likely to be appropriate when: | Hardware-based code generators are less likely to be appropriate when: | Example use case |
|---|---|---|
The user often works in a location where mobile devices are not permitted and a FIDO2 security key or app-based OTP is not appropriate. Users must share and transfer an authentication token and none of the previous MFA methods are appropriate. | You are unable to provide and/or manage individual hardware tokens to the individual. | An administrator ‘on-call’ must hold the hardware code generator for access to a shared account (that does not support multiple registered authenticators). |
5. Message-based methods (email, SMS and call-based)
Message-based authentication uses delivery of a message (usually containing a code) to a verified contact address. This code can strengthen password-based authentication by suggesting ‘live’ access to the previously verified contact address.
| Message-based methods are only likely to be appropriate when no other strengthening method is possible. |
|---|
| Example use case: A legacy system that does not support alternative types of MFA, or the only information about the user that you have verified is a digital contact address. |