How to Apply For NHS Login Integration – Checking Prerequisites and Eligibility

NHS login has become the standard way to let people in England access digital health and care services securely. If you provide an app or website that needs to verify a patient’s identity and then authenticate them on repeat visits, integrating NHS login can remove friction for users and raise trust with commissioners. It can also avoid the cost and risk of building your own identity stack. Yet NHS login is not a free-for-all: you will need to meet strict eligibility and commissioning criteria, prove your technical and governance maturity, and follow a multi-stage onboarding process before any live traffic flows.

Tl;DR – Want to apply to integrate with NHS Login quickly? Start your NHS Login integration journey on the NHS England website here 👉 https://digital.nhs.uk/services/nhs-login/nhs-login-for-partners-and-developers/nhs-login-integration-toolkit/apply-for-nhs-login.

Understanding what is—and is not—in scope is half the battle. NHS login verifies and authenticates people; it does not grant clinical privileges or authorise access to a clinician’s system on its own. It is designed for ongoing authentication, not a one-off grab of GP credentials. It also assumes your service is free at the point of use, is sponsored or commissioned appropriately, and is deployed for users in England. Getting these fundamentals right early will save months later.

This guide explains, in depth, how to check whether your service is eligible, what prerequisites you must satisfy before you apply, and how the end-to-end onboarding works from first enquiry through to go-live. It also covers identity proofing levels, scopes and claims, and offers a practical readiness checklist that teams can use to de-risk the journey.

Who Can Integrate NHS login? Eligibility, Sponsorship and Use Cases

NHS login is designed for digital services that provide a clear health or social care benefit to people in England. At its simplest, that includes patient-facing apps that surface health information, help people manage conditions, support wellbeing, or connect patients to NHS services. A bedrock requirement is that your service uses NHS login to verify users and authenticate them on repeat visits; it must not rely on NHS login for a single-use identity check and then revert back to private credentials.

Your service must be accessible free of charge to the user at the point they receive it. Normal NHS charges, such as prescription fees, are compatible, but paywalls that gate core functionality are not. Just as important is commissioning: being listed on a procurement framework is not the same as being commissioned or sponsored. You will need a bona fide NHS organisation or a local authority to commission or sponsor your use case. That link anchors your service in the public interest and creates an accountability chain for information governance.

There is also a geographical boundary. NHS login is for services delivered to people in England, and your eligibility will be assessed on that basis. If you serve users registered with GP practices in England—or receiving NHS services in England—you’re in scope. If you hope to cater for users primarily outside England, the fit is unlikely to be right.

• Your service must deliver a demonstrable health or social care benefit to people in England, be commissioned or sponsored by an NHS organisation or a local authority, and be free at the point of use.
• NHS login is for identity verification and authentication, not clinical authorisation or one-time GP credential capture; your flow should use NHS login for ongoing sign-ins.
• Eligibility is tied to patients registered at GP practices in England or receiving NHS services in England; deployment for England is expected.
• If you run your own login alongside NHS login, you must meet the applicable national standard for authentication and verification.
• Linked NHS APIs (for example IM1 or PDS FHIR) bring dependencies: certain scopes cannot be enabled until those other integrations are live.

Technical and Data Protection Prerequisites You Must Meet Before You Apply

The simplest predictor of a smooth integration is your readiness across security, privacy, and identity. NHS login is built on modern identity protocols and an explicit risk model aligned to national standards. Before you even open the application form, get aligned on how you will design your sign-in journey, how you will protect tokens, and what personal data you will request and why.

If you offer a native sign-in flow alongside NHS login, the applicable national information standard for authentication and verification comes into play. In practice, that means demonstrating clear identity assurance levels matched to the risk of the transactions you enable, limiting the personal data you collect to what is strictly necessary, and ensuring robust technical controls: TLS everywhere, secure token storage, server-side session management, and appropriate logging with tamper resistance. Your privacy notices, consent mechanisms, and data protection impact assessment should be drafted and owned by named stakeholders—not written on the fly during onboarding.

Data residency is non-negotiable for many health contexts. You will need to disclose where you host and process data, including sub-processors and failover regions. Expect close scrutiny of any transfers outside the UK. Transfers into the EU/EEA may be considered with appropriate safeguards; transfers beyond the UK and EU/EEA are generally out of scope for live patient data. Multi-region cloud designs should be carefully architected to avoid accidental replication of personal data into non-UK regions, including where observability tools and backups are configured. If you rely on global vendor support arrangements, confirm that diagnostic access is constrained and auditable.

Identity by design matters as much as privacy by design. Your user journey should keep NHS login as the front door for repeat authentication, not as a one-time proofing step. Avoid any pattern that extracts GP system credentials or re-uses them in a way that bypasses NHS login on subsequent visits. If your product integrates with other NHS services—such as an IM1 Partner-Facing Service (PFS) interface or the PDS FHIR API—map those dependencies early. For example, you cannot use a GP surgery information scope within NHS login’s integration test or live environments until your IM1 route is live (either directly or via an approved third-party connector). Those dependencies are gating items for scopes; building your timeline around them prevents last-minute surprises.

