User application hardening

User application hardening is the Essential Eight mitigation strategy that disables or restricts risky features in the software users run every day: web browsers, Office productivity suites, PDF software and PowerShell. It shrinks the attack surface those applications expose, rather than protecting applications an organisation develops.

Book a Free Discovery Call (08) 6365 5360

Last checked against cyber.gov.au on 25 August 2026. Current model: Essential Eight Maturity Model (November 2023).

On this page 4 sections

What is required, and where
What this strategy does not cover
How the PowerShell controls change by level
Commonwealth implementation

User application hardening at a glance

What each maturity level requires

Requirements are cumulative: Level Three means everything in Levels One and Two as well. Each level links to that requirement on the matrix.

New requirements start here Carries the level below Score yourself with the self-assessment, or look a term up in the glossary.

Essential Eight at a glance

Eight strategies, three maturity levels

Requirements are cumulative: Level Three means everything in Levels One and Two as well. Overall maturity is the lowest strategy, so one weak row caps the whole board. Every cell links to that requirement on the matrix.

What each of the eight mitigation strategies requires at each maturity level.
Mitigation strategy	ML1 Maturity Level One	ML2 Maturity Level Two	ML3 Maturity Level Three
Patch applications	Patch applications, Maturity Level One: Patch online services — critical, or a working exploit exists (ISM-1876)	Patch applications, Maturity Level Two: Patch all other applications	Patch applications, Maturity Level Three: Patch office suites, browsers, email clients, PDF and security products — critical or exploited
Patch operating systems	Patch operating systems, Maturity Level One: Patch internet-facing OS — critical or exploited / otherwise	Patch operating systems, Maturity Level Two: Carries Maturity Level One No new requirements	Patch operating systems, Maturity Level Three: Patch drivers and firmware — critical or exploited / otherwise
Multi-factor authentication	Multi-factor authentication, Maturity Level One: MFA for users of your own and third-party online services handling your sensitive data (ISM-1504, ISM-1679)	Multi-factor authentication, Maturity Level Two: MFA for privileged and unprivileged users of systems	Multi-factor authentication, Maturity Level Three: MFA for users of data repositories
Restrict administrative privileges	Restrict administrative privileges, Maturity Level One: Privileged access requests validated when first requested (ISM-1507)	Restrict administrative privileges, Maturity Level Two: Administrative activities via jump servers; privileged environments not virtualised within unprivileged ones	Restrict administrative privileges, Maturity Level Three: Secure Admin Workstations and just-in-time administration
Application control	Application control, Maturity Level One: Implemented on workstations (ISM-0843)	Application control, Maturity Level Two: Implemented on internet-facing servers	Application control, Maturity Level Three: Implemented on non-internet-facing servers
Restrict Microsoft Office macros	Restrict Microsoft Office macros, Maturity Level One: Macros disabled for users without a demonstrated business requirement (ISM-1671)	Restrict Microsoft Office macros, Maturity Level Two: Macros blocked from making Win32 API calls	Restrict Microsoft Office macros, Maturity Level Three: Only macros from a sandboxed environment, a Trusted Location, or signed by a trusted publisher may execute
User application hardening This page	User application hardening, Maturity Level One: Browsers do not process Java or web advertisements from the internet; Internet Explorer 11 disabled or removed; browser security settings unchangeable by users	User application hardening, Maturity Level Two: Browsers, Office suites and PDF software hardened using ASD and vendor guidance, most restrictive taking precedence	User application hardening, Maturity Level Three: .NET Framework 3.5 (including 2.0 and 3.0) and Windows PowerShell 2.0 disabled or removed; PowerShell in Constrained Language Mode
Regular backups	Regular backups, Maturity Level One: Performed and retained in accordance with business criticality and business continuity requirements (ISM-1511)	Regular backups, Maturity Level Two: Privileged accounts (excluding backup administrators) cannot access other users' backups, or modify or delete backups	Regular backups, Maturity Level Three: Unprivileged and privileged accounts cannot access their own backups

New requirements start here Carries the level below Score yourself with the self-assessment, or look a term up in the glossary.

User application hardening restricts risky features in browsers, Office, PDF software and PowerShell. It applies to software users run, not software the organisation develops.

What is required, and where

Maturity Level One has four browser requirements:

web browsers do not process Java from the internet
web browsers do not process web advertisements from the internet
Internet Explorer 11 is disabled or removed
users cannot change browser security settings

Maturity Level Two has twelve application-specific requirements:

