Guidance

How to use authenticators to protect an online service (1. 0) pre-release

Published 3 March 2026

0. Version and certification validity notes

0.a. This 1.0 publication of ‘How to use authenticators to protect an online service’ (‘GPG 44’) is valid from [date of the final publication] to coincide with the date the 1.0 publication of the UK digital verification services trust framework (‘trust framework’) comes into force.

0.b. Services demonstrating compliance with GPG 44 as part of certification against the 1.0 trust framework must comply with this version of GPG 44. You should refer to the version and certification validity notes in the trust framework to understand which version(s) of the trust framework you can undergo certification against.

0.c. This is the first version-controlled publication of GPG 44. The most recent non-numbered version of GPG 44 (titled ‘Using authenticators to protect an online service’) can be found on GOV.UK and is, from the date of this publication, to be considered as the 0.4 version of GPG 44.

1. The authentication process

1.a. You might need to know if someone has already used your service before you give them access to it. A process which does this is called ‘authentication’. It can be useful if users need to sign in to your service more than once.

1.b. The authentication process depends on users having at least one ‘authenticator’. An authenticator could be some information (like a password), a piece of software, or a device.

1.c. This guidance will help you choose an authenticator that will give you the level of protection that’s most suitable for users accessing your service. It describes a methodology for assessing the level of protection achieved by authenticators of different types and of different quality. This guidance has been produced for digital verification service (DVS) providers, but others may consider that its contents are instructive for assessing authentication in a wider context.

1.d. This guidance is maintained by the Office for Digital Identities and Attributes (OfDIA), which sits within the Department for Science, Innovation and Technology (DSIT) and is produced as an exercise of DSIT’s functions. If other government departments want to apply the guidance to their functions, they should ensure it does not cut across any applicable legislation or statutory guidance that may be relevant.

1.e. DVS providers must follow this guidance to be certified against the trust framework as a holder service provider (HSP). A component service provider (CSP) who performs part of an authentication process may also need to follow this guidance to be certified.

1.f. You might also need to check a user’s identity if your service gives them something valuable or lets them access personal information.

2. Different types of authenticators

2.a. There are different types of authenticators. An authenticator will usually be one of the following:

2.b. Sometimes an authenticator can fit into more than one of these categories.

Example

A password is something the user knows. If the user writes it down on a piece of paper, it will also become something the user has. The piece of paper is now the authenticator because it contains information that previously could not be known by anyone apart from the user.

2.1. Something the user knows

2.1.a. The most common way for users to sign in to a service is by entering a piece of information that only they know. This is called a ‘secret’.

2.1.b. A secret could be something like:

• a PIN;
• a password; or
• an answer to a question that only the user knows the answer to, which is also called knowledge-based verification (‘KBV’).

2.1.c. A secret is one of the easiest ways for someone to sign in to a service, as a user does not need any special equipment or software to use it. But secrets can be easily:

• stolen, for example in a phishing attack;
• guessed, for example if the password or PIN is low quality (like ‘1234’);
• found out, for example if the answer to a KBV challenge is publicly available; or
• shared, for example if the user gives the secret to family and friends.

2.1.d. Read the National Cyber Security Centre’s (NCSC’s) guidance to find out how your service can use passwords.

2.1.e. In order to be more secure, a secret is usually used with either:

• another piece of information, such as a username or email address; or
• a token, such as a chip and PIN card.

2.1.f. You might need to use a different type of authenticator if you need greater assurance that the user who’s trying to sign in is the same person who created the account.

2.2. Something the user has

2.2.a A user might be able to sign in to a service using something called a ‘token’. A token can be something physical, like a chip and PIN card or a mobile phone.

Example

A user can sign in to a service with a physical security key by inserting it into their computer or tapping it against their phone. This proves that someone is present when they’re trying to sign in to a service.

A token can also be something digital, like a single use authentication code or a digital certificate.

Example

When a user adds an electronic wallet app to their mobile phone, a digital certificate is created and stored securely within their phone. This digital certificate is the token. When a user pays for something using their phone, the bank checks the digital certificate. If the bank is sure the phone is the same device the user installed the app on, it will approve the transaction.

2.2.b. Using a token by itself might not be appropriate if your service needs a high level of protection. This is because tokens can be easily lost, stolen or shared.

2.2.c. A token can also be copied or tampered with if:

• it does not have any security features; or
• the security features it has have been badly designed.

2.2.d. A token can only confirm that someone is there, which can help protect your service from remote attacks. Unless you combine it with biometric information, you cannot be sure that a token is being used by the same person that created the account.

