NHS Spine, Smartcards and CIS2 Identity Security Guide

Access to national NHS patient record services in England rests on a single identity chain, from a face-to-face identity check by a Registration Authority to a smartcard or CIS2 authenticator and a selected role, and weaknesses anywhere in that chain, such as shared cards, stale roles or untracked leavers, turn into unauditable access to patient data. NHS Spine connects more than 23,000 healthcare IT systems across 20,500 organisations, and NHS England reports more than 800,000 Spine smartcard users. This guide explains how the pieces fit together: Registration Authorities, the Care Identity Service, smartcards and newer CIS2 Authentication methods, and national role-based access control. It then covers the controls, monitoring and failure patterns that matter to NHS trusts, GP practices, pharmacies and suppliers building Spine connected systems. It complements the Smart Card and PIV/CAC Authentication Guide and the Healthcare Identity Security Guide with England specific detail.

Key takeaways

Identity is proven once, centrally. Registration Authorities verify identity face to face and register users in the Care Identity Service, so the RA process is the foundation every Spine access decision inherits.
The smartcard is no longer the only authenticator. CIS2 Authentication now offers Windows Hello, security keys and an iPad app at AAL3, and passkeys, Microsoft Authenticator and NHS.net Connect at AAL2, which only work with AAL2-enabled applications.
Roles, not people, carry permissions. National RBAC maps job roles ("R" codes) to activities ("B" codes); users select a role per session and applications must check the activity, so wrong role assignments are as dangerous as stolen cards.
Sharing is the defining local risk. Trust RA policies state that only the card holder should know the passcode and that letting someone else use a card breaches the card terms and can breach the Computer Misuse Act 1990.
Leaver and mover processes decide exposure. Smartcards usually stay with staff who move within the NHS, so the end date in the workforce system and role removal, not card recovery, is what actually revokes access.

How NHS national identity fits together

Component	What it does	Security relevance
NHS Spine	National infrastructure linking health and care IT in England; services include the Electronic Prescription Service, Summary Care Record, e-Referral Service, Child Protection Information System and Spine Mini Service	Holds or brokers national patient data, so every connected user and system is a route to it
Registration Authority (RA)	Usually a function inside an NHS organisation; checks identity of prospective users and assigns access profiles approved by the employer	The identity proofing and authorisation step for national access
Care Identity Service (CIS)	The system RAs use to register users and issue smartcards and assign roles	System of record for national user identities and their roles
Smartcard	Chip card used with a passcode known only to the holder, giving secure and auditable access to Spine enabled systems	Hardware authenticator; audit relies on one person per card
NHS CIS2 Authentication	National authentication service using OIDC, WebAuthn and FIDO2, with more than 40 applications and 530,000 users reported	Brings phishing-resistant, device-bound credentials beyond the smartcard
National RBAC Database (NRD)	Holds job roles, activities and the baseline policy mapping roles to activities	Defines what each role may do in national applications
Warranted Environment Specification (WES)	Checks whether an IT system and environment support smartcard access	Local build standard for workstations using smartcards

Registration Authorities and identity proofing

National RA policy is applied locally through each organisation's RA policy. Trust policies published by NHS bodies describe a consistent structure:

RA Manager: runs RA governance, appoints and trains RA Agents and Sponsors, carries out audits and makes sure leavers' access is removed promptly.
RA Agent (and advanced RA Agent): registers users, verifies identity, creates and cancels smartcards, renews certificates where self-service is not used and grants access.
Sponsor: approves which roles a person should have, on behalf of the employer.
Local Smartcard Administrator: unlocks cards and renews certificates locally.
Identity standard: NHS Employers identity check standards apply; one trust policy states verification to GPG45 Level 3 or 4, face to face with original documents, and the same check for changes to name, date of birth or National Insurance number.

Security points that follow from this structure:

Separation of duties: the person who sponsors a role should not be the person who grants it, and RA staff should not grant roles to themselves.
RA roles are privileged access: an RA Agent can create a national identity and attach clinical roles. Review RA role holders as you would domain administrators. See the Privileged Access Management Guide.
Postal handling: trust policy allows posting only locked cards, which the user must then unlock in person with a Local Smartcard Administrator.

Authenticators: smartcards and CIS2 options

