Skip to main content
Creating a new NHS England: Health Education England, NHS Digital and NHS England have merged. More about the merger.

Troubleshooting NHS Identity Agent

How to fix common issues with NHS Identity Agent configurations.

Compatibility with 3rd-party applications

System suppliers have been formally invited to integration test NHS Digital IA v2.3.2.0 against their software, and in the vast majority of cases they have reported that this has been successful.

NOTE: EMIS users. There is currently a known issue where Series 8 Smartcards (Oberthur) cannot perform initial registration with any version of Identity Agent higher than v2.2.2.0. This is being investigated by EMIS. Once the initial registration process has been completed, EMIS Web works with the latest version of Identity Agent. Currently it is not possible to register an NHSD Virtual Smartcard with EMIS. This is being investigated by EMIS.

NOTE: EMIS and TPP users. There are known issues when using the NHSD Virtual Smartcards with these systems. Please check with the supplier if you are having issues. These issues are currently under investigation by EMIS and TPP.

However prior to installation of NHS Digital IA v2.3.2.0 please confirm its compatibility status against your particular suite of 3rd-party applications, with their suppliers.

Known issues

The list of IA v2.3.2.0's known integration issues against third-party applications is listed in the ‘Known Issues’ section of the Release Notes.


NHS Digital IA v2.3.2.0 is assured and supported against the majority of current Operating Systems and components (see the Warranted Environment Specification for a comprehensive list).

Identity Agent v2.3.2.0 supports authentication using Citrix. Registry changes are required.

It has been designed to provide more secure and convenient ways of working with identity access, through the use of Mobility and Session Lock Persistence modes. When configured in the registry, the modes operate in the order of precedence as described below:

  • Mobility modeThis mode enables users of mobile devices running a Windows OS to authenticate, remove their Smartcard from the device for secure storage (lanyard etc.), and continue working as normal. The user will be required to reauthenticate at timed intervals to prove they still have the required credentials for their Spine session.
  • Session Lock PersistenceIf a user removes their Smartcard in order to temporarily leave their workstation, they are able to preserve their Spine session when locking their PC. On unlocking the PC and re-insertion of their Smartcard, the user is able to reauthenticate and continue their Spine session, with no loss of state.
  • Enhanced normal modeThe mode is the same as Normal mode in NHS Digital Identity Agent and earlier in that the user will be required to enter their Smartcard PIN if they lock and unlock their Spine session without removing their Smartcard.
  • Normal modeThe mode is the default mode with no additional registry settings and is the same as Normal mode was in HSCIC Identity Agent v1 and BT Identity Agent in that the user will not be required to enter their Smartcard PIN if they lock and unlock their Spine session without removing their Smartcard. This change has been added following user feedback from previous versions of Identity Agent v2.x

An improved role selection form compared to HSCIC IA v1 and BTIA – more configurable, and now including Org Code.

Faster to authenticate than HSCIC IA v1

NHS Digital IA v2.x now supports those employing ‘fast-user-switching’ and ‘follow-me-sessions’ ways of working:

  • Fast-user-switching is the method of using multiple Windows accounts and discrete respective Spine sessions on a single workstation. The users Spine Sessions can be preserved if Session Lock Persistence mode is enabled.
  • Follow-me-sessions describe the method of connecting / disconnecting to remote or RDP sessions, from different workstations, whilst maintaining a single Spine session. This requires Session Lock Persistence to be enabled to avoid the user being logged out when moving between machines.


Why am I getting ‘unexpected error… code 26352’ when installing NHS Digital IA v2.3.2.0?

Due to the permissions set on some machines, if installing NHS Digital IA v2.x on a machine which had a previous version of Identity Agent installed, the certificates can fail to be overwritten successfully, or they were not correctly removed from the uninstallation of the previous version of Identity Agent.

See the ‘Troubleshooting’ section in the Admin Guide for a full explanation of the workaround.

I seem to be authenticating successfully, but launching my Spine application / Portal gives me an error

This is likely due to files overhanging from previous (particularly BT) Identity Agent installations.

See the ‘Troubleshooting’ section in the Admin Guide for a full explanation of the fix (‘Following upgrade from BT Identity Agent’).

Why am I getting an error saying I have multiple Smartcards inserted when I only have one Smartcard?

