Hardening Windows 10 and 11 Workstations: The ACSC High-Priority Controls

The Australian Cyber Security Centre’s “Hardening Microsoft Windows 10 and Windows 11 Workstations” publication (last updated July 2024) is one of the more comprehensive endpoint-hardening references the security community has. It runs to ~80 controls grouped into High, Medium, and Low priorities, each tied to specific Group Policy settings, and most of them apply to Windows Server too (with the unsurprising exception of Domain Controllers). This article walks through the 19 high-priority controls — the ones the ACSC explicitly says to do first — with the GPO paths, recommended values, and the practical context for what each one actually defends against.

Source attribution: this is a derivative reference based on the ACSC publication. Anything technical (GPO paths, recommended values, ASR rule GUIDs) is preserved as-stated; the framing, prioritisation guidance, and operational notes are InfoTech Ninja’s. For the authoritative document, see cyber.gov.au → Hardening Microsoft Windows 10 and Windows 11 Workstations.

Before you start

The ACSC document is explicit that all of this needs thorough testing before rollout to production endpoints. Hardening controls have second-order effects: an over-aggressive Application Control rule blocks a developer’s build tool, an Attack Surface Reduction rule blocks a legitimate macro, a Credential Guard configuration breaks a legacy single-sign-on integration. The pattern that works is: stage the controls in audit mode, capture what would have been blocked, fix the false positives, then enforce. Don’t skip that step.

The GPO paths and setting names below are taken from the document; they’re accurate against Windows 10 22H2 and Windows 11 23H2. Earlier versions may differ slightly. If you’re managing endpoints through Microsoft Intune (or Endpoint Manager) instead of Group Policy, every setting here has an Intune equivalent — either as a configuration profile setting or via the “Import GPO” function.

The High Priorities subset is what we cover here. The Medium and Low priority controls (account lockout, anonymous connections, antivirus, Attachment Manager, AutoRun, BitLocker, BIOS passwords, NetBIOS, PowerShell logging, Remote Assistance, scripts, server message block sessions, session locking, software firewalls, UEFI passwords, USB media, etc. — another ~50 controls) are equally important; they’re just not the first thing you do.

1. Application hardening

Most applications ship with default configurations that prioritise functionality over security. Microsoft Office allows untrusted macros to auto-execute by default. PDF readers enable JavaScript out of the box. Browsers ship with permissive content policies. Each of these defaults is a documented attack vector, and each can be tightened without breaking legitimate workflows — if anyone bothers to tighten it.

The ACSC’s position: every application that ingests content from untrusted sources (browsers, email clients, Office apps, PDF readers, web browser plugins, runtime platforms like .NET and Java) should have its in-built security functionality enabled and its non-essential functionality disabled. Microsoft publishes Security Baselines for their products on the Microsoft Security Baselines Blog — for any Microsoft application you’re shipping to endpoints, the baseline is the right starting point.

For Office specifically, the ACSC has its own dedicated companion publication: Hardening Microsoft 365, Office 2021, Office 2019 and Office 2016 — it’s where the macro-control settings, ActiveX restrictions, and the OLE blocking guidance live. Worth treating as a paired reference to this one.

2. Application versions and patches

An unpatched application is exploitable on a known schedule: between vulnerability disclosure and the first public exploit is usually weeks; between exploit and worm-grade automation is usually months. The window where you’re “ahead” of attackers shrinks every year. The ACSC’s recommendation is to apply application patches in a timeframe matched to the vulnerability severity and any compensating controls already in place — with the higher-impact applications (browsers, Office, PDF readers, runtimes) prioritised because they handle untrusted content.

Two operational notes worth flagging:

• If a vendor still supports an older version with security patches, you should still upgrade to the latest version. Older supported versions get vulnerability fixes but miss the security architecture improvements that newer versions bring (modern sandbox models, mitigations like CFG and CET, etc.). Stay current, not just patched.
• The companion ACSC publication Patching Applications and Operating Systems defines the actual timeframes (e.g. 48 hours for critical, 2 weeks for high, etc.) and is where you should anchor your SLA targets.