From a protocol perspective, implement OpenID Connect with a conservative security posture: standard code flow with PKCE, nonce checking to mitigate replay, and short-lived tokens. Treat ID tokens as sensitive and never persist them in client-side storage. On the back end, adopt strict audience checks, rotate keys, and monitor token use. Your session model should align with the identity proofing level you request: higher-risk actions merit tighter re-authentication prompts and shorter sessions. Where your app runs on multiple device types (web, iOS, Android), ensure consistent behaviour and shared security expectations—an uneven experience is a common source of assessment feedback.

Artificial intelligence is increasingly part of product roadmaps, but AI in health contexts needs careful governance. You will be asked to declare any AI use, including third-party models, where they are hosted, and the data they process. If models are trained or fine-tuned on personal data, document your legal basis, explain your safeguards, and show how users can understand the role of automation in outcomes that affect them. Even when AI does not touch personal data directly, be ready to evidence how you prevent leakage of sensitive prompts or outputs to uncontrolled regions or vendors.

The End-to-End Application and Onboarding Journey

Once your prerequisites are in good shape, you will create a developer account and start the digital onboarding flow. Treat this as more than a formality: the quality of your submission sets the tone for the evaluation. Provide a clear, concise description of your service, the user journeys that require NHS login, the claims you intend to request, and the exact lawful basis for personal data processing. Include your commissioning or sponsorship context and identify the NHS or local authority partner who will vouch for the use case.

If the initial review suggests your service is within scope, you will be invited to an Application Review Call. This is a working session to validate the use case and surface any red flags early. Expect to cover how NHS login will be integrated in your product, your target timescales, the hosting and processing locations for all data (including telemetry, backups, and content delivery), where your service will be deployed geographically, current commissioners and any live commissioning discussions, and dependencies on other NHS APIs such as IM1 PFS or PDS FHIR. You will also be asked about the identity verification and authentication level your product needs, using the transaction risk examples from the national standard as a reference point. Finally, you will be asked what user information you need—for example contact details or the NHS number—based on the published scopes and claims guidance. Come prepared: ambiguity here usually results in follow-up actions.

Following the call, the integration team will decide whether your use case should be put forward to the Partner Integration Board. Think of the board as a cross-functional gate that checks the public value, compliance posture and operational readiness of your proposal. The board can approve the use case to proceed, reject it if it is out of scope, or defer the decision pending additional information. Approval to proceed is not permission to go live; it’s permission to enter the next development and testing stages. Deferral is common where data residency, commissioning, or identity risk alignment is unclear; treat it as an opportunity to tighten your artefacts rather than a setback.

Assuming approval, you will move into technical integration, testing and assurance. This phase generally includes environment setup, configuration of test and integration endpoints, and alignment with the identity journey requirements. Many teams underestimate non-functional testing: plan for performance baselines, resilience tests, error handling for edge cases in the sign-in flow, and accessibility conformance. If you are requesting higher identity proofing levels, be ready to demonstrate that your UI patterns help users complete photo ID and liveness checks successfully, and that you manage drop-offs gracefully with clear support routes.

Timelines vary according to complexity, but most partners complete the overall process in three to four months; a well-prepared, straightforward use case can move faster. Communication is typically run through Microsoft Teams, and you should expect iterative feedback rather than a single pass/fail moment. Progress depends on your responsiveness to actions, the maturity of your governance documents, and the lead time for any linked APIs. If your use case relies on an IM1 integration or a PDS FHIR capability, sequence your work so that those dependencies land before you request the related NHS login scopes.

The final stretch towards live status includes operational checks. You will need to evidence monitoring, alerting, incident response and user support pathways that are proportionate to the risk of your service. If you operate out-of-hours, your support model should reflect that. Make sure you have a rollback plan for identity-related releases and that your change process prevents accidental changes to sign-in behaviour. When all gates are met, you can proceed to live. Continue to treat identity as a living service: track metrics such as sign-in success, abandonment in verification steps, and support contact drivers; use those insights to iterate without compromising security.

Choosing Identity Proofing Levels, Scopes and Claims for Your Service

One of the most consequential decisions in your application is the identity proofing level you request. The national standard provides transaction-level examples to help map risk to proofing requirements. A wellbeing app that lets a user record mood may be satisfied with a lower assurance level; an app that lets a user view or manage sensitive clinical information, or initiate transactions with financial or safety implications, will demand stronger verification such as photo ID and liveness checks. The art is in choosing the minimum level that appropriately mitigates risk; over-proving identity can hurt completion rates and generate support queries, while under-proving identity can leave you exposed.

Consider how identity proofing interacts with session management. If your app exposes mixed-risk features, design re-authentication prompts that appear only when a user performs higher-risk actions, rather than interrupting low-risk browsing. Use short-lived tokens and server-side sessions to avoid long windows of exposure, and make it easy for users to see when they are signed in. If a family member or carer might use the same device, consider explicit sign-out prompts after sensitive actions. These patterns often deliver more real-world safety than a blanket increase in proofing level.