On later versions of Windows 10, Microsoft have made the drivers for mobile SIM cards part of the Windows operating system. This can cause the mobile SIM card to be reported incorrectly as a Smartcard. Earlier versions of Identity Agent v2.x required a registry change to suppress this issue. Now the latest version Identity Agent v2.x ignores Windows reporting mobile SIM cards and the Windows Hello service as a Smartcard device.

User Experience

I’m authenticated in ‘Enhanced Normal Mode’, yet after locking and unlocking Windows, I’m being asked to re-verify my Spine session with my Smartcard passcode. Why?

This mode has the same behaviour as NHS Digital IA v2.1.2.16 in Normal Mode.

This feature exists for backwards compatibility with previous versions of Identity Agent v2.x. If the user does not want this feature, either turn this off in the registry or simply delete the registry key for this value, the default mode will not exhibit this behaviour. See the Registry settings section in the Admin Guide for further information.

Why do all my browser(s) shut down when I log out?

This is default behaviour, in order to reduce the risk that browsers are incorrectly keeping a Spine application alive even after logging out of Spine.

This behaviour can be configured via the registry (see the ‘Configuration’ section in the Admin Guide, and look for registry key ‘ProcessesToKill’).

NHS Digital IA v2.3.2.0 seems slower to authenticate than with the BT Identity Agents. Can authentication be speeded up?

Whilst NHS Digital IA v2.3.2.0 is faster to authenticate than HSCIC IA v1, it may still seem slower than BT Identity Agents.

The use of Oberthur Smartcards and / or contactless Smartcard readers will significantly increase authentication speed in NHS Digital IA v2.3.2.0.

Meanwhile authentication speed is still being investigated and will be prioritised for resolution in a future release, most likely IA v3.

When I insert my smartcard, the PIN form does not appear.

There is a known issue with Identity Agent v. causing this problem on certain operating systems. If you experience this issue, upgrade to Identity Agent v.

I have noticed the CPU usage going up and Identity Agent not responding correctly.

There have been issues identified for users with Win8.1 or Win10 on versions of Identity Agent from v.2.2 onwards causing a memory leak. Users having this issue should upgrade to Identity Agent v2.3.2.0.

Why am I getting logged out when using Session Lock mode rather than my machine being locked?

If you are getting logged out when using session lock mode, this can happen under the following circumstance:

  • Session Lock mode is enabled
  • Windows screen saver is active
  • Using Windows 8.1 or later

If all the above are true and the user removes their Smartcard when the screen saver is active, currently the Identity Agent does not correctly swap to the Lock/Logout screen and when the countdown timer expires in the background the machine fails to lock correctly and the user is logged out of Windows

To avoid this occurring, ensure Windows is not displaying the screen saver when your Smartcard is removed.

Users having this issue should upgrade to Identity Agent v2.3.2.0.

Why am I getting logged out randomly during the day when using Normal mode?

A bug was introduced in Identity Agent v2.2.1.0 which did not stop the timer for the “time allowed locked until logged out” when the machine is locked and then unlocked in Normal mode. The default for this timer is 15000s (just over four hours). This can mean the user will get logged out of Spine just over four hours after they first locked their machine.

One work around is to set TimeAllowedLockedUntilLogoffInSeconds = 28500 in the registry which will then give the user just over seven hours from first locking their machine to being logged out

Alternatively, upgrade Identity Agent to v2.3.2.0 to resolve the issue

This issue does not affect any modes other than Normal mode for the affected versions of Identity Agent.

I cannot associate my Series 8 (OT) Smartcard with EMIS

The changes required to resolve the memory leak in IA v2.2.3.7 have caused an issue with how EMIS access the Smartcard which appears to stop the first time Smartcard association from working with Series 8 (OT) Smartcards. EMIS are aware of the issue and are trying to resolve it.

The only current workaround is to perform the first-time association on a version of Identity Agent lower than v2.2.3.7, i.e. use v2.2.2.0. Once the Smartcard has been associated, EMIS works as expected.

NOTE: EMIS have attempted to advise on a fix for this issue to us which comprises the following actions.

Install GEM, install IA, install SR8, and then revert the registry back to the GEM settings.

This fix must not be used as will render any user who implements this unable to perform a self-renew on Series 8 Smartcards and a high risk of damaging the card beyond repair if attempted.

If required, Identity Agent v2.2.2.0 can be downloaded from Identity Agent v2.2.2.0