NHS England lists seven Care Identity Service authenticators. AAL3 authenticators work with all CIS2 applications; AAL2 authenticators work only with applications enabled for AAL2. Non-smartcard authenticators can be self-registered, otherwise an RA issues them.

Authenticator	Assurance level	What the user does	Operational notes
Smartcard	AAL3	Insert card, enter passcode	Needs a reader and software; the classic shared workstation risk is a card left in the reader
Windows Hello	AAL3	Face or fingerprint on the device	No certificate renewal; device bound, so device management matters
Security key	AAL3	Enter PIN, touch key	Portable; some models work with tablets
iPad app	AAL3	Face or fingerprint in the NHS CIS2 iPad app	No card or reader; suited to mobile clinicians such as paramedics
Passkeys	AAL2	Fingerprint or device camera	Only with AAL2-enabled applications
Microsoft Authenticator	AAL2	Email, password and a six digit code	Used for services such as MESH and e-Referral; phishable compared with AAL3 options
NHS.net Connect	AAL2	NHS.net account with Authenticator push	Shares the NHS email MFA process, so email account security becomes record access security

Decision guidance: use AAL3 authenticators wherever a role can reach identifiable clinical records. Windows Hello suits single user corporate laptops; security keys suit staff who move between shared devices; smartcards remain the fallback for shared clinical workstations built to the WES. Treat AAL2 methods as appropriate only for the applications NHS England has enabled for AAL2, and protect the NHS.net account that backs NHS.net Connect with the same care as the smartcard. See the Phishing-Resistant MFA Guide.

National role-based access control

National RBAC assigns users predefined job roles, each linked to predefined activities. NHS England's developer guidance gives examples: Clinical Practitioner is role R8000, Amend Patient Demographics is activity B0825, and B0825 includes View Patient Demographics (B0820), so authorisation checks must account for included activities. The NRD also holds the baseline policy that maps roles to activities, and activities can be assigned directly to users where a service such as e-Referral needs it.

Session role selection: where a user holds several roles, the application must let them pick one for the session, check the NRD for the requested activity, and pass the user's role profile ID when calling national APIs.
Least privilege in practice: sponsors should approve the narrowest role and organisation combination; avoid giving clinical roles to administrative staff "in case".
Movers: a role tied to a previous post at another organisation can follow the card unless the old organisation ends the association.
Legitimate relationship: national services expect access to follow a care relationship; local applications should log the reason for access where the role allows broad lookup.

Where identity fits: systems and supplier identities

Spine connected systems are not only accessed by people. Supplier applications, integration engines and messaging endpoints hold their own credentials and certificates, and CIS2 integrations are OIDC clients with secrets or keys.

Application onboarding: NHS England requires developers to integrate CIS2 Authentication and get approval before going live, which typically takes about three months. Keep client credentials in a secrets manager and rotate them on a schedule.
Endpoint certificates and messaging credentials: treat integration certificates and mailbox credentials as non-human identities with owners, expiry tracking and revocation plans. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Service accounts in clinical systems: interface accounts that query Spine on behalf of many users must not use a person's smartcard session; design them with their own audited identity.

How to implement or improve

Baseline: export RA role holders, sponsors and Local Smartcard Administrators from CIS, and list every application using smartcard or CIS2 authentication.
Fix joiner, mover, leaver: connect the workforce system end date to CIS role removal, and run a monthly reconciliation of active CIS roles against current staff.
Review roles: sponsors recertify the roles of their staff at least annually, with RA Managers chasing exceptions.
Introduce AAL3 alternatives: pilot Windows Hello on single user devices and security keys for mobile staff in one directorate, measure login times and helpdesk calls, then expand.
Harden shared workstations: build to the WES, configure session lock on card removal and short idle locks, and test fast user switching so staff are not tempted to share.
Roll back safely: keep smartcards active for pilot users until the new authenticator has worked for a full rota cycle, so an authenticator failure never blocks patient care.

Smartcard lifecycle and shared workstation controls

Most day to day smartcard risk sits in the lifecycle events around the card rather than the cryptography on it. Each event below should have a written local procedure, an owner and an audit record.