3. Application control

Application control — the ability to allow or deny code execution based on policy — is one of the few technical controls that meaningfully changes attacker economics. An endpoint that will only execute approved binaries is dramatically harder to weaponise than one that runs anything a user can save to disk. The ACSC has long ranked this as one of the most impactful single controls on the list.

Two implementation principles the document is explicit about:

• Build the allowlist from scratch, not from observation. Cataloguing every executable currently on a workstation and allowlisting all of them encodes any malware already present. The right starting point is “known-good business applications” explicitly enumerated.
• Define your own ruleset rather than taking a vendor’s. Application control vendors’ default rulesets exist to maximise compatibility, not to maximise security. Use them as input; don’t treat them as the answer.

And, like every other control, the ruleset needs ongoing review — new applications get deployed, old ones get retired, the ruleset should track. The companion ACSC document Implementing Application Control covers the technical detail across Windows Defender Application Control (WDAC) and AppLocker.

4. Attack surface reduction (ASR)

ASR is part of Microsoft Defender Exploit Guard. It’s a rule-based engine that blocks specific, common attack patterns — particularly the ones that exploit legitimate Office functionality (macro-spawned executables, child process creation, code injection, etc.). It requires Microsoft Defender Antivirus as the primary real-time scanner; if you’re running a third-party AV, that AV usually has equivalent rules but the ASR engine itself is off the table.

The full ASR rule set the ACSC recommends enabling, with the GUIDs the policy uses to identify each rule:

All of these get configured under one Group Policy setting:

Operational note: roll ASR out in audit mode (2) first. Some of these rules — particularly “Block executable files unless they meet a prevalence, age, or trusted list criterion” — will block legitimate but uncommon binaries. Audit mode logs what would have been blocked without breaking anything; review the audit events, allowlist legitimate cases, then flip to Block.

If you’re running a non-Microsoft antivirus, ASR isn’t available; check whether your AV has equivalent behavioural-blocking rules. For older Windows versions where ASR doesn’t exist at all, alternative mitigations are needed for things like Dynamic Data Exchange (DDE) attacks — the ACSC document has a separate appendix on those.

5. Credential protection

Cached credentials, credentials in memory, and the protocols that hand them around are the most-attacked piece of every Windows endpoint. Pass-the-hash, pass-the-ticket, Mimikatz, LSASS dumping — all the techniques you read about in incident reports — target this surface. The ACSC bundles several distinct controls under “credential protection”:

Limit cached domain credentials

By default Windows caches the credentials of the last 10 domain users to sign in, in the local SAM database, so users can sign in even if the DC is unreachable. That’s convenient and also a juicy target — an attacker with admin on the workstation can extract those hashes and crack them offline. Limit the cache to one previous logon (you still get the “DC unreachable” convenience for the most recent user without giving up nine other accounts).

Disable WDigest, enable Credential Guard

WDigest is a legacy authentication protocol that, when enabled, kept users’ cleartext passwords in LSASS memory for protocol compatibility. Mimikatz famously dumped them straight out. Disable it; nothing modern needs it. Credential Guard uses virtualisation-based security (VBS) to isolate LSASS and the secrets it holds in a separate, attacker-inaccessible enclave. Together with LSA running as a protected process (PPL), this closes the most-abused credential extraction paths.

The MS Security Guide settings ship as part of the Microsoft Security Compliance Toolkit — you have to install the toolkit to get those policy templates into your GPO editor.

Hardware prerequisites matter here. VBS, Credential Guard, and the “Enabled with UEFI lock” options require a TPM 2.0, UEFI firmware, virtualisation-extension-capable CPU, and (for full Secure Launch) modern hardware that supports the right firmware features. Older hardware will report errors when these settings are pushed; the modern ACSC guidance assumes modern hardware. Workstations that don’t meet the bar should either be hardware-refreshed or excluded from this GPO with security-filtering until they can be.