2.2.e. Some tokens can contain information about:

• the person that’s using it to sign in to the service; or
• the organisation that issued the token (for example a chip and PIN bank card will include the name of the bank that issued it).

2.3. Something the user is

2.3.a. A user might be able to sign in to a service using their biometric information. Biometric information is a measurement of someone’s:

• biological characteristics, such as their fingerprint; or
• behavioural characteristics, such as their signature.

Example

A user can look at their phone to open an app or unlock the phone.

The app or device uses facial recognition software to check the user looks like the person who created the account or registered the phone. If there’s a match, the user can access the service.

2.3.b. Using biometric information you know belongs to the person who created the account means your service can tell if the user who’s trying to sign in is the same person who created the account. This is because:

• each person’s biometric information is unique to them; and
• it’s difficult for biometric information to be forgotten, lost, stolen or guessed.

2.3.c. You could read the NCSC’s guidance to find out more about how biometric information can be used to access a service.

2.3.d. There are some risks to using biometric information as an authenticator. A fraudster could attempt to impersonate someone by recreating their biometric information. For example, they could:

• hold up a photo of the user;
• wear prosthetics or a mask to make themselves look like the user;
• play a recording of the user’s voice; or
• use a copy of the user’s fingerprint.

2.3.e. These are called ‘presentation’ or ‘spoofing’ attacks. Although attacks can be detected by the system that’s used to capture biometric information, there’s always a risk a fraudster could successfully sign in to a service this way. Some types of biometric information will be easier to recreate than others.

2.3.f A fraudster could also supply untrusted biometric information or media into an authentication process, for example by injecting a falsified image of a user, a forged video of a user, a morphed image, or a deepfake. This is known as an ‘injection attack’. 

2.3.g. It’s also possible that the system can make a mistake when it’s matching someone’s biometric information. It could either:

• wrongly match a user to another person (called a ‘false match’); or
• not be able to match a user to anyone, even though a record of their biometric information exists (called a ‘false non-match’).

2.3.h. It’s easier to make these mistakes when matching some types of biometric information than others. You can lower these risks by asking users to use another authenticator as well as their biometric information.

3. Two-factor authentication

3.a. You can protect your service using a combination of two authenticators. This is called ‘two-factor authentication’ (‘2FA’). It helps protect your service against some of the risks that come from using just one type of authenticator.

Example

A user can sign in to a social media account using a username and password (something they know) and an authentication code sent to their mobile phone (something they have).

If a user could sign in without the code, there’s a risk that someone else could guess or steal their password to access their account. Using an authentication code as another authenticator means that, even with the password, a fraudster would still not be able to access the account.

3.b. It’s important that you use two different types of authenticators. A fraudster who’s able to compromise one authenticator is likely to be able to compromise another of the same type using a similar method.

Example

A fraudster can guess both a user’s password and their PIN. This is because they’re both the same type of authenticator (a secret). Fraudsters know users will often use personal information, such as their date of birth, to create them.

3.c. You can choose to protect your service using more than two authenticators. This is called ‘multi-factor authentication’. If you do this, you should be aware that it can have an impact on the usability and cost of your service.

4. The quality of an authenticator

4.a. An authenticator can be low, medium or high quality. The quality of an authenticator will depend on how secure it is.

4.b. The most secure authenticators have a strong link to the user. This means it’s difficult for someone other than the user who created the account to guess, copy or make changes to the authenticator.

4.c. High quality authenticators are also protected against ‘large scale’ attacks. These are automated attacks that use large databases of stolen or weak authenticators to try to break into users’ accounts.

4.d. The quality of an authenticator will depend on how it was:

• created by a user (or a manufacturer if it’s something like a physical token);
• managed (including how the authenticator is issued and updated, and what happens when it’s no longer being used); and
• captured (if it’s biometric information).

4.e. Some types (or ‘modalities’) of biometric information are higher quality than others. Read the NCSC’s guidance to find out how to pick the right biometric modality for your service.

4.1. Low quality authenticators

4.1.a. A secret is low quality if it’s one of the following:

• a password;
• a PIN; or
• a KBV challenge based on information that does not change over time (known as ‘static’ information).

4.1.b. A token is low quality if you do not know how it was created or issued. This is because there could be a risk it was tampered with or issued to someone who should not have it.

4.1.c. Biometric information is low quality if you do not know how it was captured or processed. Using low quality biometric information might mean your service is at risk of being attacked.

