Guide to multi-factor authentication (MFA) policy

This document provides explanatory guidance on the NHS England multi-factor authentication policy.

This guidance does not form part of the policy and is not directly enforceable.

The policy is published as guidance on compliance with the Data Security and Protection Toolkit (DSPT), and will be incorporated directly within DSPT version 6 (2023-24). The DSPT is an information standard to which all health or care providers, and public bodies exercising functions in connection with the provision of health or care services, have a statutory obligation to have regard under s250(6) of the Health and Social Care Act 2012. Additionally, completion of the DSPT to at least ‘Standards Met’ is a contractual obligation on many organisations, such as for providers under the NHS Standard Contract.

The policy is also published as guidance under s3(3)(b) of the Network and Information Systems (NIS) Regulations 2018.  Organisations that are designated under the Regulations as operators of essential services for the health sector have a statutory obligation under s10(4) to have regard to such guidance.

Enforcement action may be taken under any of these as applicable to the particular organisation.

The cyber security strategy for health and social care establishes the Cyber Assessment Framework (CAF) as the principal cyber standard for health and care.

Implementation of this policy will help you meet CAF outcomes B2.a (‘Identity Verification, Authentication and Authorisation’) and B2.c (‘Privileged User Management’).

The policy states that: 'The key words ‘must (not)’, ‘required’, ‘shall (not)’, ‘should (not)’, ‘(not) recommended’, ‘may’, and ‘optional’… are to be interpreted as described in RFC 2119.'  These interpretations are:

• ‘must’ means an absolute requirement of the policy
• ‘must not’ means an absolute prohibition of the policy
• ‘should’ (or ‘recommended’) means that there may exist valid reasons in particular circumstances to ignore the particular item, but the full implications must be understood and carefully weighed before choosing a different course
• ‘should not’ means that there may exist valid reasons in particular circumstances when the particular item is acceptable or even useful, but the full implications should be understood and the case carefully weighed
• ‘may’ (or ‘optional’) means that an item is truly optional.

These interpretations will be used in determining whether an organisation is compliant with the policy.

The same words in this guidance document have only their normal English meanings.

Multi-factor authentication (MFA) is an extremely effective control against a wide range of common cyber security attacks.¹ 

The intent of the policy is to increase adoption of MFA in that context, rather than as part of wider identity management.  Organisations with weak identity management practices are more vulnerable to identity fraud risks – if you do not verify the identity of a user before issuing them with a hardware MFA token, you will not change your risk that they are an impostor.  However, by enforcing MFA on your systems you still reduce the risks associated with other common attacks that compromise user credentials.  You should therefore not delay implementing basic MFA even if you have weak identity management practices.

This intent is also the rationale for permitting a wide range of authentication factors (see ‘Implementation’), as even weak second factors are effective against automated attacks.² You may be subject to other policies that impose stricter requirements about identity verification or authentication, such as permitting only certain types of authentication factor for certain systems.  This MFA policy does not supersede any such policies and should not be interpreted as justification to weaken authentication security in any particular case.

The policy requires that MFA:

• must be enforced on all remote user access to all systems; and
• must be enforced on all privileged user access to externally-hosted systems; and
• should be enforced on all privileged user access to all other systems.

The intent of the less strict wording on the last element is to permit organisations with many internal systems to make proportionate decisions about access that occurs wholly within a trusted corporate network.  For example, you may have a large number of small clinical systems that each have their own authentication mechanism.  However, use of the keyword ‘should’ means that “the full implications must be understood and carefully weighed” – this is a route for you to make proportionate risk decisions, not a blanket exception.  Protecting privileged internal access with MFA would severely limit the ability of an attacker to make meaningful gains within your network, such as by using a stolen password to access multiple systems.

Patients and people in care are excluded from the definition of ‘user’ individuals.  Accounts that are used solely by such people are therefore not in scope of the policy.

The intent of scoping “all services for which [your organisation] is the controlling recipient” is that the organisation controlling and receiving a particular system is responsible for compliance.  Some example scenarios are listed below.

In some cases you may have no practical control over the systems your organisation uses, such as systems procured nationally for which there is no alternative.  The policy is not intended to create enforcement traps, but rather to motivate collective effort towards better authentication.  Enforcement action will not be taken unreasonably.

Where you do have control and influence over systems, such as by being a paying customer, you should use that influence towards enabling and using MFA, working with your suppliers and supported by national supplier engagement initiatives.  Systems that cannot support any form of MFA can be excepted from the policy (see ‘Exceptions’) but you must have a plan to minimise or eliminate completely these exceptions, which in practice means that over time you must decommission, federate, or upgrade those systems.

You are not accountable under this policy for accounts on services that you provide in the role of supplier to another organisation.  However, as a matter of good security practice you should consider how you can help your customers manage their cyber security risk and comply with this policy, as they may be accountable under it for the services they receive from you.  A good system is likely to support multiple authentication factors, and preferably federated authentication, to industry standards.

