Two of the eight strategies target the same reality: users open untrusted content all day, in software designed to be helpful about it. Restricting macros and hardening user applications both close the path from "opened a document" to "code running".
Technically these are among the easiest strategies — mostly configuration. Operationally they are among the most disruptive, because they collide with how parts of the business have quietly worked for years.
Restrict Microsoft Office macros
Level One
- Macros disabled for users without a demonstrated business requirement.
- Macros in files originating from the internet blocked.
- Macro antivirus scanning enabled.
- Users unable to change macro security settings.
The phrase "demonstrated business requirement" implies an artefact: a register of who has macros enabled and why. That register is one of the most frequently missing pieces of evidence in the whole framework — the setting is applied, the justification was never written down.
Level Two
Adds macros blocked from making Win32 API calls, and macro execution events centrally logged.
Level Three
The model changes shape. Macros may only run when they are:
- in a sandboxed environment, or
- in a Trusted Location, or
- digitally signed by a trusted publisher.
With supporting requirements: only privileged users responsible for validating macros may write to Trusted Locations; macros signed by an untrusted publisher cannot be enabled through the Message Bar or Backstage View; and the Trusted Publishers list is validated annually.
A Trusted Location that ordinary users can write to is not a Trusted Location — it is a bypass with a reassuring name. This is the specific misconfiguration assessors look for at Level Three.
Track both strategies across maturity levels
GRC Copilot ships all four Essential Eight levels as assessments, so macro and hardening requirements are tracked with their evidence rather than living in a spreadsheet.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
User application hardening
Level One — the browser
- Browsers not processing Java from the internet.
- Browsers not processing web advertisements from the internet.
- Internet Explorer 11 disabled or removed.
- Users unable to change browser security settings.
Blocking advertisements is a security control here, not a convenience — malvertising delivers exploit content through legitimate sites, which is precisely the commodity path Level One targets.
Level Two — behaviour, not just settings
- Browsers, Microsoft Office and PDF software hardened per ASD and vendor guidance.
- Office unable to create child processes, create executable content, inject code into other processes, or activate OLE packages.
- PDF software unable to create child processes.
- Users unable to change Office or PDF security settings.
- Blocked PowerShell script executions centrally logged.
These four Office restrictions are the highest-value controls in the strategy. Nearly every document-borne intrusion chain needs at least one of them — spawning a shell, dropping a payload, or injecting into a trusted process.
Level Three — remove the legacy
- .NET Framework 3.5 (including 2.0 and 3.0) disabled or removed.
- Windows PowerShell 2.0 disabled or removed.
- PowerShell configured to use Constrained Language Mode.
- PowerShell script block logs and command line process creation events centrally logged and protected.
PowerShell 2.0 is the clearest statement of intent in the model: it exists only for backwards compatibility and it bypasses the logging later versions provide. Configuring around it is not the answer.
The discovery problem
Applying these settings takes an afternoon. Finding what breaks takes months. Before enforcing:
- Inventory macro use by department. Finance and operations almost always have one that matters.
- Identify anything that legitimately spawns processes from Office — some reporting add-ins do.
- Check whether any line-of-business application depends on Internet Explorer or a legacy .NET runtime.
- Find the PowerShell automation that will meet Constrained Language Mode before it meets it in production.
Frequently asked questions
What is a demonstrated business requirement for macros?
A recorded justification tied to a named person or role and a business process, reviewed periodically. The point is that macro access is an exception granted deliberately, not the default that survived.
Can we sign our own macros instead of removing them?
At Level Three, signing by a trusted publisher is one of the three permitted paths. It requires a signing process, key protection and an annually validated Trusted Publishers list — worth it where macros are genuinely core to a business process.
Does an ad blocker satisfy the advertisement requirement?
The requirement is that browsers do not process web advertisements from the internet. Enterprise-managed blocking, whether by extension policy or network filtering, can satisfy it. A user-installed extension they can disable cannot.
Is disabling PowerShell entirely simpler?
Usually counterproductive — administration and endpoint tooling depend on it. The model asks for PowerShell 2.0 removal, Constrained Language Mode and logging, which keeps the capability while removing the unlogged legacy path.
Key takeaways
- The macro business-requirement register is evidence, and it is usually missing.
- A user-writable Trusted Location defeats the Level Three macro control entirely.
- The four Office behaviour restrictions break most document-borne intrusion chains.
- Settings take an afternoon; discovering what breaks takes months.