Scopes and claims should be ruthlessly minimal. The default profile and email claims may suffice for many apps; requesting the NHS number should be justified by a business process that truly needs it, such as matching to records in a safe, consent-driven way. Similarly, if you intend to show details about a user’s GP practice, plan for the fact that the related scope is contingent on your IM1 route being live. The more ambition you have in scope, the more dependencies you invite; sequenced delivery—launching with the minimum viable claims and then expanding—is a pragmatic way to get value to users sooner while still meeting governance expectations.

Technical implementation choices affect your ability to uphold these decisions. Avoid storing tokens on the client; use secure server-side session stores with rotation and revocation, and ensure that any analytics scripts are isolated from identity artefacts. Build a strong consent experience that explains why a claim is requested and what value it unlocks. If you later decide that you no longer need a claim, remove it proactively and communicate the change in your privacy notice. Finally, keep a tidy audit trail: when scopes change, record the rationale, approval and any downstream impact so you can answer questions crisply during assessments or audits.

Practical Tips, Common Pitfalls and a Readiness Checklist

The fastest integrations are rarely the ones with the fewest features; they are the ones that arrive with a clear story, minimal surprises and a team that uses the onboarding phases to validate, not to discover. Treat the eligibility check as a gate, not a hoop. Secure a commissioning or sponsorship letter that is specific about your use case, your user base and the intended benefits. This provides the backbone for decisions later and pre-empts questions about public value. Be candid about data residency. If your preferred vendor configuration replicates logs or telemetry outside the UK, either redesign it or come prepared with a robust mitigation that keeps personal data at home.

On the technical side, lean into reference implementations and harden them. OpenID Connect with code flow and PKCE, strict nonce checking, short-lived tokens and back-end session management is a well-trodden path; do not invent your own patterns. Build your sign-in UI to handle verification edge cases gracefully—timeouts, camera permissions, poor connectivity—and set expectations with users without oversharing about the identity provider’s internal processes. Prepare environment parity: staging should mirror production sufficiently for meaningful performance and accessibility checks.

Assurance artefacts are a frequent source of delay. Draft your DPIA, security model, and user-facing privacy communications early. Name your accountable owners and, where needed, your Senior Responsible Officer. If you use AI, describe the role it plays and where models run; if it touches personal data, explain your legal basis, minimisation approach, and how individuals can understand and challenge outcomes. Keep your engineering and legal teams in the same loop; unanswered questions from one side will stall the other.

• Confirm your eligibility and sponsorship position: identify your NHS or local authority sponsor, document the specific use case and benefits, and ensure the service is free at the point of use.
• Map data residency thoroughly: list all hosting regions, sub-processors, backups and observability tools; re-configure anything that would replicate personal data outside the UK; document any EU/EEA transfers and safeguards if applicable.
• Choose identity proofing levels and scopes deliberately: align to transaction risk, pick the minimum viable claims, and plan a phased approach for any scopes that depend on IM1 or PDS integrations.
• Prepare assurance artefacts early: DPIA, security architecture, session model, consent flows, privacy notice updates, incident response and change control; nominate accountable individuals.
• Build and test the identity journey: implement OIDC code flow with PKCE, nonce checks, token rotation, server-side sessions, and accessible UI that handles verification edge cases; validate performance and failure modes.
• Get commissioning evidence and governance aligned: secure a clear letter or contract of sponsorship, ensure procurement and IG teams are engaged, and keep a single source of truth for approvals and scope changes.

Plan the onboarding cadence: allocate a product owner for the Microsoft Teams channel, respond promptly to actions, and sequence dependencies (e.g., IM1) ahead of scope requests; define go-live criteria and rollback plans.

By approaching NHS login as a strategic capability—not merely a compliance box—you improve both user experience and organisational resilience. Eligibility, commissioning and data residency are the foundations; identity proofing and scopes are the structure; and your operational readiness is the roof that keeps the rain out. Do the groundwork well and the rest of the build proceeds quickly.

There is real user value in getting this right. People expect to sign in with confidence, to know what information they are sharing and why, and to trust that their data remains in safe locations. Commissioners and clinical partners expect clear governance and robust incident response. NHS login integration, done well, gives you a credible, modern sign-in experience and frees your team to focus on the unique value your service brings—be that better condition management, faster access to care, or more effective prevention.

Most of what slows teams down is avoidable. Over-asking for claims, loose session models, unclear data maps, and late discovery of third-party transfers are self-inflicted wounds. The remedy is deliberate scoping, early documentation, and a security-first technical design. If your roadmap includes deeper NHS integrations, tackle their prerequisites in parallel so you do not end up waiting on external gates to unlock identity scopes. And remember that “approved to proceed” is the start of the real work: treat every integration test, accessibility fix and performance tweak as a rehearsal for live operations.