4.1.d. For example, if your service is checking a facial biometric, you might be at risk of attack if you let a user upload a photo that they previously took of themselves. This is because a fraudster could use a photo of the user that they found on social media. It would be more secure to use ‘live capture’, which involves asking the user to take a photo on their webcam or phone and upload it as they use your service.

4.1.e. Using low quality biometric information could also stop you from doing an accurate biometric comparison, which means you might not be able to match the right person to a record.

4.2. Medium quality authenticators

4.2.a. A secret is medium quality if it’s either:

• automatically created and securely stored (for example in a password manager); or
• a KBV challenge based on information that changes over time (known as ‘dynamic’ information).

4.2.b. A token is medium quality if you know tokens are created in a way that stops them from being:

• tampered with; and
• issued to the wrong person.

4.2.c. You may be able to find out whether this is the case from the manufacturer or supplier of the token. For example, a manufacturer might have published a report or white paper that documents how the token was created.

4.2.d. Syncable authenticators (for example, ‘passkeys’) built on W3C’s Web Authentication specification and FIDO’s Client to Authenticator Protocol (CTAP) standard are an example of medium quality tokens.

4.2.e. Biometric information is medium quality if you know the system that captured it when the user created an account can detect spoofing or presentation attacks. You may be able to find out whether this is the case from the manufacturer of the system. For example, they might have published a report or white paper that describes how the system detects presentation attacks.

4.3. High quality authenticators

4.3.a An authenticator is high quality if it could not belong to anyone other than the user who created the account. A secret cannot be a high quality authenticator because it’s easy for someone to steal, guess or copy.

4.3.b. A token is high quality if it has been independently tested by an ISO/IEC 17025 accredited testing laboratory recognised by the International Laboratory Accreditation Cooperation (ILAC) mutual recognition agreement to prove it meets industry standards, such as the Common Criteria guidelines, FIDO or NIST FIPS 140.

4.3.c. Biometric information is high quality if the system or process used to capture it has been independently tested by an ISO 17025 ISO/IEC accredited testing laboratory recognised by the ILAC mutual recognition agreement to check if it meets industry standards such as the following:

• ISO/IEC 19795-1 and 19795-10 for performance;
• ISO/IEC 30107-1 and 30107-3 for presentation attack detection; and
• CEN TS 18099 for injection attack detection.

4.3.d. This will prove that the technology can protect your service from spoofing and injection attacks, and meets accuracy assessment requirements, including demonstrating no bias against any demographic group.

5. Choosing an authenticator

5.a. An authenticator can protect your service from being accessed by someone who should not be able to use it. How much protection your service needs depends on:

• what information the user needs to use the service;
• what information the service gives the user access to; and
• what the service or user can do with that information.

5.b. When choosing an authenticator, you should also think about how much risk your service can accept. You should do a risk assessment if you do not already know this.

5.c. You get different levels of protection by using different authenticators or combinations of authenticators.

5. d. You must consider the needs of your users when you choose authenticators for your service. Some users might struggle to use an authenticator that others find easy to use. For example, accessing an app using a fingerprint can be easy for a lot of users, but it would be very difficult for someone who has lost the use of their hands.

5.e. You must provide more than one way your users can sign in to your service. This is particularly important if using syncable authenticators as not all users will find this technology fits their situation, e.g. they may not have a device that can store one.

5.f. Some users might not be able to access your service online. If there are other ways to access your service, you must assess its level of protection and ensure the level meets your service’s needs.

5.1. Low protection

5.1.a You might need low protection if the information that’s shared between the user and your service cannot be used to:

• get anything valuable; or
• do any harm to the user if it’s seen by someone else.

5.1.b. You’ll have low protection if you protect your service with any low quality authenticator.

Example

A wifi network in a public place can usually be accessed with an email address and a password (something the user knows).

The service does not need to be protected by a more secure authenticator than this because it only gives users access to the internet. If a user had unauthorised access to the network, it’s unlikely they’d be able to use any information they get from the service to do any harm.

5.2. Medium protection

5.2.a Your service might need medium protection if it gives users access to sensitive information.

5.2.b. Medium protection means your service knows:

• the authenticator is being used by the person who created the account; and
• any information (such as bank data in a chip and PIN card) is securely stored in the authenticator and has not been tampered with.

5.2.c. You’ll have medium protection if you protect your service with 2FA. Use two different authenticators from the following list:

• a low or medium quality secret;
• a low or medium quality token; or
• low or medium quality biometric information.

