Entra ID Conditional Access Best Practices: Protecting NHS Data & Systems UK 2026
The real problem with NHS authentication today
When I first moved from clinical nursing into cloud infrastructure, one thing shocked me: how many NHS trusts were still treating authentication as a checkbox exercise. A username and password, maybe TOTP on a good day. Meanwhile, attackers were exploiting that gap relentlessly, and the trusts responding with blanket MFA policies were breaking clinical workflows instead of securing them.
Entra ID conditional access changes that equation. Instead of a one-size-fits-all MFA rule that frustrates nurses at 3am in A&E, you can build intelligent policies that authenticate based on context: where the person is, what device they are using, what risk signals are present. It is smarter security, not harsher security.
But getting it right in an NHS environment means understanding both the technical side and the reality of how clinicians actually work. That is what this guide covers.
What conditional access actually does
Conditional access in Entra ID (formerly Azure AD) is a policy engine that sits between a user and a Microsoft 365 application. When someone tries to log in, it runs real-time checks: is this device compliant? Is the user coming from a trusted location? Has there been suspicious activity? Based on those signals, it either allows access, blocks it, or requires an additional challenge like MFA.
The key difference from a static rule is that the policy responds to context, not just identity. A clinician accessing patient records from the staff network on a managed laptop gets one experience. A contractor trying to log in from a coffee shop on a personal device gets another.
For NHS trusts, this is essential because:
The core policies every NHS trust needs
1. Require MFA for high-risk sign-ins
Entra ID's risk detection engine evaluates every login for anomalies: impossible travel (logged in from London 30 minutes ago, now trying from Glasgow), sign-in from an unfamiliar location, sign-in from a Tor or VPN endpoint, password spray attempts, and more.
The policy: If risk level is high, require MFA. If risk level is medium or low, allow the sign-in without MFA.
This cuts frustration: staff on their normal shift do not hit MFA every single time. But attackers using compromised passwords or signing in from unusual locations are stopped immediately.
NHS specifics: You will see legitimate medium-risk scenarios: locum doctors signing in from home for the first time, or night shifts logging in from unusual times. Tune your policy to require MFA only for high-risk events, not medium, in your first few weeks.
2. Block or require MFA for external access
Anyone signing in from outside the NHS trust network (typically identified by IP range or VPN connection) gets hit with a stronger policy: either block it outright or require MFA plus a compliant device.
Why this matters in NHS: Clinicians access records from home increasingly, especially after-hours for on-call or continuity of care. You cannot block external access, but you can enforce that external access must come from a managed device (one enrolled in Intune) and must include MFA.
The policy: If the sign-in location is outside your corporate network AND the device is not compliant, either block it or require MFA and device compliance check.
3. Enforce device compliance for sensitive data
Entra ID integrates with Intune (Microsoft's device management service) to verify that a device meets your security baseline before allowing access to sensitive apps.
A compliant device, in NHS terms, typically means:
The policy: If accessing patient data applications (electronic patient record systems integrated with Microsoft 365), require the device to be Intune-compliant.
Critical point for NHS: This requires all clinical staff to use managed devices. Bring-Your-Own-Device (BYOD) policies must be abandoned for access to patient data. The good news is Intune enrolment for NHS staff is straightforward, and Intune reports a 94% reduction in security incidents among enrolled devices.
4. Require MFA for administrative actions
Any user with admin rights in Microsoft 365 or Entra ID (Global Admin, Exchange Admin, SharePoint Admin, etc.) should always authenticate with MFA, no exceptions.
The policy: Require MFA for all sign-ins to the Azure portal, Microsoft 365 admin centre, or Exchange admin centre.
NHS angle: Not just IT admins. Clinical informatics leads, department heads with delegated SharePoint admin rights, anyone with admin roles. Treat this as a mandatory gate.
5. Block legacy authentication protocols
Old protocols like Basic Authentication (used by some older on-premises systems and email clients) do not support MFA and are favourite attack targets.
The policy: Block all sign-ins using legacy authentication protocols (SMTP AUTH, IMAP, POP3, older Office clients).
NHS reality check: This one often breaks something on day one. An old clinical workstation running Outlook 2010. A legacy EHR integration using basic auth. Identify these during a pilot phase and either upgrade them or use a conditional access exception (applied to specific users or apps only, not blanket exemptions).
Implementing conditional access: the NHS playbook
Start with audit mode
Do not deploy policies in enforcement mode immediately. Create your policies in "Report-only" mode first. They evaluate every login but do not block anything. After one to two weeks, review the logs to see what policies would have affected real users.
What to look for: How many sign-ins would be blocked? Are they from expected scenarios (mobile access, night shift, agency staff) or attacks? Tune the policy before enforcement.
Pilot with a small group
Roll out enforcement to a small group of IT staff or a single department first. Ask them to report friction: "I could not access the system from home," or "I had to do MFA five times." Use that feedback to adjust.
Phase by application
Start with admin portals and sensitive apps (patient records). Then move to general productivity (Teams, SharePoint, email). Do not flip all policies at once.
Document the clinical exceptions
There will be edge cases: emergency access for contractors, external clinical partners, or legacy systems that cannot support the policy. Document every exception, who approved it, when it expires, and why. This is not a weakness; it is a compliance strength.
If you are a healthcare worker moving into IT and managing security for the NHS feels overwhelming, the Microsoft 365 Administrator Programme at SmoothOps 365 covers Entra ID, conditional access, and real-world healthcare scenarios. It is three months, on weekends, £850, and teaches you to build policies like these. [Join the waitlist at smoothops365.com/courses to get started.]
Monitoring and maintenance
Conditional access is not a set-it-and-forget-it investment. Review your policies monthly:
Use the Entra ID Sign-In Logs and Risky Sign-Ins reports to track this. If a policy is blocking more than 2 to 3% of legitimate sign-ins, it probably needs tuning.
Frequently asked questions
What is the difference between conditional access and traditional MFA?
MFA is a single factor: you use your password and then enter a code. Conditional access is a policy engine that decides whether to require MFA at all, based on context. Traditional MFA says "always use a code." Conditional access says "use a code only if you are signing in from outside the network or at unusual hours," which is faster and smarter for NHS clinical workflows.
Does conditional access slow down clinicians trying to access patient records in an emergency?
Not if configured correctly. If a clinician is on a managed device inside the hospital network, conditional access can allow them to sign in with just their password (no MFA required), because the risk is low. In an emergency, that is instant. Only external or unusual sign-ins trigger MFA. That is the whole point: faster authentication for normal, lower-risk scenarios.
Can conditional access block access from personal devices?
Yes, if you require device compliance and the personal device is not enrolled in Intune. However, this is a policy choice. Some NHS trusts allow personal devices for non-sensitive apps (Teams, email) but block them from patient records. Conditional access lets you enforce that granularly.
What happens if a clinician is locked out by a conditional access policy?
There should always be a break-glass or emergency access account (a dedicated admin account with no conditional access policies applied) that IT can use to sign in and adjust policies or grant temporary exceptions. This is a critical safety measure in any NHS environment.
Is conditional access compliant with NHS Data Security and Protection Toolkit requirements?
Yes. Conditional access provides the risk-based authentication and detailed audit trails that the DSPT expects. However, it must be part of a broader security strategy (encryption, device management, access reviews). Conditional access alone is not sufficient, but it is a critical component.
SmoothOps 365 runs live instructor-led training every Saturday and Sunday. 3 months. 50 contact hours. Keep your job while you train.