6. Controlled Folder Access

Controlled Folder Access is the anti-ransomware piece of Microsoft Defender Exploit Guard. It blocks untrusted processes from modifying files in protected folders — if a process isn’t on the allow list and tries to write to a protected folder, the write fails. Like ASR, it requires Microsoft Defender Antivirus as the primary real-time scanner.

By default, Controlled Folder Access protects the standard user profile folders (Documents, Pictures, etc.). For environments using folder redirection, the redirected paths on the file server are a separate matter — protect them with backups and immutable snapshots; Controlled Folder Access lives on the endpoint and won’t see redirected file servers as “its” folders.

Same audit-then-enforce pattern as ASR: deploy in audit mode, see what legitimate applications would have been blocked, allowlist them, then enforce.

7. Credential entry

Every time a user types a credential, there’s a window for keylogging malware to capture it — unless the prompt is shown on the Secure Desktop, an isolated session that user-mode malware can’t reach. The credential entry hardening is about forcing every credential prompt onto the Secure Desktop and removing the cosmetic “helpful” features that leak information to an attacker (showing local users on the logon screen, enumerating administrator accounts during elevation, the password-reveal eye icon).

The CTRL+ALT+DEL requirement deserves a note: it’s the most commonly bypassed of these for “user friendliness” reasons, and it’s also one of the most useful. The Secure Attention Sequence (CTRL+ALT+DEL on a physical keyboard) is the only keystroke combination that user-mode software cannot intercept, by design. A logon screen reached via CTRL+ALT+DEL is provably from Windows; one that’s already there isn’t. Cosmetically inconvenient; functionally a real defense.

8. Early Launch Antimalware (ELAM)

Trusted Boot is the chain of trust from UEFI through to the OS, and ELAM is the link in that chain that lets antimalware vendors register a driver as the first non-Microsoft driver loaded at boot. The ELAM driver verifies subsequent drivers as they load, blocking malicious ones before they can hide themselves. Without ELAM, a rootkit driver that loads before any antimalware is invisible to that antimalware once the system is up.

Four policy options for what ELAM lets boot:

• Known good only
• Known good and unknown
• Known good, unknown, and bad-but-critical
• All drivers (effectively no policy)

The ACSC recommends “Good, unknown and bad but critical” — the third option. This blocks known-bad drivers that aren’t critical for boot, allows unknown drivers (necessary for any legitimate driver the AV hasn’t classified yet), and allows bad-but-critical drivers (because blocking them would brick the boot, which is operationally worse than the risk).

9. Elevating privileges (UAC)

User Account Control is the “are you sure?” prompt before privileged operations. It’s also one of the most-disabled controls because the prompts annoy users. Don’t disable it. Configure it to be useful instead. Two principles:

• Privileged operations must require credential entry on the Secure Desktop. The default “just click yes” prompt is essentially worthless — any malware running in the user’s session can click yes too. Requiring credential entry forces the user to actively prove they’re still in control.
• Standard users should not get an elevation prompt at all. The default behaviour for standard users (prompt for credentials of an admin account) is also a key-logging window. Set it to “Automatically deny elevation requests” — standard users who need to do admin work should sign out and back in as an admin, not enter admin credentials inside their standard session.

10. Exploit protection

Exploit protection is the modern successor to EMET (Enhanced Mitigation Experience Toolkit). It applies process-wide and per-application security mitigations that make exploit development harder — Control Flow Guard (CFG), DEP, mandatory ASLR, bottom-up ASLR, SEHOP, heap corruption protection, etc. Most of these have negligible runtime cost; the per-application mitigations sometimes break older or unusual applications, so test in audit mode first.

The XML file path matters operationally: define the exploit protection settings using Get-ProcessMitigation on a reference machine, export with Get-ProcessMitigation -RegistryConfigFilePath, store the XML on a network share, and point the GPO at that share. Centralising the file means you can adjust mitigations without redeploying GPOs.

