Most NHS Trusts now have the Microsoft security tooling in place. The question is whether it is configured to genuinely reduce ransomware risk, or simply installed. This article sets out a practical, progressive approach to endpoint hardening that acknowledges clinical constraints while moving from detection toward prevention and true resilience.
The NHS Has the Tooling. The Question Is Whether It Is Configured.
Over the past several years, NHS Trusts have undertaken a significant transformation in their endpoint estate. Most organisations have now migrated to Windows 11, standardised on Microsoft Defender for Endpoint, and established central telemetry feeding a national SOC. Cyber assurance has increasingly aligned to the CAF framework, and the DSPT has raised the baseline expectation for endpoint security across the sector.
In most cases, these changes were driven by licensing deadlines, end-of-life pressure and operational necessity. Clinical continuity rightly took precedence over structured hardening, and programmes were delivered against tight timelines with limited disruption windows. That context was the right one at the time.
But the environment has now largely stabilised. The tooling exists. The question facing most NHS cyber teams is no longer whether they have Microsoft Defender or Windows 11 — it is whether those tools are configured to genuinely reduce ransomware risk, or simply installed.
Those are very different things.
Understanding the Operational Reality
Any realistic approach to endpoint hardening in an NHS Trust has to begin with an honest account of the constraints. Clinical systems are frequently fragile, vendor-managed, and bound by support agreements that restrict configuration changes. Downtime windows are limited and contested. Cyber teams are typically small relative to the estate they manage. GPO inheritance in large, historically complex environments can make targeted policy changes genuinely difficult. MECM remains the dominant management platform in most Trusts, with Intune available but underused. And legacy antivirus exclusions — often created years ago for specific applications — have in many cases been carried directly into Defender without review.
Adding to this, many estates still have widespread local administrator rights, creating both a management challenge and a significant security exposure. Security teams operating in this environment are not resistant to hardening for its own sake. They are managing patient safety risk alongside cyber risk, and they need an approach that is progressive, evidence-based and safe to implement in clinical settings.
Why Endpoint Hardening Is the Right Priority Now
Ransomware attacks against healthcare organisations follow a recognisable pattern: initial access via phishing or credential compromise, followed by script or macro execution, credential dumping from LSASS, lateral movement using PSExec or WMI, persistence, and eventually domain-wide ransomware detonation. This is not a novel attack model — it is well-documented, widely replicated and consistently effective against estates that have not systematically addressed the individual steps in the chain.
Windows 11 and Microsoft Defender for Endpoint contain controls that directly interrupt this chain at multiple points. Attack Surface Reduction rules, Windows Defender Application Control, and properly configured Defender policies can each break specific steps in the sequence. The challenge in most NHS environments is not the absence of these tools — it is that they are running in audit mode, partially configured, or not configured at all. Turning them into genuine prevention controls requires deliberate, phased implementation.
Attack Surface Reduction: Turning Detection into Prevention
Microsoft's own guidance recommends running ASR rules in audit mode first, assessing the impact on line-of-business applications, and then progressively moving to enforcement. In NHS environments, this sequencing is not just recommended — it is essential. The wrong rule enforced without prior testing can disrupt a clinical system, and that risk has to be managed carefully.
The ASR rules with the highest impact in healthcare environments fall into four broad categories.
The Office and macro controls — blocking Office from creating child processes, blocking Office from creating executables, blocking Office from injecting code into other processes, and blocking Win32 API calls from macros — together break the macro-to-PowerShell-to-ransomware execution chain that underpins a significant proportion of commodity ransomware attacks. These rules have relatively low impact on standard clinical workflows and should be among the first to move from audit to enforcement.
Script and download controls address the loaders that deliver ransomware payloads: blocking obfuscated scripts, blocking executable content from email and webmail, and blocking JavaScript and VBScript from launching downloaded executables. These disrupt the delivery mechanisms that typically follow initial access, and are particularly important in estates where phishing remains the primary entry vector.
Credential and escalation controls target the post-compromise phase. Blocking credential stealing from LSASS directly addresses one of the most common techniques used to pivot from a workstation to server-tier access. Blocking the abuse of vulnerable signed drivers prevents a technique that has become increasingly common in more sophisticated ransomware operations. In estates with broad local admin rights, these controls are particularly important.
Lateral movement controls — blocking PSExec and WMI process creation, and blocking WMI event subscription persistence — reduce the blast radius once an account is compromised. They are not a substitute for AD tiering, but they provide meaningful friction against the most common lateral movement techniques.
The critical point about ASR rules is this: running in audit mode indefinitely is not a neutral position. It is passive risk acceptance. Audit mode without a defined transition timeline to enforcement means the organisation is collecting data about attacks it is not preventing.
Windows Defender Application Control: The Step Beyond ASR
While ASR disrupts specific malicious behaviours, Windows Defender Application Control addresses a more fundamental question: what is allowed to execute on this device at all?
In most NHS estates today, if a user or an attacker can drop a new executable onto a device, it will typically run — and be detected or blocked only afterwards, if at all. WDAC changes that model. Rather than attempting to identify and block malicious behaviour after execution begins, WDAC prevents unapproved code from running in the first place. It enforces application allowlisting using Microsoft-trusted signing, enterprise signing, file hash rules, publisher rules and Intelligent Security Graph reputation.
This matters in healthcare for specific reasons. Ransomware increasingly uses newly compiled payloads, signed but malicious binaries, renamed system tools and commodity loaders — techniques designed specifically to bypass behaviour-based detection. ASR rules help, but they are targeted at known behavioural patterns. WDAC reduces the risk from unknown executables, limits the impact of zero-day ransomware, and protects against user-executed droppers that arrive via phishing or removable media.
Historically, WDAC has been considered too disruptive for healthcare environments. That perception usually reflects poor rollout methodology rather than an inherent incompatibility with clinical settings. Microsoft supports a staged deployment approach — audit mode to collect execution events, baseline policy creation from that data, ring-based enforcement starting with the least sensitive systems, and targeted exceptions for applications that genuinely require them. In practice, WDAC can be deployed first on IT devices, then on high-value servers, then on non-clinical user estates, with separate and more permissive policies for fragile legacy clinical systems.
WDAC does not need to be universal to deliver meaningful value. Even partial deployment — beginning with Tier 0 systems such as Domain Controllers, where it should be considered a baseline hardening requirement — dramatically reduces the attack surface available to ransomware operators.
CAF Compliance: Designing for Where the Bar Is Heading, Not Where It Sits Today
NHS endpoint security aligns to the NCSC Cyber Assessment Framework via the DSPT. CAF is outcome-focused and evolves over time. The profiles define minimum expectations, not best practice — and those expectations will continue to rise as threats develop and as national policy matures.
Designing endpoint security to meet the minimum current CAF threshold creates a structural problem: each time the framework updates, organisations find themselves in a cycle of gap assessment and remediation. The more effective approach is to build toward measurable control coverage, automation, drift detection and progressive hardening — not to ask what the minimum requirement is today, but to design for where the framework will be in two or three years.
The NCSC's own endpoint principles reinforce this direction. Controls must be consistently configured, centrally monitored, resistant to tampering, and capable of supporting logging and incident response. They must contribute to ransomware mitigation at scale. The CIS Controls framework similarly emphasises prevention and control of malicious code execution at enterprise scale, with automation and integration into detection and response as explicit objectives.
WDAC, properly enforced ASR rules and well-configured Defender together align strongly with both frameworks. Organisations that implement them properly now will find future CAF assessments considerably more straightforward.
Moving from Legacy Management to Modern Control
Most NHS endpoint estates are still managed primarily through GPO, MECM and on-premises configuration models. These approaches were built for a different era — one of static, on-premises environments with predictable device populations. They were not designed for granular security policy targeting, rapid ring deployment, compliance-driven enforcement or automated posture visibility. As endpoint hardening becomes more sophisticated, the limitations of legacy management become a ceiling on what is achievable.
Co-management — running MECM and Intune in parallel — is frequently positioned as the migration path forward, and it is certainly better than MECM alone. But co-management should be understood as a transition state, not a destination. It adds complexity, creates split policy authority, and limits access to cloud-native capabilities including Autopatch, advanced compliance policies and streamlined application delivery. Running both platforms in parallel indefinitely is an architectural compromise that constrains the very security outcomes this roadmap is trying to achieve.
The north star is cloud-native Intune management: devices enrolled directly into Entra ID, security policy delivered entirely from the cloud, application management available through the central tenant, and Autopatch handling patching without the overhead of MECM infrastructure. This state is not just cleaner to operate — it is fundamentally more secure. Policy enforcement is consistent, drift detection is automated, and compliance is tied to device identity in real time.
This is also where identity strategy and endpoint hardening converge. Achieving cloud-native device management is not a separate workstream from identity modernisation — it is the same journey. When devices are Entra-joined, identities are in Entra, and management is in Intune, security can be automated in ways that are simply not possible in a hybrid estate built around on-premises infrastructure. Conditional access, device compliance policies and risk-based authentication all function at their full potential only when the device management layer has caught up with the identity layer.
The path there requires a structured decommission plan for MECM, a device replacement or re-enrolment programme for older estate, and engagement with the central application management services that will progressively replace local MECM delivery. Organisations that plan for this now — rather than consolidating further on co-management — will find themselves in a substantially stronger security position within a realistic planning horizon.
A Practical Hardening Roadmap
For NHS Trusts looking to move from minimum compliance to genuine endpoint resilience, the following phased approach provides a structured path that can be adapted to local constraints.
Phase 1 — Stabilise the baseline. Inventory all Defender exclusions and remove those without current justification. Audit which ASR rules are deployed and in what mode. Enable Tamper Protection across the estate to prevent configuration drift. Begin removing unnecessary local administrator rights.
Phase 2 — Core ASR enforcement. Move Office and script ASR rules from audit to block, having completed the audit phase and addressed any identified conflicts. Enable LSASS protection. Begin reducing risky Defender exclusions systematically.
Phase 3 — Lateral movement reduction. Enforce the PSExec and WMI ASR rules. Implement Active Directory tiering in parallel. Deploy Defender for Identity to provide visibility into identity-based attack techniques.
Phase 4 — Introduce WDAC. Deploy in audit mode on IT devices and Tier 0 servers first. Use the audit data to build baseline allow policies that reflect actual application usage. Begin ring-based enforcement, prioritising privileged users — IT administrators, finance staff and executives — where the risk of targeted attack is highest.
Phase 5 — Modernise management. Shift security policy delivery to Intune. Automate compliance visibility and drift detection. Enable granular, risk-based device profiles that allow different hardening levels for different device classes. Implement automated patching where the clinical risk assessment supports it.
The Strategic Point
The NHS has already achieved something significant: operating system standardisation, unified endpoint telemetry and national SOC integration. These are not trivial accomplishments in an estate of this complexity. They represent a genuine platform for the next stage of improvement.
That next stage is not about buying more security products. It is about enforcing what is already deployed, reducing reliance on legacy management patterns, automating configuration and moving from a detection-led posture to a prevention-led one. Designing for tomorrow's CAF expectations, rather than today's minimum, is how that transition gets embedded rather than repeatedly restarted.
In healthcare, operational safety will always be paramount — and rightly so. But cyber resilience is now inseparable from patient safety. A properly hardened Windows 11 estate, with ASR rules in enforcement, WDAC deployed progressively and Defender configured beyond its defaults, is one of the most powerful and achievable improvements NHS Trusts can make with the tools they already have.