Example

A user will usually need to use 2FA to sign in to their email account. They might need to enter their email address and password (something the user knows) and an authentication code that has been sent to their mobile phone (something the user has)

The service is protected by 2FA because it gives users access to emails. These could include sensitive information from their doctor, bank or family.

5.2.d. Alternatively, a syncable authenticator built on W3C’s Web Authentication specification and CTAP can provide medium protection on its own where the authentication makes use of ‘user verification’ as specified in CTAP.

5.3. High protection

5.3.a. Your service might need high protection if it lets users access information that could be used to cause harm. This could be to another user, service or organisation.

5.3.b. If your service has high protection, you can be sure that the authenticators will not be used by anyone apart from the user who created the account.

5.3.c. You’ll have high protection if you protect your service with 2FA that uses a medium quality authenticator and a high quality authenticator.

5.3.d. Even with ‘user verification’ as specified in CTAP, a syncable authenticator cannot provide high protection or above without additional factors because there are scenarios where a syncable authenticator might be shared or where other users might have access to an account that stores it.

Example

A user can access their online bank account using a fingerprint (something they are) to sign in to an app on their phone (something they have). They will only be able to sign in if the app can confirm the fingerprint and phone belong to the same user that created the account.

The fingerprint is a high quality authenticator. This is because it has been captured by a system with a documented process for capturing and checking biometric information, that has been independently tested to check it meets industry standards by an appropriately accredited testing laboratory.

5.4. Very high protection

5.4.a. Your service might need very high protection if it lets users access information that could be used to cause significant harm. This could be to another person, service or organisation. You should use it if the information your service keeps is more sensitive than information kept by a service with high protection.

5.4.b. You’ll have very high protection if you protect your service with 2FA that uses a high quality token and high quality biometric information.

5.4.c. Very high protection gives you more confidence that the authenticators will not be used by anyone apart from the user who created the account.

5.4.d. This is because you’re using two high quality authenticators, which will have been protected from being attacked when they were created or issued. You’ll be sure that any information stored in the authenticator cannot be changed by someone other than the user or the organisation that issued it.

Example

Some organisations might need access to sensitive or personal information about their customers. To do this, employees could use a combination of:

• a certificate-based smart card (something the user has); and
• their fingerprint (something the user is).

These are two high quality authenticators. The smart card is protected by cryptographic security features which means it’s difficult for someone to copy or tamper with it. A fingerprint is unique to that user and will be stored in the chip in the smart card.

The service needs very high protection because it gives employees access to sensitive information. If someone other than an employee managed to sign in to this service, they could use the information to do harm to a customer. This could also cause damage to the organisation’s reputation by showing that their process is not secure.

6. If an authenticator has been forgotten, lost or stolen

6.a. You must give users a way to access your service if their authenticator has been forgotten, lost or stolen. If you issue a replacement authenticator, you must make sure that the person you give the replacement authenticator to is the same user who first created the account.

6.b. You could do this by using:

• information that you know was given to the user when they set up the account (such as a backup or recovery code); or
• contact details that you know belong to the person who set up the account (such as their email address or phone number).

Example

A user has forgotten their password but still has access to the email address they used to set up their account. A service can use this email address to send them a link to a page that tells them how to reset their password.

6.c. You might need to be more confident that the user is the same person who created the account if all of their authenticators have been forgotten, lost or stolen. You could do the same checks you would do to make sure an identity belongs to the person who’s claiming it.

7. If an authenticator has been revoked

7.a. You might need to temporarily stop a user accessing your service if you think their authenticator has been compromised.

7.b. You must:

• ask the user to use a new or different authenticator, if it’s a secret; and
• cancel (or ‘revoke’) the authenticator and issue a new one, if it’s a token.

7.c. As biometric information is a measurement of someone’s biological or behavioural characteristics, you will not be able to revoke it or issue a replacement authenticator if it’s compromised.

8. Monitoring how users use your service

8.a. As well as making sure you give the right users access to your service, you must also look out for any unusual activity once they’ve signed in. This is called ‘transaction monitoring’ and will help keep your service and your users’ data secure.

8.b. For example, it can protect your service from ‘authenticator stuffing’. This is when a large number of usernames and passwords taken from compromised websites are automatically used to try to get access to a service.

8.c. You must follow the NCSC guidance on transaction monitoring.

8.d. You could look at who’s signing in to your service and look for information like:

• their name or another identifier (such as their username or email address);
• their IP address, to find out where they are; or
• what device they’re using.