Approach: system-wide mitigations (CFG, DEP, ASLR, SEHOP) can typically be enabled across the board. Per-application mitigations need staged rollout — start with applications that ingest internet content (browsers, Office, PDF readers, media players) and audit before enforcing.

11. Local administrator accounts (LAPS)

The built-in local Administrator account is one of the most-attacked credentials in any Windows estate. If every workstation has the same local admin password (whether by image, by GPO password, or by laziness), one compromise becomes lateral movement to every workstation in the environment. Even with unique passwords, the well-known security identifier (S-1-5-21-domain-500) makes the account easy to enumerate and brute force.

The fix is Microsoft LAPS (Local Administrator Password Solution) — a free Microsoft tool that automatically generates a unique random password for the local admin account on each domain-joined computer, stores it encrypted in Active Directory (or Entra ID), and rotates it on a schedule. The recovery flow when you actually need local admin (broken machine, can’t reach domain) is to read the current password from AD via the LAPS UI or PowerShell.

Prerequisite: LAPS in modern Windows is built into the OS (no separate client install) but the AD schema and password-storage attributes need to be configured by an Enterprise Admin via Update-LapsADSchema on a Windows Server 2019+ DC. Microsoft’s LAPS docs cover the schema extension in detail.

12. Measured Boot

The third pillar of Trusted Boot, after Secure Boot and ELAM. Measured Boot uses the TPM to record cryptographic measurements of every component loaded before the ELAM driver — the firmware, bootloader, kernel, early drivers. The resulting log can be evaluated by remote attestation services to detect tampering of boot components. If a rootkit replaces a boot driver, the measurement chain breaks; an attestation server sees the broken chain and can flag the device.

Measured Boot itself doesn’t have a single GPO toggle — it’s a hardware capability that’s automatically used when a TPM is present and Measured Boot evaluation is consumed by your antimalware or device-attestation infrastructure. The high-priority recommendation is to use hardware that supports it (UEFI + TPM 2.0) and to ensure your endpoint security tooling actually consumes the measurements. Without an attestation consumer, Measured Boot is collecting evidence nothing reads.

13. Microsoft Edge

Microsoft Edge (Chromium-based) replaced the legacy Internet Explorer 11 and is the recommended browser for Windows 10/11 environments — principally because it’s actively maintained, integrates with Microsoft Defender SmartScreen, and ships with a security architecture that legacy IE can’t match. Use it where possible.

Edge is configured via Group Policy through a separate set of administrative templates (Microsoft Edge ADMX files) that have to be installed in your Central Store before the policies appear in the GPO editor. Once installed, the recommended hardening is published on the Microsoft Security Baselines Blog — enable SmartScreen for downloads and phishing, disable risky features like password autofill for unmanaged accounts, restrict extensions to a publisher allowlist.

The ACSC document explicitly defers the per-setting list to Microsoft’s baseline rather than reproducing it — which is sensible because the baseline updates more often than this publication does. Pull the current baseline from Microsoft, import into your GPO infrastructure, customise as needed.

14. Multi-factor authentication

Single-factor passwords are inadequate for any privileged account, any remote access, or any access to sensitive data. The ACSC’s recommendation is hardware-based multi-factor authentication — a TPM-backed credential, a FIDO2 security key, or an equivalent — for those high-value scenarios. Software-based MFA (TOTP from an app, SMS) provides some uplift over password-only but is bypassable by SIM swap, push fatigue, or AiTM phishing kits.

Windows Hello for Business (WHfB) is the Microsoft-native answer. It binds a credential to the device’s TPM, unlocked by a local PIN or biometric. The combination is genuinely two-factor (something you have: the device; something you know or are: PIN/biometric), and the credential never leaves the TPM — even if an attacker dumps memory, they can’t get usable secrets out.