web browsers, Office productivity suites and PDF software hardened using ASD and vendor guidance
Office blocked from creating child processes, from creating executable content, from injecting code into other processes, and from activating Object Linking and Embedding (OLE) packages
PDF software blocked from creating child processes
Office and PDF security settings locked against user change
centralised logging of PowerShell module logging, script block logging and transcription
centralised logging of command line process creation events

Six shared logging and incident-response requirements also start at Level Two:

logs are protected
internet-facing server logs and resulting cyber security events are analysed
incidents are reported to the chief information security officer (CISO) and ASD
the incident response plan is enacted

Maturity Level Three adds three application-specific controls:

.NET Framework 3.5, including .NET 2.0 and 3.0, is disabled or removed
Windows PowerShell 2.0 is disabled or removed
PowerShell uses Constrained Language Mode

Log analysis also expands to non-internet-facing servers and workstations.

See the requirements matrix for every control at each maturity level.

What this strategy does not cover

User application hardening is about the software your users run: browsers, Office, PDF readers, PowerShell, .NET. It is about turning off features attackers use: the Java plugin, malvertising, Office spawning processes, legacy PowerShell.

It is not about hardening software you develop. Anti-debugging, code obfuscation, binary packing, jailbreak detection and runtime application self-protection belong to mobile application shielding and related software-security disciplines, not this Essential Eight strategy.

The distinction applies across the framework: the Essential Eight contains no software development controls. All 108 controls in the ISM's Guidelines for software development are tagged Essential 8: N/A.

How the PowerShell controls change by level

Three of the Level Two and Three requirements concern PowerShell, and they follow a clear logic.

Level Two requires logging: module logging, script block logging and transcription, centrally collected. PowerShell is an important administrative tool, but attackers can also use it after compromising a system. Level Two therefore adds visibility rather than removing the current version.

Level Three removes the version that cannot provide the same visibility. Windows PowerShell 2.0 predates script block logging, so invoking it can bypass the Level Two logging control. Constrained Language Mode then limits access to capabilities such as .NET and Component Object Model (COM) APIs.

Command line process creation logging sits alongside these for the same reason.

Commonwealth implementation

ASD's Commonwealth Cyber Security Posture in 2025 has user application hardening reaching 49% of Commonwealth entities at Maturity Level Two or above in 2024–25, recovering from 37% the year before.

Level One contains four browser controls. Level Two adds configuration across browsers, Office and PDF software, plus centralised logging and incident response. "Hardened using ASD and vendor guidance" describes a body of configuration rather than a single setting.

Sources

ASD — Essential Eight maturity model — Last updated 27 November 2023
ASD — Essential Eight maturity model FAQ — Last updated 28 October 2024
ASD — The Commonwealth Cyber Security Posture in 2025

All ASD source documents →

Common questions

Does blocking Java from the internet mean blocking JavaScript?

No. ASD answers this directly: "Does preventing web browsers from processing Java from the internet include JavaScript? No." The requirement concerns the Java runtime and browser plugins, not JavaScript, which is unrelated despite the name.

Is user application hardening about securing the applications we develop?

No. ASD's user application hardening covers web browsers, Office productivity suites, PDF software and PowerShell — software your users run. It does not cover anti-debugging, code obfuscation, binary packing, jailbreak detection or runtime application self-protection in software you build. Software development controls live elsewhere in the Information Security Manual.

Does this strategy apply to servers?

Yes. ASD's FAQ answers "Does this mitigation strategy apply to servers? Yes." It is not limited to workstations, despite the name.

Whose hardening guidance takes precedence, ASD's or the vendor's?

Whichever is more restrictive. From Maturity Level Two the requirement is that applications are "hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur".

Essential Eight requirements matrix
What each Essential Eight strategy requires at Maturity Levels One, Two and Three: timeframes, scanning intervals and controls introduced at higher levels. Sourced line by line from the November 2023 maturity model.
The Essential Eight will not secure the software you ship
Every one of the 108 software development controls in the Information Security Manual is tagged "Essential 8: N/A". The Essential Eight says nothing about how you build software. It still binds you in four specific ways, and something else governs the code itself.
Restrict Microsoft Office macros
ASD removed macro execution-event logging in November 2023 and added V3 signature requirements at Maturity Level Three.

Essential Eight

Need this assessed rather than explained?

We assess your maturity across all eight strategies, show you where you actually stand, and do the remediation. We are not an ASD-endorsed assessor — nobody is, because no such endorsement exists.

Essential Eight compliance Talk to us