Authentication methods: choosing the right type
Recommended authentication models for organisations looking to move 'beyond passwords'.
This guidance helps organisations to select an appropriate method to authenticate their customers who are accessing online services. It's intended for retailers, hospitality providers and utility services, but can be used by any organisation that needs to authenticate customers when accessing online apps or websites. Adding any of the methods described here (that is, in addition to password authentication) will significantly increase the security of your customer accounts.
There are several authentication methods that provide security that goes 'beyond passwords'. This guidance summarises the benefits and limitations of each method, so you can choose the one that's most appropriate for your organisation - and your customers. It also provides links to more detailed NCSC guidance on each of the authentication methods.
Why go 'beyond passwords'?
Bill Gates predicted the death of the password nearly 20 years ago. Many assumed that alternative methods would replace them, but passwords remain the default method of authentication for a huge range of services, both at work and home. Password authentication is cheap, easy to implement, and understood by users. Password use continues to rise, mostly due to the adoption of online services and the massive growth in use of personal computers, smartphones and tablets.
Since the average user has so many online accounts, creating different passwords for all of them (and remembering them) is hard. Inevitably, users will devise their own strategies to cope with ‘password overload’. This includes using predictable patterns to create passwords, or re-using the same password across different systems. Cyber criminals can exploit these well-known coping strategies, leaving your customers and your organisation vulnerable.
- Research from Google found 52% of passwords are reused across accounts.
- More recently, World Password Day - Global Survey 2025 suggested password reuse amongst younger generations is over 70%.
- Data from FIDO indicates that passwords are the root cause for over 80% of breaches.
It also makes good business sense to introduce additional authentication methods. Some estimates suggest that as many as one-quarter of online purchases are abandoned due to forgotten passwords, as recovering passwords (or creating new accounts) can be a time-consuming process and will put off many potential customers.
How does additional authentication help?
Passwords can be stolen in a number of ways, but the most common way is when an organisation holding account details suffers a data breach. Criminals will use passwords stolen in the breach to try and access other accounts, a technique known as 'credential stuffing'. It works because many people use the same password for different accounts.
Cyber criminals may also use phishing techniques (either by email, text message or direct messages/chat) to try and access accounts, or simply try the really obvious passwords that millions of people still use.
Regardless of how they acquire passwords, unless you implement an additional method of authentication, cyber criminals can use stolen credentials to access users' accounts fraudulently. This might give them access to sensitive personal data (including financial data such as credit card details), or allow them to impersonate someone to carry out harmful actions. Adding a second additional method of authentication for customer accounts makes it much more difficult for a cyber criminal to do harm.
Note:
When setting your organisation's password policy, please refer to the NCSC's guidance for system owners. It explains how you can implement technical measures to reduce the burden on customers, and implement policies which support the ways in which people naturally work.
Chose the model that's right for you
This guidance looks at four authentication models:
- Multi-factor authentication (MFA)
- Federated Single Sign-On (SSO) services
- FIDO2
- Magic links and one time passwords
For each authentication method, you should consider both the security and usability of each one, and - most importantly - the profile of your customer base. For example, some customers may be reluctant to purchase additional devices in order to buy goods from your online store.
Although passwords have weaknesses, as a method of authentication it's both understood and accepted by most users. Whichever model of additional authentication you implement, you'll need to provide additional support for your users, during account setup and beyond.
You should offer a range of methods to ensure you appeal to as many of your users as possible. And offering these options during account setup provides an opportunity to explain the benefits of extra authentication, and how it works.
Multi-factor authentication (MFA)
The most common authentication method that goes 'beyond passwords' is to implement multi-factor authentication (MFA), which is also known as two-step verification (2SV) or two-factor authentication (2FA). Accounts that have been set up with MFA require the user to provide a second factor, which is something that only the user can access. The second factor can be:
- PIN codes or a string of characters, often sent to the user via SMS or email
- a physical security token that the user must 'present' to their device (such as via USB or NFC)
- biometric details (such as a fingerprint scan, or facial recognition)
- approval through an app on a trusted device (such as those provided by Microsoft or Google)
Note:
The most appropriate second factor to use during MFA implementation will depend on what services your organisation offers, and your customer profile. For example, using a PIN code sent via SMS is the most widespread and well-understood second factor, but is not the most secure option. Providing your users with a choice of second factors will ensure you cover the widest customer base. For more information about implementing MFA - including detailed guidance on choosing authentication factors - refer to the NCSC's guidance on Multi-factor authentication for online services.
You should not mandate use of a second factor every time an MFA-protected service is used, as this would soon be irritating for users. It should only be required for high-impact activities, such as:
- transferring large amounts of money
- changing passwords
- changing account details (including updating/adding credit card details)
A second factor should also be required whenever suspicious account activity is detected, such as a sign-in from an unfamiliar device, or from a different part of the world than is normal for that user.
Note that introducing MFA to online services will mean you need to provide additional support for your users, both during account setup and in the longer term (including what to do if users lose access to the second factor). The NCSC has produced guidance that can help your users get to grips with MFA. You can adopt this guidance to include in your own support materials, if required.
The following table summarises the conditions when implementing MFA are likely to be appropriate.
| MFA is likely to be appropriate when: | MFA is less likely to be appropriate when: |
|---|---|
| Security is of a higher priority than user experience and throughput. | User experience and throughput is a higher priority than security. |
| Your users are willing to provide an additional means of contact (phone or email). | Your users don't want to have additional contact information associated with your website. |
| Your users are confident using mobile devices, and able to identify an unexpected or false request. | Your users are not confident using mobile devices, and are unlikely to understand authentication messages. |
| You are able to provide a range of options for how a user can verify themselves. |
MFA: a typical scenario
You are a large online marketplace, with customers who buy and sell goods through your website. Due to the growth in password attacks (such as credential stuffing against many online platforms), you’d like to reassure your customers by adding extra security, so you decide to implement MFA on your accounts. You provide customers with a choice of factors; they can either use a code sent via SMS, or an authenticator app. Because you don’t want to overburden your customers, you only prompt them for the second factor when a new device or login location is detected.
A customer, Jean, sells hand-crafted items through your marketplace, and she's aware of phishing and credential theft affecting another online marketplace. Accounts have been taken over, and users have lost income and struggled to gain control of their accounts. Jean is concerned that she may be a victim of future attacks on your marketplace, and this could significantly harm her livelihood.
As part of the setup process for 2SV, you are able to reassure Jean that this extra measure will make it much less likely that her account will be vulnerable to these sorts of attacks.
Federated Single Sign-On (SSO) services
Federated SSO, based on protocols such as OpenID Connect (OIDC), allows a customer to use their sign-in for an existing account in one trusted service to sign in to another new service. This is usually a well-known service provider among users, such as Apple, Facebook or Google). This may also be referred to as Social Login. The ability to “Sign in with…” (or similar) removes the burden of creating another set of account details when signing in to a new website.
In addition, if a chosen federation provider has account security measures already in place, or adds stronger measures – such as common password banning, MFA or suspicious activity blocking – then the new service inherits these benefits for sign-in to their accounts. This means the new service is spared the cost and effort of duplicating development of these measures themselves.
But by the same token, if a cyber criminal accesses the account a customer has with a trusted federation provider, then they'll also have access to the connected accounts in the online services that use it for authentication. For this reason, you should consider the security posture of the provider – and the accounts they provide – and only select providers that demonstrate appropriate security. The NCSC's Cloud Security guidance includes advice to help you determine if a provider is 'secure enough' for your requirements.
You'll also need to consider the availability of your chosen federation provider(s). If a provider's authentication service experiences an outage, and it is a customer's only way of signing in to your online service, they will be unable to complete a new sign in until the outage is resolved (as demonstrated in the 2021 Facebook outage).
Even if you offer a selection of federation providers, some users will not want to associate an existing account with your new service. For these users, you should offer an alternate authentication method.
Implementing federated SSO
The following links describe how to implement federated sign-in for some of the well-known providers:
- Google: Sign in with Google using OpenID Connect
- Facebook: Facebook Login and Facebook Login using OIDC flow
- X (formerly Twitter): Sign in with X
- Yahoo: Yahoo developer guide for OpenID Connect
- Apple: Sign in with Apple
The following table summarises the conditions when offering OIDC are likely to be appropriate.
| OIDC is likely to be appropriate when: | OIDC is less likely to be appropriate when: |
|---|---|
| Ease of use is particularly important. | Assurance of account security is critical, and it would not be appropriate to rely on the security of an external OIDC provider. |
| You can have confidence in the OIDC provider's security posture and trustworthiness. | Your users do not want their connection to your service being known to the OIDC provider. |
| Your users are comfortable with their connection to your service being known to the OIDC provider. | Your availability or security requirements are higher than those of the OIDC provider(s) available to you. |
| The expected downtime of the OIDC provider(s) is acceptable. |
OpenID Connect: typical scenario
You are a major hotel chain with properties across the globe. Many of your customers have not stayed with you before, which means they would like to be able to sign in quickly, and book a hotel stay without having to set up a new account.
You decide to include OIDC authentication in your booking process. Jack, is a new customer, he doesn't have an account with you and needs to book a hotel room quickly. He is able to log in using his Google account, making the account creation and booking processes simpler and faster.
FIDO2
FIDO2 is a set of standards that define cryptographic authentication using public key credentials and protocols to provide more secure alternatives to passwords for accessing online services. FIDO2 authenticators can include:
- a personal device such as a smartphone or laptop with a trusted platform module (TPM)
- a physical USB key
They can be used for passwordless logins, or as a second factor.
Most FIDO2 tokens are USB-based - such as Yubikeys. There is a variety of FIDO2 authentication tokens available to suit various needs and budgets. Most modern smartphone apps can support FIDO2 as they have biometrics built-in to authenticate the user to the device. FIDO2 grants authentication via a user action such as entering a PIN, or presenting a known biometric (for example, a registered fingerprint or facial scan).
In the majority of cases, the customer would be responsible for purchasing the token. A lost token means that a customer would be unable to authenticate to the service they’re trying to access if they didn't have a backup, so they should register a backup (which may mean buying another token). Since relatively few services accept FIDO2, customers may be reluctant to purchase one or more tokens (given that there are alternative cheaper and more widely-used forms of authentication). A lost token will also need to be revoked, which requires the customer to log into every service with the backup token to remove the lost one.
Whilst major phone and computer vendors are enabling FIDO2 natively on their devices (enabling the automatic sharing of tokens across user devices on their platforms), there are still several barriers to adoption, including usability and upfront cost.
Implementing FIDO2
The FIDO2 website contains information to help developers implement FIDO2 authentication. Since FIDO2 uses public key cryptography, developers should have experience of implementing cryptographic protocols - even if they don’t have experience of implementing a FIDO2 login directly.
The following table summarises the conditions when implementing FIDO2 are likely to be appropriate.
| FIDO2 is likely to be appropriate when: | FIDO2 is less likely to be appropriate when: |
|---|---|
| Security is more critical than ease of use. | Security isn’t highly critical, and user experience and throughput is of equal importance. |
| You have a security-conscious user base, who understand the need for high security. | Your users don't consider security of the account important, and are deterred by the need for a second factor. |
| You are in a position to provide users with an authenticator app or security token, and not reliant on users doing this. | Your users are unlikely to own a smartphone, or would be reluctant to purchase their own security tokens. |
| If a user loses their access token, you have time to recover their accounts. | If a user loses their access token, you need to recover their accounts immediately. |
FIDO2: a typical scenario
As a major video gaming company running multiple online games, your customers' accounts hold real world value in digital assets (such as virtual items, levels, and in-game currency). There have been cases where cyber criminals have used leaked password databases to hack individual accounts and have stolen these digital assets from legitimate users, causing reputational damage to your company.
One of your competitors offers services to make customer accounts more secure using a FIDO2-based authenticator app. To compete, you consider offering in-game rewards to anyone logging on to the site with a FIDO USB token or authenticator app, but these are not consistently collected by your high-value customers due to their relatively low in-game value. Instead you decide to manufacture branded FIDO2 USB tokens and offer them for free as a reward for reaching a particular high level in one of your games.
These FIDO2 USB tokens come to be seen as a status symbol within the community - and your highest-value customers are keen to qualify for one. Once they receive the token, they are motivated to use it to log into the site. This means the accounts containing the highest value of digital assets are the ones most likely to be protected against password-based attacks.
Magic links and one time passwords (OTPs)
Magic links are a type of passwordless login that allows a customer to log in by clicking a link that has been emailed to their registered address, rather than typing in their username and password. Once the user follows the link, by clicking or copying-and-pasting it, they are automatically signed-in to their account in the service.
OTPs are similar to magic links in that the customer doesn't need to create or remember a password. Instead users:
- receive an SMS or email containing a single-use password to sign-in with
- are asked to generate an OTP using an app
Magic links and OTPs provide an easy user experience and remove the need to manage forgotten passwords or password breaches. However, if a cyber criminal has access to a user's phone they may be able to access the accounts associated with that phone, including email and SMS notifications and/or messages.
Implementing magic links
- Okta: Sign users in with Email Magic Links
- Auth0: Passwordless authentication with magic links
- PingIdentity: Magic Link Integration Kit
The following table summarises the conditions when implementing magic links and/or OTPs are likely to be appropriate.
| Magic links and OTPs are likely to be appropriate when: | Magic links and OTPs are less likely to be appropriate when: |
|---|---|
| Security isn’t highly critical, and user experience and throughput is of equal importance. | Security is the most important factor, and the security posture of the mobile network or email provider is inappropriate. |
| Your users are willing to provide an additional means of contact, such as email or phone number. | Your users are reluctant to provide an additional means of contact, such as email or phone number. |
| Your users are likely to be confident using mobile devices, and able to identify an unexpected or false request. | Your users aren't confident using mobile devices, and are unlikely to understand authentication messages. |
Magic links: a typical scenario
You run a market comparison site. Your customers use your website a couple of times a year when they need to look for the best deals on insurance, utilities or broadband. Since they don't use your site frequently, you decide to implement magic links so they can log on quickly without having to remember a password.
Meg stopped using a rival market comparison site after she forgot her password and became frustrated with the password reset process. However, when she returned to your site she was only asked to enter her email address. In a few seconds an email appeared in her inbox, and once she'd clicked on a link inside it, she was automatically logged into the site.