For deployment patterns and the broader hybrid identity story, the ACSC has a separate companion publication Implementing Multi-Factor Authentication, and Microsoft has detailed guidance on FIDO2 security keys for Windows logons (worth implementing for tier-0 admin accounts even if WHfB is the baseline for everyone else).

15. Operating system architecture (x64 only)

The x86 (32-bit) versions of Windows lack security features that the x64 versions have natively: hardware-based DEP kernel support, Kernel Patch Protection (PatchGuard), mandatory device driver signing, and no support for malicious 32-bit drivers. There’s effectively no reason to deploy 32-bit Windows on modern hardware — the recommendation is x64 only, period.

This isn’t a GPO setting; it’s an imaging / procurement decision. Confirm your standard operating environment image is 64-bit, and that any 32-bit holdouts in your fleet have a refresh date.

16. Operating system patching

The same logic as application patching: an unpatched OS is exploitable on a known schedule, and the window between patch release and exploit availability gets shorter every year (1-day attacks — exploits developed within a day of the patch by reverse-engineering the diff — are now routine). Patches need to be centrally managed, deployed, and applied within timeframes matched to vulnerability severity.

Modern options for OS patching:

• Microsoft Endpoint Configuration Manager / WSUS — traditional centrally-managed patching with Wake-on-LAN for off-hours installs
• Windows Update for Business — cloud-managed deferral and ring policies, configured via Group Policy or Intune; can replace or supplement WSUS
• Intune update rings — the modern Microsoft pattern for cloud-managed endpoints

For severity-based patching SLAs, see the ACSC’s Patching Applications and Operating Systems companion publication.

17. Operating system version

Each major Windows release ships meaningful security architecture improvements: VBS, Credential Guard, Hypervisor-Protected Code Integrity, App Container sandboxes, etc. Older Windows versions (including older builds of Windows 10/11) lack these, exposing the endpoint to attacks that have been mitigated in newer releases. Run the current supported version, not a frozen-three-years-ago build.

Practically this means a feature-update plan: Windows 10/11 feature releases ship roughly annually; deploy them within Microsoft’s servicing window. Don’t let endpoints fall off support.

18. Restricting privileged accounts

Day-to-day usage of privileged accounts for web browsing and email is one of the cleanest attacker paths into a network: phish a privileged user’s primary account, get privileged shell. The mitigation is the well-known “separate accounts” pattern:

• Users who don’t need privileged access should not have privileged accounts at all
• Users who do need privileged access should have two accounts: standard for daily use (email, browsing), privileged for administrative tasks
• Privileged accounts should have internet and email access blocked — firewall rules, conditional access, or both

This is more an organisational and AD-design control than a single GPO setting. The ACSC’s Restricting Administrative Privileges publication is the deeper reference; for the AD-side patterns (Tier 0 / Tier 1 / Tier 2, Privileged Access Workstations, time-bound group membership) see the broader Active Directory pathway.

19. Secure Boot

The first link in the Trusted Boot chain. Secure Boot uses UEFI to verify that the bootloader is signed by a trusted certificate before allowing it to execute. Without Secure Boot, a malicious bootloader (a bootkit) can replace the legitimate one, run before Windows loads, and install rootkit functionality that’s invisible to anything that runs later. Bootkits are difficult to detect post-infection — the standard advice for an infected system is reimage from known-good media, which is costly to do at fleet scale.

Secure Boot lives in the firmware, not in Group Policy. Confirmation that it’s enabled is operational rather than policy-pushed:

• Confirm via Confirm-SecureBootUEFI in PowerShell — returns True if enabled, False if disabled
• Confirm via System Information (msinfo32) — the “Secure Boot State” line should read On
• Procurement should specify Secure Boot as a hardware requirement; older hardware that can’t do Secure Boot should be on a refresh cycle

Note that several other High Priorities (VBS, Credential Guard with UEFI lock, Measured Boot) require Secure Boot to be enabled to function correctly — so this isn’t standalone; it’s a hardware prerequisite for much of the rest of the list.

