The Weeks Before ‘Continue with NHS’: A Product Lead’s Guide to Health App Sign-In

Every health app demo reaches the same slide: a neat ‘Continue with NHS’ button and a promise that sign-in is solved. The button is real. The weeks behind it are also real, and they rarely appear in the sprint plan.

This is not a scare story. NHS Login is a sensible route for plenty of UK health products. But it is an assurance programme wearing a login screen, and product leads need to price that in before someone tells the board it is ‘just an integration’. Treat this as a decision memo: what the trail contains, where it slows a roadmap, and when the NHS App is the better front door.

The button is the last five per cent

The first mistake is treating NHS Login as an authentication feature. It is closer to a trust arrangement. You are asking to be let into a national identity service, and the people reviewing that request will want to see how you handle data, clinical risk, user support and failure cases. The technical connection may be tidy. The evidence around it is the work.

That matters for UK product teams because health apps often sit between a clinical sponsor, an information governance lead and a commercial deadline. If the roadmap says ‘NHS Login: two sprints’, someone has skipped the reading.

What sits under the sign-in

DSP Toolkit: annual, not a one-off

The Data Security and Protection Toolkit usually sits in the room. It is an annual self-assessment with evidence, not a form you fill in once and frame. Expect questions about policies, incident handling, staff training, asset registers and your suppliers. The awkward part is that evidence ages badly: a policy dated before your last release can look thin, and a supplier list that has not been updated since procurement will not survive scrutiny.

For a product lead, this is not a security-team side quest. It affects launch sequencing. If your information governance lead needs three weeks to gather evidence, that is three weeks on the critical path.

DCB0129: a clinical safety case, not a form

If your app touches clinical decisions, triage advice or patient records, expect the clinical safety file to be examined. DCB0129 is the manufacturer-side standard: a clinical safety case report, a hazard log and a clinical safety officer with the right experience. The hazard log is where optimistic product language goes to die. ‘Users will understand the red warning’ is not a control. ‘We tested the warning with 12 users, added a second confirmation step and logged the residual risk’ is closer.

This work also has a maintenance tail. A hazard log that stops at launch is a hazard log that is already out of date.

Identity proofing: match the tier to the risk

NHS Login supports different identity proofing levels, and the level you need depends on what the app exposes. A leaflet library and a test-results viewer are not the same risk. If users can see sensitive records or change something that matters, expect a higher tier — and expect a longer user journey.

That has product consequences. Verification fails for real people: changed names, shared addresses, expired documents, overseas phone numbers. You need fallback routes, support scripts and a plan for people who cannot get through. Otherwise your launch metric becomes a queue.

PDS matching: the quiet failure mode

Personal Demographics Service matching is where a lot of confident roadmaps meet messy reality. Names change. Addresses are shared. Welsh and English forms of the same place coexist. A failed match can look like a login failure to the user, even when authentication worked. Build a reconciliation queue and a support path before launch, not after the first batch of tickets.

The sandpit is not a demo

The NHS Login sandpit is not a place to improvise. You need test accounts, test data and a team that can get into the environment without a fortnight of ticket tennis. Onboarding review and evidence checks take time, and the queue is not yours to control. Book launch marketing only when you have a date you can defend, not a date you hope for.

A useful planning rule: assume the assurance work runs in weeks, not days. That does not mean every project takes months. It means the calendar should show the evidence gathering, the clinical safety file, the sandpit build and test, the onboarding review and the support rehearsal as separate items. If they are all one line called ‘NHS Login’, you have hidden the risk.

When the NHS App is the better front door

There is a genuinely honest alternative: point users at the NHS App. If your product is a companion, a content-led service or something that mainly needs to show people their own information, the NHS App may already provide the trusted front door. You get reach and a familiar trust signal. You give up control of the journey and some of the data flowing into your product.

That trade-off is worth naming in the decision memo. Integrate NHS Login when identity is core to the clinical or records workflow and you can staff the assurance trail. Point to the NHS App when trust and reach matter more than owning every pixel. Neither choice is a failure. Pretending the first one is quick is.

A 2026 budget sketch

Put names against the work: product lead, information governance or security lead, clinical safety officer, engineering, support and content. Put weeks against the evidence pack, the clinical safety file, sandpit testing and onboarding review. Then add the post-launch line that everyone forgets: DSP Toolkit renewal, hazard log updates, identity proofing support and PDS exception handling.

That is the real ‘simple sign-in’ budget. It is not glamorous, but it is the difference between a launch date you can hold and a slide that quietly moves to next quarter.