NHS Login is available exclusively for digital health and social care services that are commissioned or sponsored by an NHS organisation. Private-only services cannot integrate unless the specific component sits within a commissioned pathway. If your service clears that eligibility bar, you are looking at five mandatory onboarding stages and a realistic project timeline that is shaped far more by compliance and clinical safety than by code complexity, typically requiring several months.
What you need to know immediately:
- Eligibility: Your service must be NHS-commissioned or NHS-sponsored. Confirm this before any technical work begins.
- Five mandatory stages: Apply for access → Discovery → Technical integration → Clinical safety and conformance (including SCAL) → Go-live approval from the National Service Desk.
- Where time is spent: DAPB3051 alignment, SCAL evidence collection, and integration-environment testing routinely take longer than the OIDC implementation itself.
- NHS Login is not plug-and-play. Budget lead time for clinical safety assessments and conformance reviews from the outset.
The NHS login integration toolkit sets out these five stages as non-negotiable. Teams that treat them as sequential checkboxes rather than overlapping workstreams consistently hit avoidable delays at the conformance stage.
Key takeaways
Successful NHS login integration depends on resolving eligibility, Vector of Trust, and SCAL evidence strategy before technical build begins — compliance decisions determine the schedule, not code complexity.
| Point | Details |
|---|---|
| Eligibility is the first gate | Only NHS-commissioned or NHS-sponsored services can integrate NHS Login; confirm this before any technical work. |
| Choose the right authentication path | NHS Login serves patients; CIS2 Authentication serves health and care professionals — conflating them causes access failures. |
| VoT decision drives everything | Define your Vector of Trust profile in discovery; it sets verification levels, scopes, and DAPB3051 transaction mapping. |
| SCAL evidence must come from the integration environment | Sandpit evidence is rejected; all conformance submissions require the NHS integration test environment. |
| Compliance runs throughout, not just at the end | Assign a clinical safety lead at the apply stage and begin SCAL preparation during technical integration. |
| Pocketapp delivers end-to-end | Pocketapp covers discovery, compliance gap review, technical build, integration-environment testing, and go-live support. |
Table of Contents
- NHS Login versus CIS2: which authentication path does your service need?
- How the five onboarding stages work in practice
- How the technical implementation actually works
- Choosing the right Vector of Trust and mapping to DAPB3051
- What SCAL requires and how to pass conformance
- Operational, privacy and accessibility requirements post-launch
- Why a compliance-first approach saves time and money
- Pocketapp's NHS login integration service: from discovery to go-live
- Sources
- FAQ
NHS Login versus CIS2: which authentication path does your service need?
Getting this decision wrong early costs weeks of rework. The two systems serve entirely different user populations and call for different technical implementations.
NHS Login is for patients and the public. It handles identity verification through photo ID, automated face matching, and GP fast-track options using linkage keys. It returns claims such as GP practice information when IM1 integration is available. If your service is patient-facing — a portal, a booking tool, a personal health record — NHS Login is the correct path.
CIS2 Authentication is the national Care Identity Service for health and care professionals. It uses OIDC, supports passkeys, Windows Hello, and security keys, and is required for some national user-restricted APIs. CIS1 is deprecated and scheduled for retirement by February 2027, so any staff-facing service still on CIS1 needs a migration plan now.
The practical decision criteria come down to three questions:
- Who is the end user? Patient or public → NHS Login. Health or care professional → CIS2.
- What data sensitivity is involved? High-sensitivity clinical data accessed by clinicians typically requires AAL3 authenticators under CIS2. Patient-facing convenience features generally sit at AAL2.
- Do you need national RBAC? Clinical authorisation patterns and role-based access control for national APIs require CIS2, not NHS Login.
Pro Tip: Confirm your end-user type and required assurance level in the discovery stage, before any API registration. Changing authentication paths after technical integration begins is expensive and time-consuming.
How the five onboarding stages work in practice
The integration toolkit defines each stage, but the checklist below translates them into project-grade actions.
Stage checklist
- Apply: Submit your service details to NHS England Digital. Confirm NHS commissioning or sponsorship. Assign a clinical safety lead, technical lead, and product owner before this stage closes.
- Discovery: Define your Vector of Trust (VoT) profile, map transactions to DAPB3051 Appendix D, and agree scope with NHS England. Produce a Connection Agreement draft.
- Technical integration: Register your application on both NHS Login and the NHS API Platform. Generate your RSA key pair. Implement the OIDC authorisation code flow and token exchange. Test in the sandpit for initial exploration only.
- Clinical safety and conformance (SCAL): Produce all conformance evidence from the NHS integration test environment. Complete the Clinical Safety Assessment Log. Submit evidence to the National Service Desk.
- Go-live: Receive National Service Desk approval. Register on the National Service Desk. Deploy to production.
Roles and responsibilities
| Role | Stage ownership | Key deliverable |
|---|---|---|
| Product owner | Apply, Discovery | Connection Agreement, scope sign-off |
| Clinical safety lead | SCAL, Conformance | Clinical Safety Assessment Log evidence |
| Technical lead | Technical integration, Testing | OIDC implementation, key pair registration |
| Security lead | Technical integration, Go-live | Key storage, token lifecycle policy |
| Development supplier (e.g. Pocketapp) | Integration, Testing, Go-live | Code build, integration-environment test evidence |
A realistic timeline for a well-prepared team involves multiple months of work. Discovery and SCAL evidence collection are the longest phases. Teams that engage their clinical safety lead at the apply stage, rather than at the conformance stage, consistently move faster.
How the technical implementation actually works
The NHS authentication process for user-restricted APIs follows a specific sequence. Understanding it before you write a line of code prevents the most common integration failures.
The token exchange sequence
Developers must register applications on both NHS Login and the NHS API Platform, generate a key pair, register the public key, and follow the OIDC flows to obtain an ID token to exchange for API access tokens.
- Register your application with NHS Login and the NHS API Platform separately.
- Generate a 4096-bit RSA key pair. Register the public key with the API Platform.
- Direct the user through the OIDC authorisation code flow on NHS Login.
- Call the NHS Login token endpoint to receive an ID token.
- Construct a
client_assertionJWT, signed with your private key at runtime. - POST to
https://api.service.nhs.uk/oauth2/tokenwith the ID token andclient_assertionto receive an API access token.
The separate authentication and authorisation pattern is the authoritative reference for this flow.
Implementation notes
| Parameter | Requirement |
|---|---|
| RSA key size | 4096-bit minimum |
client_assertion | Signed JWT, generated at runtime per request |
| Token exchange endpoint | https://api.service.nhs.uk/oauth2/token |
| OIDC error handling | Redirect-based; never swallow OIDC errors silently |
asserted_login_identity | snake_case; misformatting is a common blocker |
Private key storage is non-negotiable. Store private keys in a secrets manager — AWS Secrets Manager, Azure Key Vault, or equivalent — never in source code or environment variables committed to version control. Token lifetimes are short by design; implement refresh token handling and plan for graceful expiry UX from day one.
For practical implementation steps, the Java tutorial on NHS England Digital walks through the full sequence with code examples. For secure token storage patterns, see Pocketapp's guidance on protecting user data in mobile app development.
Choosing the right Vector of Trust and mapping to DAPB3051
The Vector of Trust decision is the most consequential strategic choice in an NHS login integration project. It determines which identity verification and authentication levels you request, which scopes are available, and which DAPB3051 transaction examples apply to your service.
DAPB3051 defines two authentication types — strong and basic — and provides Appendix D with transaction examples that map directly to VoT choices. Work through Appendix D during discovery; it is required reading, not optional background.
AAL2 versus AAL3 decision criteria:
- AAL2 suits patient-facing convenience features: appointment booking, messaging, viewing non-sensitive records. Two-factor authentication is required but does not need a hardware authenticator.
- AAL3 is required where high-sensitivity clinical data is accessed or where the transaction risk warrants a hardware-bound authenticator. For CIS2 authenticators, some national APIs mandate AAL3 explicitly.
Common NHS patient transaction mapping:
- Viewing GP summary record → medium verification, AAL2 authentication
- Updating demographic information → high verification, AAL2 or AAL3 depending on data sensitivity
- Accessing sensitive clinical history → high verification, AAL3
Pro Tip: Request only the VoT level your transactions genuinely require. Requesting AAL3 for low-sensitivity features creates unnecessary friction for patients and increases drop-off at the identity verification step.
For services incorporating biometric local authentication on mobile, Pocketapp's biometric authentication guide covers the UX and security considerations that complement your VoT choices.
What SCAL requires and how to pass conformance
SCAL is where many integrations stall. The most common reason is straightforward: evidence submitted from the sandpit environment rather than the NHS integration test environment.
The sandpit is for exploration only. Every piece of conformance evidence submitted for SCAL must be produced in the NHS integration test environment. This distinction is stated clearly in the integration toolkit and is the single most frequent cause of approval delays.
Non-negotiable conformance items for go-live:
| Test area | Acceptance criterion |
|---|---|
| OIDC error handling | All OIDC errors redirect correctly; none are swallowed silently |
| Logout behaviour | Full logout clears session and NHS Login session cookie |
| Reauthentication | Triggered correctly at required intervals; not skipped |
asserted_login_identity | Correctly formatted and handled in all flows |
| Consent decline | Service handles consent decline gracefully without errors |
| Token refresh | Refresh token flow tested end-to-end in integration environment |
Common blockers include incorrect OIDC paths, missing reauthentication triggers, and consent-decline flows that return unhandled errors. Plan integration tests to cover every edge case in the table above before submitting SCAL evidence.
Operational, privacy and accessibility requirements post-launch
Going live is not the end of the compliance obligation. Several operational requirements persist and must be built into your runbook from day one.
Monitoring and incident response:
- Monitor token expiry and refresh failures in real time; an expired token that is not caught gracefully breaks the patient session silently.
- Define an escalation path to the National Service Desk for SSO failures that cannot be resolved at service level.
- Log consent declines and SSO errors for audit purposes, in line with your GDPR data processing records.
Privacy and consent:
- NHS Login shares claims only for the scopes your service requests. Present those scopes clearly to patients at the point of consent; do not request scopes you do not use.
- Align your privacy notice with the claims your service receives. GP practice information, for example, requires explicit mention if returned via IM1 integration.
Accessibility and logout:
- Logout must clear both the local session and the NHS Login session. Partial logout that leaves the NHS Login session active is a conformance failure.
- Reauthentication timing must be implemented on the service side; do not rely on NHS Login to enforce session limits.
- For mobile apps, local authentication patterns (biometric unlock, PIN) can reduce reauthentication friction without bypassing NHS Login security requirements.
For broader digital transformation governance across complex NHS projects, the digital transformation roadmap guidance from 121 Group offers a useful multi-stakeholder planning framework.
Why a compliance-first approach saves time and money
The teams that move fastest through NHS login integration are not the ones with the most experienced developers. They are the ones that resolve their Vector of Trust profile and SCAL evidence strategy before writing production code.
In practice, this means treating the discovery stage as the most important phase of the project, not a formality before the build begins. The VoT decision shapes every downstream technical choice: which scopes to request, which authenticators to support, which DAPB3051 transactions to map. Getting it wrong at discovery means rework at conformance, which is the most expensive place to discover a misalignment.
The same logic applies to clinical safety. Organisations that assign a clinical safety lead at the apply stage, and begin assembling SCAL evidence during technical integration rather than after it, consistently avoid the approval delays that push go-live dates back by months. Compliance is not a gate at the end of the project. It is a thread that runs through every stage.
Pocketapp's NHS login integration service: from discovery to go-live
Pocketapp brings over 300 delivered projects to NHS login integration work, with direct experience across the five mandatory onboarding stages. For healthcare IT teams that need a delivery partner rather than a framework to follow alone, we map our capabilities directly to your project needs.
Our engagement typically begins with a compliance gap review and discovery workshop: we assess your eligibility, define your VoT profile, and identify SCAL evidence requirements before a line of code is written. From there, we handle technical integration, integration-environment testing, and go-live support, with your clinical safety lead and technical lead involved at every stage.
The first meeting is a structured scoping session. We come prepared with questions about your commissioning status, end-user population, and data sensitivity, so you leave with a clear picture of what the project involves and what it will take to reach go-live. To start that conversation, visit our mobile app development service page or get in touch directly.
Sources
The following NHS England Digital pages are required reading for any team planning an NHS login integration project:
- NHS login - NHS England Digital
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
Who is eligible to integrate NHS Login?
Only digital health and social care services that are commissioned or sponsored by an NHS organisation are eligible. Private-only services can integrate only where the specific component is part of a commissioned pathway.
What is the difference between NHS Login and CIS2 Authentication?
NHS Login is for patients and the public; CIS2 Authentication is for health and care professionals. Using the wrong system for your user population causes access failures and may prevent calls to national user-restricted APIs.
What does SCAL require and where must evidence come from?
SCAL requires documented conformance evidence covering OIDC error handling, logout behaviour, reauthentication, consent decline flows, and token refresh. All evidence must be produced in the NHS integration test environment, not the sandpit.
What RSA key size is required for the token exchange?
A 4096-bit RSA key pair is required. The public key must be registered with the NHS API Platform, and the client_assertion JWT must be signed with the corresponding private key at runtime for each token exchange request.
Can Pocketapp manage the full NHS login integration process?
Yes. Pocketapp covers all five onboarding stages: eligibility and discovery, VoT definition, technical build, integration-environment testing, and go-live support, working alongside your clinical safety lead and technical lead throughout.