Register to access an environment
Gain access to our Path to Live and production CIS2 Authentication environments.
Overview
We provide the following CIS2 Authentication environments:
| Environment | Usage |
|---|---|
| Mock authorisation service | Early developer testing (primarily when integrating with national APIs); automated testing |
| Integration (PtL) | Development and integration testing |
| Deployment (PtL) | Not our preferred environment, but still used by some suppliers for testing and end user training |
| Production | The production environment |
To access one of these environments, you’ll need to register your application with us.
For testing in our Path to Live (PtL) environments, you’ll also need to set up:
- test users
- authenticators
- client devices
How to register
PtL environments
To register your application in one of our PtL environments, you can use our online tool, Connection Manager.
To access Connection Manager, send us your Team ID as detailed in the document 'Providing your Team ID' that was included in the 'Welcome to CIS2' email you would have received when you applied to use CIS2 Authentication.
Once you have access to Connection Manager, use it to enter the registration information.
Production environment
To register your application in our production environment:
- Gather the relevant registration information.
- Send it to us.
Registration information
When you register, you’ll need to tell us the following information:
| Information | Comments |
|---|---|
| Redirection URIs |
Used during the authentication request and the token request. Should use the HTTPS scheme, except for native applications that handle their own localhost callback. Examples: |
| Client authentication mechanism and associated credentials |
Used during the token request. The options are:
If you use private key JWT, you'll also need to tell us the URI of your public key JWKS endpoint. |
| Whether you want UserInfo responses to be signed, and if so which algorithm to use |
Used during the UserInfo request. The algorithms that are supported are defined in each of the OpenID Provider Configuration Documents, but typical values we see used are RS256 or RS512. |
| Whether you want to use the back-channel logout capability and, if so, your back-channel logout URI |
The URI must be secured with HTTPS, accessible by a public DNS domain and present a server certificate matching its FQDN. The certificate presented must include a full certificate chain to a trusted public root CA, such as DigiCert. For more details see back-channel logout. |
In return, we'll tell you the following information:
| Information | Comments |
|---|---|
| Client identifier |
Used during the authentication request and the token request. Takes one of the following forms:
The 12 digit number is randomly generated in order to prevent it from being guessed. |
| Client secret |
Only if you’re using it as your client authentication mechanism during the token request. Takes the form of a randomly generated 128-bit GUID, for example 50a6122b-6907-4a13-948e-f31d4c4714d5. |
Test environment set-up
Test users and UUIDs
For testing in our PtL environments, you'll need to set up some test users. Each user has a unique ID known as a UUID.
UUIDs are specific to each environment, so a UUID in the integration environment will not work in the production environment and vice versa. Typically, integration environment UUIDs start with 5552 or 5553.
If you have previously integrated with CIS1, you may already have smartcards for a PtL environment (and therefore UUIDs). These will continue to work with CIS2 Authentication.
If you require new UUIDs, make a smartcard request for a Path to Live environment. This process is still used if you just require a UUID, for example if you are going to be only using security keys. There is an option to advise that you do not require a smartcard to be sent to you. This process is managed by our ITOC team.
Any subsequent changes to identity set up can be made by contacting the ITOC team directly at [email protected].
If you don't already have particular permission/role requirements for your application, then use these value when requesting that a user be set up:
- organisation code: A9A5A
- organisation name: NHSID DEV
- role code: R8015
Authenticators
All our PtL environments support the same authenticators available in the production environment. The choice of authenticator doesn't change how you integrate your application with CIS2 Authentication, but may simplify how your development teams work.
Options to consider when deciding which authenticator to use:
- While some end users are still using smartcards over HSCN, there is no requirement to test with smartcards over HSCN as the authenticator flow is the same for all authenticators, therefore you can use any of the supported authenticators for testing. The only exception to this when testing for AAL3, you can't use an AAL2 authenticator.
- For remote teams where an HSCN connection may not be available, we support authenticators that work over the internet without the need for a HSCN connection: smartcards that authenticate over the internet, security keys and Windows Hello. For offshore teams, security keys are a good choice as they are easy to purchase and can be registered remotely. They also have the advantage of not requiring any additional software to be installed.
- Each person in your team can use a different authenticator, plus a user's identity (UUID) can be bound to multiple authenticators, which helps support a variety of working patterns your team may require.
While smartcards are provided centrally by NHS England, the other authenticators are not and must be purchased separately. NHS England also do not supply smartcard readers for system integrators and these must also be purchased separately. There are many different manufacturers of smartcard readers, whose drivers need to interact with a vast combination of different platforms, software, hardware and setups. Find out more about the smartcard readers we support.
If you have any questions about which authenticators your teams should use, please contact us to discuss.
Client devices
There is minimal set up required to client devices that are specific to CIS2 Authentication. No additional software is required to use security keys or Windows Hello. NHS Identity Agent, NHS Credential Management and relevant drivers are required to use smartcards over HSCN, along with having an HSCN connection. The set up is the same as for setting up a smartcard user workstation - an HSCN connection is needed to download the necessary software.
Last edited: 4 February 2026 9:18 am