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 incorporated as a requirement within the Data Security and Protection Toolkit (DSPT).

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 MFA even if you have weak identity management practices.

You are expected to take proportionate action on your cyber security risks irrespective of whether a specific national policy 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 scenarios in which general exceptions are permitted.

The policy requires that you:

• must enforce strong MFA on all remote user access to all systems; and
• must enforce strong MFA on all privileged user access to externally-hosted systems; and
• should enforce MFA 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. By federating the authentication of each of those systems against a single identity platform, you can also improve staff experience as well as better securing them.

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.

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 virtual private network (VPN) before being able to access internal systems, then you must enforce strong 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 apply and justify them as detailed in the policy. This means that you:

• understand, document, risk-assess and internally approve (at board level or as delegated) all exceptions, with regular 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
• consider alternative controls and mitigations for the security risk whilst the exception is maintained

The summary in your DSPT return should use the template provided. 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 any individually-excepted users to enable monitoring and other mitigations for the increased risk.

Regular 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 policy further requires that you must 'have and actively pursue plans to minimise or eliminate completely the exceptions'. This implies that you should not take active steps to increase your reliance on exceptions, such as by procuring systems that do not support MFA (or federated authentication against an MFA-capable identity provider). Any of the permitted exceptions may be removed in future revisions to this policy.

The exception for 'situations in which strong MFA is not feasible' is provided to help you migrate your systems to strong MFA (and phase out the use of basic MFA in a managed way) without immediately falling into an enforcement trap. If you rely on this exception, you must enforce alternative MFA or apply a further permitted exception to that requirement. However, you should understand that the regulatory view expressed through this policy is that strong MFA is a necessary and proportionate control against the threat faced by health and care organisations. Reliance on this exception might normally only be expected for:

• a reasonable and well-defined period of time to migrate a system from basic to strong MFA
• supporting a transition to strong MFA that is planned to occur shortly after the DSPT submission deadline
• excessive cost levied by a supplier to enable strong MFA or federated authentication within the DSPT submission year
• non-human identities for which hardware-bound certificates or similarly strong authentication are not currently feasible

Exceptions are ultimately provided to help you avoid enforcement traps and improve your MFA deployment over a reasonable period of time, not to provide you with a long-term excuse for failing to protect your systems appropriately.

Choosing factors

The policy sets expectations on the strength of authentication rather than on individual technical implementation choices – it does not (for example) require the use of passkeys, or of ‘passwordless’ authentication. You should choose types of authentication factors, and specific authenticators, based on all the circumstances of your organisation and staff.

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 assessing a particular implementation for your environment, consider the security outcome that it would give you, the other risks that the implementation might create, and the methods by which it might be attacked or subverted.

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.

The policy makes no requirements about FIDO authenticator certification levels, so a ‘Level 1’ FIDO authenticator is valid for the purposes of complying with the policy. You may want to consider higher certification levels for particularly sensitive or high-risk systems.

The policy also makes no requirements about FIDO authenticator attestation, so authenticators without attestation (including synced passkeys) are valid for the purposes of complying with the policy. If you do use attestation, you should do so in a way that protects user privacy (such as not requiring any identifiers unique to the authenticator).

Other certificate authentication can include mTLS and other device-based certificates. Hardware-bound certificates within a TPM or similar can be considered ‘strong’ for the purposes of the policy. Other implementations will vary in strength.

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

Therefore, when using FIDO-compliant authenticators that support biometric authentication (such as ‘Windows Hello for Business’), you should allow staff an alternative to using biometrics – such as a PIN.

Application-based authentication includes one-time passwords (OTP) and push notifications. They can be convenient in many situations, and the wide range of time based one-time password (TOTP) generator applications means that you do not have to provide or allow only one solution within your organisation, but they are not considered ‘strong’ as they are not resistant to phishing. Some implementations, such as TOTP within a password manager, can provide partial resistance by matching against a defined URL, but this can be overridden by users so is vulnerable to social engineering or malware.

Short message service (SMS) and voice messages are a weak authentication factor, susceptible to phishing and 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 robust monitoring practices and improvement plans.

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
• other staff may use a password manager that supports both synced passkeys and TOTP authentication against multiple systems, simplifying user experience during migration from basic to strong MFA
• 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 FIDO2 security keys (device-bound passkeys stored on physical authenticators) 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. Where you rely on basic (not phishing-resistant) MFA, you may only do so under the permitted exception for 'scenarios in which strong MFA is not feasible', and with an active plan to minimise or eliminate completely your reliance on that exception.

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 NHS.net Connect, your organisation’s instance of Microsoft Entra ID, or another identity provider.

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.

Password managers

Credential managers (also known as password managers) can be a useful tool in deploying MFA. Good credential managers can support both passkeys and TOTP authentication, providing a consistent and familiar software interface to staff during your migration from basic to strong MFA.

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.

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'. Synced passkeys, such as those supported by good credential managers, can improve resilience and staff experience by being usable from multiple devices.

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 authenticating users, 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 strong MFA is enforced but does not prescribe how to achieve it, providing flexibility for you to consider different approaches to accommodate 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 authentication factor to access multiple systems.

In some cases your suppliers may be able to help you comply with this policy, such as by enforcing strong 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.