I cannot associate my NHSD Virtual Smartcard with EMIS

Currently EMIS users cannot perform the initial registration with virtual Smartcards. This issue is under investigation with EMIS.

I am getting a TLS/SSL error when trying to authenticate

This error occurs within Windows and is echoed by the Identity Agent. The usual cause of this error is either the certificates for the platform chosen for authentication are missing, or they have expired.

Either re-install or repair the Identity Agent with both production and test certificates, or if this has been done, update to the latest Path-to-Live (PTL) certificates. These are available from

I’ve just got a new Windows 10 machine and I’m having multiple issues reading or renewing my Smartcard

With the later builds of Windows 10, by default, the wrong drivers are being installed for the Omnikey 3121 Smartcard reader which can cause a variety of issues from the card being unable to be read to CMS activities failing.

If you experience any of these issues after getting a new machine, check the correct drivers have been installed. Run the CIS diagnostic tool and look at the .txt file on your desktop. The tool is available from Check if the OmniKey 3121 Smartcard reader driver is shown as a 3021 CCID reader. If it is, download and install the correct drivers, from the link above and re-run the report. The Omnikey 3121 Smartcard reader driver should now have the correct drivers installed.

I am being told my certificates are expired but I have only just renewed my Smartcard

This issue can occur if the trust has a mix of BTIA and machines with Oberthur middleware. When a Smartcard is renewed by BTIA, only the GEM compatibility element is updated. When the Smartcard is subsequently used in a machine with Oberthur middleware, the agile (OT) applet is read. Since this has not been renewed the user will be advised their Smartcard has expired. The Smartcard will need to be repaired by a RA to resolve this issue. A new Smartcard is NOT required. For trusts who operate in this type of mixed environment, it is recommended to renew the Smartcard on a machine with NHS Digital Identity Agent as this will renew both applets on the Smartcard regardless of whether Oberthur middleware is installed or not.

My Spine session seems to be shorter than expected

All versions of NHSD Identity Agent prior to v2.3.2.0 have a bug where the session length time is incorrectly calculated during BST and the session is one hour shorter than the correct length. This issue is now resolved.

Registration Authorities (CMS Activities)

Why am I being asked to re-verify my Spine session whilst performing CMS activities?

This is a known bug that usually occurs when performing CMS activities (Smartcard issuance etc.) on Oberthur Smartcards, but may also happen when using Gemalto Smartcards.

The workaround is documented in the ‘Troubleshooting’ section of the Admin Guide (‘Reverification screen appearing during CMS operations’).

This is being investigated and should be resolved in a future release.

All users performing CMS activities are recommended to set the following value in the Identity Agent registry. See the Configuration section of the Admin Guide for the location(s) of the registry.

CardRemovalCheck = False

Note: Unless you are using Identity Agent v2.2.1.0 or later, you will need to restart the program for the changes to take effect.

If the issue still occurs, check with your local ICT department that this value has not been set to True via group policy as this will need removing for the above change to work.

Authentication Service Failover

What is a Care Identity Service failover?

The transferring of the Smartcard Authentication and/or Card Management services from one of our hosting sites to another by quickly redirecting network and IT infrastructure connections with minimal impact to users of the service.

When will the Care Identity Service failovers take place and is there a schedule?

Failovers are required during intrusive upgrades or maintenance activities which would otherwise result in an outage to service. The failover to a hosting site not being upgraded means service can continue uninterrupted.

If a problem is encountered with the service, which has the potential to impact multiple users, a failover can be used to prevent or resolve a High Severity Service Incident by failing over to another hosting site.

For the majority of maintenance and release updates a failover is not required.

Failovers are also used during Disaster Recovery tests.

What does this mean for my users?

If your users are NHS Digital IA users they will experience no disruption:

  • The NHS Digital Identity Agent is able to acquire a connection to the new hosting site without the need to restart the client.

If your users are BT IA users they may suffer a disruption to service:

  • If users stay authenticated throughout the upgrade or maintenance activity then they won’t see any impact.
  • However, following a failover if users log out and then attempt to re-authenticate they will not be able to acquire a connection to the new hosting site. This means they will not be able to authenticate with their smartcard and will see an error message. A reboot of the BT IA client means a new connection will be acquired.

Last edited: 17 July 2023 2:34 pm