Skip to main content

Using CIS2 with CIS1 for API access

Learn about how to use CIS2 alongside CIS1 when accessing our APIs.

Overview

CIS1 Authentication is our original service for healthcare worker authentication. It works exclusively with NHS smartcards.

CIS2 Authentication is our strategic service for healthcare worker authentication. It works with NHS smartcards, but also provides a number of more modern alternatives such as iPad authentication and FIDO2 authentication for Windows 10 tablets.

Some of our newer APIs, such as the Personal Demographics Service FHIR API, require the end user to authenticate using CIS2 Authentication.

If you want to use such an API, and you are already using CIS1 Authentication in your application, you have two options:

  1. move your application to CIS2 Authentication (recommended)
  2. use CIS2 Authentication alongside CIS1 Authentication

Using NHS CIS2 Authentication alongside CIS1 Authentication

You can use NHS CIS2 Authentication alongside CIS1 Authentication for API access. Here's how it works:

  1. The user authenticates using CIS1 Authentication - signing in using their NHS smartcard and PIN. To do this, your application interacts with our Identity Agent - the client-side component of CIS1 Authentication.
  2. Your application uses our API authorisation service to get authorised to call our APIs. We have two different patterns for this depending on your needs - combined authentication and authorisation and separate authentication and authorisation.
  3. During the authorisation journey, the user is sent on the CIS2 Authentication journey. This is a browser-based user journey. Under the covers, the browser interacts with the client-side Identity Agent.
  4. Because the user has already signed in with CIS1 Authentication, the Identity Agent knows this, and the user is not asked to sign in again. The user does, however, see browser redirects during this process.

If your application runs on the client, not in a browser, you need to implement browser integration to handle the authorisation journey. You can do this either by embedding a browser panel or by launching a separate browser.

To summarise, the user experience is:

  • the user only has to sign in once
  • in a browser-based application, they might see their browser redirecting to the authorisation service and back
  • in a client application, they might see a browser being launched and closed

Last edited: 8 January 2026 1:48 pm