Written by Technical Team | Last updated 15.08.2025 | 12 minute read
If your application is aimed at clinicians or staff inside the NHS, you will almost certainly encounter Care Identity Service 2 (CIS2). CIS2 is the identity layer used across NHS England to give health and care professionals a secure way to prove who they are and what they are allowed to do. In practice, it is the gatekeeper to a wide range of national services and APIs, and increasingly to local systems that wish to align with national policy. Building with CIS2 doesn’t just tick a compliance box; it is a strategic choice that signals your product is built for clinical-grade trust, auditability, and scale.
It is helpful to think of CIS2 in two dimensions: identity proofing and session security. Identity proofing governs how a person is enrolled and verified as an NHS professional—mapping them to roles, organisations, and privileges. Session security is how your app gets and uses tokens at runtime, ensuring only the right person has access at the right time. Together, they provide the assurance that an oncology consultant really is who they claim to be and really does have permission to access chemotherapy protocols or update a patient record.
You will need CIS2 whenever your workflows rely on the authenticated identity of an NHS professional—particularly when those workflows include access to patient data, writing to clinical systems, or making calls to nationally governed APIs. Even where the data layer is local, many NHS organisations prefer vendors to use CIS2 because it harmonises staff access across their estate and reduces the need for multiple, home‑grown sign-in solutions. For vendors, this unlocks the possibility of single sign-on across trusts, smoother procurement conversations, and faster clinical onboarding.
There are edge cases. If you build a purely public patient-facing feature or an informational microsite for clinicians without any data access, CIS2 may be excessive. Conversely, if you’re integrating deeply with Spine-facing services, CIS2 will almost certainly be mandatory. In borderline scenarios, it is wise to align early with the prospective NHS customer’s Information Governance and Clinical Safety teams; they will often prefer the predictability of CIS2 over ad‑hoc controls.
Vendors who succeed with CIS2 treat onboarding as a structured, multi‑stream project rather than a line item in a sprint plan. At a high level, you are orchestrating three things at once: product governance (can we use CIS2 and under what controls?), technical integration (can our stack speak the right protocols?), and organisational enablement (are the right roles, policies, and helpdesk flows in place?). Approaching the work as an integrated programme reduces the number of approval loops and the likelihood of rework late in the schedule.
Before writing any code, map the business case for identity and access. Document which user cohorts will sign in, which organisations they belong to, and which transactions depend on identity claims. This functional map becomes the backbone for later activities—your role design, authorisation checks, audit fields, and support runbooks all flow from it. If your product serves several clinical personas, do this exercise per persona; it will surface mismatched expectations early, such as whether locums should access the same features as permanent staff.
Key activities typically include:
With this groundwork in place, sequence your build and approvals. Many teams iterate through a sandbox-to-pre‑prod-to‑live progression. In sandbox, you prove out the core sign‑in flow, token handling, and logout logic; you also settle on how your app will surface access errors, such as a user having valid CIS2 credentials but lacking a necessary role in your product. In pre‑production, you integrate with real organisational structures and a representative set of staff accounts, enabling role-mapping and end‑to‑end test cases. Only then do you proceed to live onboarding with genuine clinical users.
The most efficient integrations share three traits: they adopt standard protocols without embellishment, they treat identity tokens as first-class domain objects, and they design for the realities of the NHS desktop estate as well as modern web and mobile clients. A clean architecture lets you change the user interface without rewriting your security model, and it keeps regulators—who care most about controls and audit—comfortable with your approach.
At the protocol level, you should expect to implement OpenID Connect flows for authentication, layered over OAuth 2.0 for authorisation. Choose the flow that best fits your client type: for browser-based single-page applications backed by your API, authorisation code flow with PKCE is the pragmatic default. For confidential server-side apps, a traditional authorisation code flow suits. Avoid implicit flow; it is a legacy path that is less secure and complicates your threat model. Regardless of flow, design for short‑lived tokens and well‑defined refresh logic.
How you handle claims will make or break your user experience. CIS2-derived identity tokens can carry rich context: the user’s unique identifier, the organisation or organisations they currently represent, their role assignments, and sometimes the professional codes that matter in clinical settings. Rather than scatter these claims across ad‑hoc session objects, create a unified identity context that your application understands. When the user first signs in, normalise the claims into this context and cache it securely on the server side. Downstream services should consume the context through a trusted gateway rather than reading raw tokens, which reduces exposure and simplifies logging.
Designing authorisation checks is another area where early clarity pays dividends. A common mistake is to bind application permissions directly to incoming role codes. That seems quick at first but it couples your product to an external taxonomy that may evolve. A better pattern is to create application roles that are stable—such as “prescribe”, “approve discharge”, or “view controlled drugs ledger”—and map those to the incoming identity claims in a single place. This approach isolates change and allows you to implement local exceptions with clear audit trails when a cohort needs temporary access.
Consider the end user devices and network realities. Many clinicians still access clinical systems on managed Windows desktops within hospital networks, often behind strict proxies and with older browsers left in place for compatibility with legacy apps. Build a graceful degradation strategy: do not rely on cutting-edge browser APIs for the authentication redirect chain and avoid assumptions about third‑party cookie availability. For mobile apps, plan for intermittent connectivity and resume‑safe flows that recover from dropped redirects or backgrounded states without breaking the sign‑in sequence.
Session management deserves careful thought. The safest pattern is a short, renewable session bound to both the device and the user identity, with revocation on sign‑out and on privilege change. If your product enables sensitive write operations, add an elevation step—sometimes called step‑up authentication—before allowing specific actions. Elevation can be time‑boxed and audited to make clinical governance comfortable, while retaining a swift baseline experience for read‑only workflows.
Finally, give equal attention to logging and observability. Your system should emit structured events for each stage of the sign‑in and token lifecycle: redirects initiated, authentication success or failure, token exchanges, refreshes, revocations, and logout. Link these events to your application’s domain events so that an investigator can reconstruct who did what, when, and under which organisation context. Beyond forensics, such telemetry powers a better product: you will spot friction patterns and misconfigured roles early, long before they generate helpdesk tickets.
Teams naturally ask, “How long will CIS2 onboarding take?” The honest answer is that timelines depend less on code and more on alignment, evidence, and scheduling. The engineering tasks—implementing OpenID Connect, building a token handler, wiring single sign‑on into your UI—are well understood. What stretches the calendar are the steps that prove your approach is safe, compliant, and operable in the target NHS setting.
A pragmatic plan for a first‑time vendor is to budget for a discovery and design phase that settles the end‑to‑end approach, a build-and-sandbox phase to make the flows real, and a pre‑production phase for organisational alignment and evidence. The approvals cadence often includes sign‑off from Information Governance, Cyber Security, Clinical Safety, and local IT Operations. Each holds different concerns: proving your threat model is sound, that your clinical risks are controlled, that your audit trail is complete, and that service desks can support staff if something goes wrong. You can shorten the path by preparing high‑quality artefacts early—architecture diagrams, data flow maps, test plans, results from penetration testing, and a clean operational runbook.
The most frequent failure is treating authentication as an afterthought until close to go‑live. When teams bolt on identity late, they create awkward hand‑offs between UI and backend components, overlook edge cases like role switching, and leave little time for clinicians to test the experience. The cure is to build sign‑in as a first-class journey, with stubbed screens and end‑to‑end redirects in your earliest demos so stakeholders can surface concerns early.
Another recurring issue is brittle role mapping. If your app hard‑codes assumptions about role codes or organisational identifiers, changes in the underlying directory can break people’s access without a clear diagnosis path. Isolate those assumptions into well‑tested adapters and expose a self‑service diagnostics page to administrators so they can see, for a given user, which claims were received and how your app interpreted them. This single capability can save days of back‑and‑forth during onboarding at a new trust.
Support readiness is often underestimated. Authentication problems tend to be urgent—busy clinical staff cannot sign in, and they need help now. Agree who owns which part of the journey: which failures route to your vendor support, which route to the trust’s IT service desk, and how to hand off with the right context. Set response targets for authentication incidents separate from general feature issues; they typically deserve a faster response because the impact is immediate and high.
Finally, do not forget the off‑boarding and exception paths. Clinicians change roles, rotate through placements, or leave organisations entirely. Your product should react promptly to changes in the identity layer—revoking access where appropriate and preserving a forensic record for anything that has clinical or legal significance. Likewise, prepare for emergency access policies, sometimes called “break-glass”, with tight audit and time limits so they serve patient safety without becoming a back door.
Practical FAQs that frequently come up:
A readiness checklist to accelerate CIS2 approval:
Onboarding your app with CIS2 is a predictable journey once you treat it as a programme rather than a feature. The technical pieces—protocol flows, token hygiene, role mapping—are mature and well documented in the broader industry, even if the precise claims and behaviours in NHS contexts have their own flavour. The bigger differentiator is how well you manage the human side: aligning with NHS stakeholders, preparing high‑quality evidence for approvals, and making the first experience for clinicians effortless.
If you plan decisively, build cleanly, and evidence your approach along the way, the approvals process becomes a sequence of confirmations rather than a gauntlet. Your product will arrive at go‑live with a security posture you can defend, a support model that scales, and an identity foundation ready for the next thing your users ask you to build.
Is your team looking for help with CIS2 integration? Click the button below.
Get in touch