Essential Eight macro settings decide whether a document someone was expecting to receive can execute code on their machine. With user application hardening, they are two of the eight mitigation strategies published by the Australian Signals Directorate, and both target the exploitable surface inside the software your staff open every working day.
Both are also routinely written off as legacy concerns — macros are a relic, browsers patch themselves now, the real work is elsewhere. Assessment results say otherwise. These are among the strategies most commonly rated below the level a team assumed it held, and the reason is rarely that nobody configured anything. It is that the configuration was applied once, to part of the fleet, and never measured again.
What the Macro Settings Strategy Asks For
The macro settings strategy asks you to decide, deliberately, who needs to run macros at all — and then to constrain everything outside that set. ASD names Microsoft Office specifically, because that is where the delivery path has been most productive for attackers, and its guidance sits alongside the rest of the eight at cyber.gov.au.
Three ideas carry it. Macros should not be available to users with no business reason to run them. Macros arriving from outside the organisation should be treated differently from macros the organisation wrote itself. And macro activity should be visible, so use can be reviewed rather than assumed.
What it does not ask for is a ban. Teams that read it as one either never implement it, or implement it and get rolled back within a fortnight.
Why Macros Are Still a Strategy in Their Own Right
Macros remain a strategy in their own right because they execute code inside a document the user was expecting to receive. That single property defeats most of the defences built around user judgement.
Awareness training teaches people to be suspicious of the unexpected. A macro-bearing document frequently arrives as the expected thing: the invoice from the supplier you deal with monthly, the rate sheet from the broker, the workbook finance has been sent every month for four years. The user is not being tricked into opening something strange. They are opening what they were waiting for, in the application they always use.
The second property is that the execution is legitimate at the application layer. A macro is a feature, not an exploit. Nothing needs to be unpatched for it to run, which is why patching does not close this path, and why application control and macro settings are separate strategies: an allowlist that permits the office suite has, by definition, permitted the thing the macro runs inside.
So the control sits in the application's own configuration, applied centrally, before the document arrives. There is no later point where the user's caution helps.
How Essential Eight Macro Settings Tighten as Maturity Rises
Essential Eight macro settings tighten in a consistent direction as maturity rises, and the direction is more useful to understand than which setting belongs to which level — read the current maturity model for that, because the specifics have been revised more than once. Three strands run through it.
Availability narrows. At lower maturity the question is whether you configure Microsoft Office macro settings to disable macros for users with no business requirement. As maturity rises, that population is defined more tightly and exceptions are held to a higher standard of justification.
Origin starts to matter. The expectation to block macros from the internet becomes explicit rather than a nice-to-have. A macro that originated outside the organisation is untrusted regardless of who forwarded it, which closes the gap an internally-relayed attachment would otherwise open.
Reliance shifts from choice to validation. The lowest-maturity posture leans on the user deciding whether to enable content. Higher maturity leans on the organisation having validated in advance what may run — administrator-controlled trusted locations, signing, or equivalent — so the user is no longer making the security decision. Logging and review come with this, because validation you cannot observe is an assumption.
That is the arc of macro security maturity: from a dialog box the user clicks through, to a defined population running defined content, measured. Decide where your own fleet sits against ASD's published model and the Essential Eight assessment process rather than from memory.
Not sure what your fleet's macro and hardening settings actually are?
Share your work email and we'll help you measure the configuration your endpoints are really running, against the policy you think you set, and mark where the two diverge.
Running the Business-Need Exception Process
The business-need exception process is where this strategy either works or quietly collapses, because macros are load-bearing in real organisations. Finance teams run reconciliation workbooks maintained for a decade. Operations teams run spreadsheets pulling from a system nobody will fund replacing this year. Treasury and pricing functions often have tooling that exists only as macros.
Telling those teams macros are gone produces one of two outcomes: the project stops, or users route around it. What works is treating the exception register as a product rather than an inbox.
- Make someone own it, with a turnaround measured in days not quarters. An exception process with no service level is one users learn to bypass.
- Require a justification that names the work, not the tool. "Finance needs macros" is not a justification. "The monthly reconciliation for entity X depends on this workbook until the ledger migration lands" is, because it tells you when the exception should end.
- Give every exception an expiry. An exception without an end date is not an exception; it is the policy.
- Review on a cycle and actually remove things. A register that only grows is evidence of drift; revocations show the control is live.
- Pair it with a narrower setting. A grant at user or group level, with content restricted to validated sources, is a far smaller concession than returning a department to defaults.
Some exceptions will be renewed for years, because the system behind them genuinely will not be replaced soon. That is fine, provided each renewal is a dated decision someone made with the risk in front of them rather than an absence of review.
What User Application Hardening Covers
User application hardening covers the exploitable surface of the software users spend their day inside: web browsers, the office suite, and PDF readers. The aim is to disable features that are rarely used and frequently abused, and to stop high-risk content executing at all.
The browser is the largest share: disabling the content types and plug-in technologies that exist mainly as an execution path, restricting what web content can do on the endpoint, and preventing users from re-enabling what the organisation turned off. The office suite and PDF readers get the same treatment — features that are legitimate, occasionally useful, and disproportionately represented in delivery chains.
This is easier than application control, because most settings are centrally manageable and the business impact of each is small and discoverable in a pilot. It is harder than it looks, because there is no single switch — it is a per-platform baseline, and baselines drift. So treat it as one: define per platform, deploy centrally, detect deviation continuously. A hardening standard that exists only as a document written during the project is not a control.
Removing Software Instead of Hardening It
Removing software is often the better answer, and this strategy explicitly includes it. Software that is no longer needed cannot be hardened wrong, cannot drift, and cannot go unpatched.
The candidates are predictable: the second PDF reader nobody chose, the browser installed for a legacy application since retired, the plug-in for a supplier portal that works fine without it, the runtime left behind by a tool the team dropped. Each is a maintained attack surface with no business value. The same sweep that finds unsupported versions for your patching timeframes finds these, so run it once and feed both.
Why Both Strategies Rate Lower Than Teams Expect
Both strategies rate lower than teams expect for three reasons, and none is a failure to understand the requirement.
Settings reach the managed fleet and stop there. Centrally managed policy lands on the standard build. It does not land on contractor laptops, machines inherited through an acquisition, or the executive's personal machine onboarded as an exception. Assessment scope is the fleet, not the managed subset, and the remainder sits at defaults.
Policy was set once and then drifted. Updates introduce settings that did not exist when the baseline was written, local administrators change things, and a troubleshooting step disables something that is never re-enabled. Without drift detection, the gap between the document and the live configuration only widens.
Exceptions became permanent. A temporary grant issued during rollout becomes the steady state within a quarter if nobody revisits it. Enough of those and the effective configuration is the pre-project one, with better documentation.
All three are findable deliberately and invisible if the assessment is a questionnaire answered by the team that owns the control — the pattern that overstates ratings across the Essential Eight maturity model generally.
Evidence That Supports the Rating
The evidence that supports a rating here is measured configuration state, not the policy that was supposed to produce it. What holds up under scrutiny:
- Configuration as it exists on endpoints, collected from the devices and reported across the fleet — not a screenshot of the console's intended policy.
- Coverage against the asset inventory, so any unmanaged remainder is a stated number rather than implied. Ninety per cent coverage is a real achievement and is not the same as coverage.
- The exception register, with justification, owner, date granted and expiry — plus a history showing exceptions have actually been revoked.
- Drift detection output, demonstrating the baseline is monitored rather than deployed once.
- Macro execution logging, where the level you are claiming expects visibility of what ran.
The question an assessor asks is not "what is your policy?" It is "show me what the machines are set to, and tell me which ones you cannot see." Preparing the second answer honestly is most of the work.
Macro and Hardening Questions Teams Ask
These are the macro and hardening questions teams ask most often once they start measuring configuration instead of policy.
Yes, which is why they remain a named strategy rather than being folded into the others. The risk is structural, not historical: a macro executes inside a document the recipient was expecting, in an application they trust, using a legitimate product feature. Nothing has to be unpatched for it to work, so patching does not close the path. Default handling in modern Office versions has improved, but a default is not a configuration you set, measured and can evidence across your fleet.
No. The strategy is about knowing who has a genuine business requirement and constraining everything outside that set. Finance, operations and pricing functions frequently depend on macro tooling that will not be replaced quickly, and a blanket ban there either stalls the project or gets circumvented. What it requires is that exceptions are defined, justified against named work, owned, dated and reviewed.
It should not, if internal content is handled properly. The intent is to treat content that originated outside the organisation as untrusted regardless of how it reached the user, while giving organisation-authored macros a validated route — administrator-controlled trusted locations, signing, or equivalent. The usual friction comes from internal workbooks shared through channels that mark them as external, which is a distribution problem to fix rather than a reason to lift the control.
No. Endpoint detection looks for behaviour it believes is malicious, which leaves the risky feature enabled and bets on recognising abuse of it. Hardening removes the feature, so there is nothing to detect. An EDR deployment does not move this strategy's rating, because the assessment looks at browser, office and PDF reader configuration across the fleet.
At least annually per platform, with continuous drift detection in between. The annual pass catches settings that updates introduced or renamed; drift detection catches the local changes in between.
Measure your macro and hardening configuration, not your policy
Book a demo and we'll show how Konfirmity tracks configuration state, fleet coverage and exception expiry across the Essential Eight so the rating you claim is the one the evidence supports.
Book a demo
Treat the Two as One Piece of Work
Macro settings and user application hardening are the same project with two names. Both are centrally managed configuration applied to the software users open all day, both are measured across the fleet rather than in the console, and both decay the same way — through unmanaged devices, drift, and exceptions that outlive their justification.
Do them together, and do them before application control. They are cheaper, they close the paths most incidents start with, and the inventory and exception discipline they force on you is what application control will need later. Most teams sequence patching and multi-factor authentication first, then these two, then the harder strategies.
The first step is small and uncomfortable: pull the real configuration from endpoints across every part of your fleet, including the parts you do not manage, and compare it with the policy you believe is in force. That gap is your actual starting position, and knowing it beats claiming a level the maturity model would not support.