Exceptions are provided to allow you to balance clinical and operational requirements with cyber security risk as you increase your deployment of MFA.  They are grouped into general and specific exceptions.

General exceptions may be used without needing to report or justify your reliance.  However, you should understand the increased risks you hold by relying on wide-ranging exceptions, and consider whether MFA is an appropriate control in these scenarios.  You are expected to take proportionate action on your cyber security risks irrespective of whether there is a specific national policy that compels action on a particular aspect – this policy is not the limit of your responsibilities for access control.

For example, the policy uses a narrow definition for ‘privileged user’ as meaning a systems administrator or having security-related functions.  You are likely to have other users with access to perform business-critical functions or to effect wide-ranging changes (such as finance users approving large payments, or software developers committing changes to code repositories).  You should consider whether it is appropriate to enforce MFA on these users in some circumstances even within your internal corporate network or the other general exception scenarios.

The general exceptions can be used to simplify your MFA deployment and improve user experience.  For example, if all your remote workers first join your internal corporate network by using a VPN before being able to access internal systems, then you must enforce MFA on the VPN access, but you would not need to enforce MFA on any of the internal systems.  For cloud systems, the exception for access to systems that have previously been authenticated with MFA means that staff do not need to use a second factor every time they log in from the same device – this is commonly implemented as allowing users to select “Don’t ask again for N days” or similar.

Specific exceptions should be used only when necessary, and you must justify them as detailed in the policy: 

• understand, document, risk-assess and internally approve (at board level or as delegated) all exceptions, with annual review
• have and actively pursue plans to minimise or eliminate completely the exceptions
• retain documentary evidence for audit purposes, and provide a summary within your DSPT submission

The summary in your DSPT return could be as simple as the number of systems or accounts for which each exception has been used, and copies of your risk assessments and exception minimisation plans.  Your internal documentation should be more detailed – for example, you should record the IP addresses of trusted external locations to allow regular review of firewall rules and conditional access policies, and you should know the systems used by excepted users to enable audit and monitoring activities as mitigation for the increased risk.

Annual review is required because you should not treat the exceptions as ‘get out’ clauses – they are intended to help you manage your cyber security risk alongside other operational considerations, all of which change over time. 

The exception for “situations in which MFA would create disproportionate clinal or operational risk” should be used cautiously.  You will need to be able to demonstrate that you have understood and weighed the cyber security risk of not enforcing MFA, and you must consider alternative controls and mitigations.

Permitted factors

All technical approaches to MFA are currently permitted.  It would be counterproductive for you to leave your organisation’s accounts unprotected for a protracted time while you pursue an “ideal” MFA solution – instead you should implement what is feasible, and improve it over time as you monitor and review the effectiveness of the controls you have in place.

The policy may be amended in future to make explicit recommendations, requirements, or prohibitions on certain factors.

Choosing factors

You should choose a factor – or more likely several factors – based on the circumstances of your organisations and users.  Stronger authentication types provide ‘better’ security, but may not be affordable or practical for all staff roles.

SMS and voice messages are a weak authentication factor, susceptible to unsophisticated attacks such as SIM swapping and number porting.³  You should use this type of factor only when no better alternative is available, and consider complementary controls such as monitoring if using it for high-profile individuals in your organisation who may be subject to targeted attacks.  (You should also consider advising such individuals to use stronger authentication on personal accounts as well.)  You cannot normally require staff to disclose or use personal telephone numbers or devices for work purposes, which will limit the extent to which SMS and voice could be used even if available on some systems.  In general, SMS or voice is better than no MFA, but you should understand the technical and privacy risks involved in using these factors, and have effective monitoring practices and improvement plans.

Application-based authentication includes one-time passwords (OTP) and push notifications.  They can be convenient in many situations, and the wide range of TOTP generator applications means that you do not have to provide or allow only one solution within your organisation.  Some implementations can be difficult for staff to maintain over long periods of time, such as when moving to a new smartphone. Push notifications require connectivity that may not be available in all scenarios, and are also vulnerable to ‘MFA fatigue’ attacks unless number matching or similar functionality is implemented.

FIDO and other public key hardware tokens (including NHS smartcards) provide the strongest authentication, highly resistant to phishing attacks, as they cannot be used to authenticate to systems on which they have not previously been registered.  NFC-enabled hardware tokens can provide fast, convenient authentication in busy environments such as emergency departments.

Biometric authentication is not given as an example in the policy, but is not prohibited.  However, you should consider the limitations of biometric authentication before deciding to implement it, including⁴: 

