Design

Checking users’ identities

Checking a user’s identity is known as ‘identity assurance’. It tells you how likely it is that:

  • the person the user is claiming to be is real
  • the user is the person they’re claiming to be

If your service needs to know either of these things, you’ll probably need to check your users’ identities. This can help you find out if your users are:

  • eligible to use your service
  • allowed to access any data the government holds about them

Checking a user’s identity online is usually the quickest and most convenient way for them to prove who they are.

Find out what checks you need to do to prove and verify someone’s identity.

Authentication

Identity assurance is different from ‘authentication’, which is about how a user signs in to something. A user can usually do this without proving who they really are.

A user needs an ‘authenticator’ to sign in to a service, for example a password.

Find out which authenticator you should use to protect your service.

You can also use an authentication pattern like a user account if you need to recognise that a user has used your service before. Read about helping users create accounts in the GOV.UK Design System.

How identity assurance can help your service

Checking users’ eligibility

You cannot usually tell if someone’s eligible to use your service just by checking their identity. But you can combine identity checks with other proof a user provides if you need a high level of confidence they’re telling the truth.

Most services check whether people are eligible to use a service by asking them for information about themselves. Sometimes it’s okay to simply accept what the user tells you, but if you need to be more confident you can ask for evidence to back up the information they’ve given.

Asking for evidence helps prevent ineligible users from accessing your service by providing false information. For example, asking for a payslip as proof of how much someone earns means you can check if their income is below a certain threshold.

Identity assurance can help you be sure the user has actually given you evidence that’s about them, not about someone else who might also be eligible. Do this if you need to be confident a user is not:

  • using a ‘synthetic’ (made up) identity that would be eligible to access your service
  • impersonating someone else who is eligible

How confident you need to be in the user’s identity depends on how much risk your service can accept. For example, you might accept more risk if your service provides users with something of relatively low value. You might accept less risk if you offer something of high value that might be more likely to be targeted by fraudsters, such as money or a licence.

There are other ways to check users’ eligibility. For example, you could check if information about the user matches data from another source. This will give you an idea if the user is who they say they are, but it will not prove their identity.

Letting users access data

You must protect data you hold about users. Remember that a fraudster might use even basic data they can get from your service to commit a more sophisticated fraud elsewhere.

Check a user’s identity before you let them access data the government holds about them. For example, users need to prove their identity before they can view their tax records using their personal tax account.

This does not include data users save in an application form they’re planning to return to later - use a secure ‘save and return’ pattern like a user account instead.

You can also let users share data without conducting further checks on the people or organisations they share it with. For example, the Driver and Vehicle Licensing Agency (DVLA) lets third parties view a person’s driving licence information if they have a ‘check code’ from that person giving them permission.

Under the General Data Protection Regulation (GDPR), you need to be sure your service is collecting and sharing this information under the right legal basis. You’ll also need to check the identity of the person giving permission to make sure they’re the same person the data relates to.

Ink signatures can prove a particular person agrees to, authorises or confirms something. That person will usually have to prove their identity before they sign anything.

If you check someone’s identity online, you might also be able to accept an electronic signature. These can replace ink signatures as a way to show that the user agrees to something online.

Read the guidance about electronic signatures to find out how you can use them in your service.

Using electronic signatures can help your service meet the electronic identification and trust services (eIDAS) regulation. An electronic signature will usually give you a ‘low’ level of assurance that the user is who they say they are. If you want to meet a ‘substantial’ or ‘high’ level of assurance, you might need to create a digital certificate first.

You can check identity at any point in your service - not just when the user applies

You can do identity checks at any point in your service - when users first apply, after they’ve applied or at the end of a user’s interaction with you.

When you should check depends on what your service does and how much risk you are willing to accept.

For example, if your service needs to pay money to a user, you need to be sure the money will go to the right account before you make the payment. You could check the user’s identity and match their details with the details of the person the bank account is registered to.

You might not need to check a user’s identity before they use your service, but might need to eventually know they are who they say are. You can build up confidence in a user’s identity over time at the different points that they naturally interact with your service.

Levels of assurance

Some products and services will check identities to a certain level of assurance (LOA).

Although different identity checking products and services describe their LOAs in different ways, the LOA will usually depend on:

You must choose an LOA that’s right for your service.

Different parts of your service might need a different LOA. For example, a service might need to be less confident that a user is who they say they are when they create an account, but more confident when that user decides they want to apply for something.

In this case, the service could use a lower LOA during the registration process, and increase it when the user starts their application.

Last update:

Clarified guidance on levels of assurance

  1. Guidance first published