How to roll all of this out (without breaking everything)

Nineteen high-priority controls is a lot to flip on at once. The ACSC document is explicit that thorough testing precedes rollout; the practical pattern that works in real environments:

1. Group the controls by risk-of-disruption. Patching, OS architecture, OS version, restricting privileged accounts, application versions — low risk of breaking workflows; deploy first. UAC, ASR, Controlled Folder Access, Application Control, Exploit Protection — significant risk of breaking workflows; pilot, audit, then enforce.
2. Build a pilot ring. 5–10% of endpoints, IT staff and willing volunteers, exposed to the new GPOs first. Capture issues, fix, expand. Don’t flip enterprise-wide controls without ring deployment.
3. Use audit mode for the disruptive ones. ASR, Controlled Folder Access, Exploit Protection, and Application Control all support audit mode. Run them in audit mode for at least two weeks, review what would have been blocked, allowlist legitimate cases, then enforce.
4. Centralise logging. Hardening that doesn’t produce evidence is hardening you can’t audit. Forward Security event log + Defender event log to a SIEM; the value of these controls compounds when you can see when they fire and why.
5. Have a rollback plan. Every GPO change should have a documented “how to back this out” path — either disable the GPO link, narrow the security filter, or push a counter-policy. Don’t deploy controls you can’t reverse in 15 minutes if they break production.

What this article doesn’t cover

The ACSC publication continues into Medium and Low priority controls — another ~50 settings covering Account Lockout Policy, Anonymous Connections, Antivirus, Attachment Manager, Audit Event Management, AutoRun, BitLocker, BIOS / UEFI passwords, Bridging Networks, Centralised Audit Event Logging, Command Prompt restrictions, Direct Memory Access, Drive Encryption, Endpoint Device Control, File and Print Sharing, Group Policy Processing, Installing Applications, Microsoft Accounts, MSS settings, NetBIOS over TCP/IP, Network Authentication, NoLMHash policy, Operating System Functionality, Password and Logon Authentication Policy, Power Management, PowerShell logging and execution policy, Printers, Registry Editing Tools, Remote Assistance, Remote Desktop Services, Remote Procedure Call, Reporting System Information, Safe Mode, Secure Channel Communications, Security Policies, Server Message Block sessions, Session Locking, Software-Based Firewalls, Sound Recorder, Standard Operating Environment, System Backup and Restore, System Cryptography, UEFI Passwords, and the rest.

Those aren’t lower-impact in absolute terms — some of them (BitLocker, PowerShell logging, audit event management) are essential. The ACSC’s priority labelling reflects relative risk reduction per implementation effort, with the High Priorities being the highest leverage. Once the High Priorities are baselined, work down through Medium and Low.

Where this fits

This is a starting point for endpoint hardening. Companion topics on the InfoTech Ninja side:

• Configure Account Lockout Policy in Active Directory — one of the Medium Priority controls covered in detail
• Configure Advanced Audit Policies in Active Directory — the audit-event-management foundation
• Enable Active Directory auditing — companion AD-side audit configuration
• Block built-in apps with AppLocker — a worked AppLocker example for the Application Control control area
• Disable (or, more usefully, manage) Windows Firewall with PowerShell — covers the software-based firewall control area
• Active Directory Security Assessment with Purple Knight — for the AD-side companion to endpoint hardening
• The broader Group Policy pathway covers GPO mechanics, OU design, link-order processing, and security filtering — relevant to every setting in this article
• The Windows Server Administration pathway covers the server-side of these controls (most apply equally to Windows Server, just not on Domain Controllers)

For the authoritative ACSC source and the related publications referenced throughout (Implementing Application Control, Implementing Multi-Factor Authentication, Patching Applications and Operating Systems, Restricting Administrative Privileges, Hardening Microsoft 365, Office 2021, Office 2019 and Office 2016), see cyber.gov.au.