• biometric verification is probabilistic
• biometric characteristics cannot be revoked or changed if compromised.  (Biometric template protection schemes can allow biometric credentials to be revoked, but this is not yet a mature or standardised field)
• biometrics as special category personal data cannot be processed without additional data protection considerations, and consent is normally not valid in an employment context.

Most organisations will adopt several different factors for different staff groups. For example:

• staff with NHS smartcards already have a strong authentication factor supported by robust identity verification. NHS smartcards are typically cheaper than other hardware-based authenticators
• staff working in roles and environments with no device restrictions may be offered the ability to use an authenticator app on a corporate or personal smartphone, reducing organisational cost for purchase of other factors
• staff working in a prison may be able to use a hardware token that is kept on site, or you may decide to rely on a policy exception and not enforce MFA for access attempts originating from the prison computer’s IP address
• you may mandate FIDO tokens for privileged users, and offer them to other staff not covered by the previous options, including NFC-enabled tokens for clinical staff in your emergency department.

In practice your choices are likely to be limited by the capability of your systems to support different factors.

Federated authentication

Federated authentication can support both security and MFA deployment, by:

• improving user experience, as staff need only authenticate once to be able to access multiple systems, and only maintain one additional factor
• providing the security benefits of MFA to systems that do not otherwise support MFA
• reducing complexity for both users and administrators

Federating with the NHS Care Identity Service 2 is a recommended approach, as it provides strong identity assurance as well as a low-cost strong authentication factor (the NHS smartcard).  You may also be able to federate with NHSmail, your organisation’s Azure Active Directory, or another identity provider.

Novel approaches

Some authenticators can be used in ways that are not strictly multi-factor, such as the following examples which (depending on configuration) might all be accessed using only a password from the same untrusted device from which the user is attempting to log in:

• TOTP codes generated from a desktop or web application
• SMS and voice messages received through a software application
• single-use code sent to an email address registered to the user

The policy is not intended to require architecturally pure authentication concepts, but rather a meaningful reduction in security risk through the use of stronger authentication approaches.  When choosing factors in your organisation, consider how your staff can use them in practice and how that affects your overall authentication risks.  For example, web-based TOTP applications and email could themselves be protected by MFA using a separate device.

Choosing TOTP applications

If you choose TOTP codes as an authentication factor, you do not have to choose a particular generator application – staff will be able to use a wide range of compliant applications.

You may want to select a particular app to deploy to corporate devices, or to give as a recommendation to staff to simplify technical support.  In doing so, consider:

• ease of use – a simple dedicated app (such as FreeOTP+) may be easier to use than an app loaded with unnecessary features. Some apps enforce PIN access which can be counterproductive on devices that already have strong unlock protection
• protection and resilience – some apps (such as Microsoft Authenticator and Google Authenticator) may back up TOTP secret keys to unmanaged personal accounts.  Some apps may not allow secret keys to be exported or backed up at all
• unnecessary collection of personal data – some apps (such as Authy) require a telephone number to be registered, which may be unnecessary or impractical for staff without an issued corporate device
• password management – password managers improve security and user experience if your organisation has many systems with independent authentication.  Some password managers (such as KeepassXC and Bitwarden) can also generate TOTP codes.

The examples given are illustrative and are not national recommendations.

Personal devices

The ability to use personal devices (such as for authenticator apps) can be convenient and cost-effective, but you will normally only be able to offer this as an option, not as an expectation.

The use of personal devices should also be considered in your user management processes, as (for example) retrieving a smartcard is a simple method of blocking a leaver’s access in a way that cannot be done with an app on a personal smartphone.

Resilience and recovery

You should consider the resilience of your chosen factors and the options available to staff who have (for instance) lost their hardware token or smartphone.

Many systems offer recovery codes as a common fallback option, which is permitted by the policy.  Some systems allow users to configure multiple second factors, but it may not be realistic to require staff to adopt this kind of “self-resilience”.

When deciding what fallback options to use, consider their susceptibility to attack, particularly social engineering.  Some systems allow administrators to disable MFA enforcement for a particular user temporarily, which provides good resilience – but means that your service desk will need a proportionate means of verifying the user’s identity, else you are creating a simple route for an attacker to bypass MFA simply by making a phone call.

Working with partners and suppliers

The policy sets an outcome that MFA is enforced but does not prescribe how to achieve it, providing flexibility for you to consider different approaches that may support wider considerations.

For example, many of your staff may need to access applications in a partner NHS organisation, such as shared care records or pathology applications hosted in different organisations.  Working with your partner organisations to adopt a standardised approach to MFA can improve the experience of those staff – such as by using federated authentication to minimise MFA prompts, or by being able to use the same factor to access multiple systems.

In some cases your suppliers may be able to help you comply with this policy, such as by enforcing MFA on their managed remote access solutions.  You may have sufficient demonstrable assurance on their controls and practices to satisfy yourself that your obligations under this policy are met, even if you are not directly managing the technical system for doing so.