Lifecycle event	Risk	Control
First issue	Card issued to the wrong person or with excess roles	Face-to-face identity check by trained RA staff; sponsor approved roles only; the user sets the passcode themselves
Forgotten passcode or locked card	Unlock performed without confirming the holder, or passcode disclosed	Unlock in person by a Local Smartcard Administrator; never ask for, record or set a user's passcode
Lost or stolen card	Card used with an observed passcode	Report immediately to the RA, cancel the card in CIS and issue a replacement after re-verification
Certificate renewal	Expired certificates push staff towards borrowing a colleague's card	Encourage self-service renewal and warn users before expiry
Change of name or personal details	Identity record no longer matches the person	Repeat the face-to-face check before updating CIS
Move to another organisation	Old roles follow the person	Old organisation ends its association; new sponsor requests fresh roles
Death in service or rare returns	Card left in circulation	Destroy as confidential waste and record the action

On shared clinical workstations, the aim is to make the honest path faster than sharing. Fast session switching, lock on card removal, short idle timeouts on unattended screens and enough readers at each nursing station remove most of the pressure to leave a card in place. Where tap based or proximity solutions are used locally, check that they still bind each session to an individual identity that appears in the audit trail.

Detection and measurement

Concurrent use: the same user active on two distant workstations or organisations at the same time suggests card or passcode sharing.
Access outside role: record access by users whose role or organisation does not match the patient's care setting; national and local audit trails exist for this.
RA activity: unusual volumes of role grants, grants by an RA Agent to colleagues in their own team, or roles granted without a sponsor.
Leavers: CIS identities still associated with your organisation after the workforce end date.
Unlock patterns: repeated passcode unlocks for the same card, which can indicate the passcode is known to others.

Metrics: percentage of leavers whose organisation association was ended within one working day; percentage of active roles recertified in the last 12 months; share of Spine sessions using AAL3 authenticators other than smartcards; number of concurrent session alerts per month and outcome; time from sponsor request to role grant.

Regulatory and framework mapping

Framework	Reference	Relevance
Data Security and Protection Toolkit	Self-assessment against the National Data Guardian's 10 data security standards; all organisations with access to NHS patient data and systems must use it	Annual evidence of access control and staff responsibilities
NCSC Cyber Assessment Framework	Objective B, principle B2 Identity and access control	The CAF-aligned DSPT uses CAF outcomes for identity and access
NHS Care Record Guarantee for England	Rules on record access, monitoring and patient controls	Applies to everyone working for or contracted to the NHS
NIST SP 800-63B and SP 800-53 Rev. 5	Authenticator assurance levels (AAL2, AAL3); IA-2, AC-2 Account Management, AC-6 Least Privilege, AU-6 Audit Record Review	The AAL terminology CIS2 uses and supporting controls
ISO/IEC 27001:2022 Annex A	5.15 Access control; 5.16 Identity management; 5.18 Access rights; 6.5 Responsibilities after termination	RA, role and leaver controls

Common failure patterns

Card sharing on busy wards: one clinician's card left in a shared workstation all shift, so every action is logged against the wrong person and audit loses its value.
Passcodes known to RA or IT staff: trust policy is explicit that only the end user should know the passcode, including RA staff; helpdesk practices that record or reset passcodes on request break that.
Roles that never expire: temporary or rotational staff keep clinical roles after the rotation ends because nobody ends the association.
RA concentration: a single RA Agent sponsoring and granting roles without review, giving one person the ability to create national access.
Weak paths around strong authentication: remote access or supplier portals protected only by passwords. The Change Healthcare breach began with a Citrix login without MFA, a reminder that AAL3 for Spine does not protect systems that sit beside it.
AAL2 creep: using convenient AAL2 methods as the default for staff whose roles reach detailed records.

Practitioner checklist

Document RA roles, sponsors and Local Smartcard Administrators, and review them quarterly.
Link workforce end dates to CIS role removal and reconcile monthly.
Recertify every active role with its sponsor at least annually.
Enforce separation of duties between sponsoring and granting roles.
Offer AAL3 alternatives (Windows Hello, security keys, iPad app) to reduce card sharing.
Build shared workstations to the WES with lock on card removal and short idle timeouts.
Alert on concurrent sessions, out-of-role access and unusual RA activity.
Manage supplier and integration credentials as non-human identities with owners and rotation.
Evidence these controls in the DSPT submission.

NHS Spine, smartcards and NHS identity security: Run RA, CIS2 and smartcard access safely