Essential Eight Series Part 6: Microsoft Office Macros: Why This Control Still Deserves Your Attention

In 2022, Microsoft did something the security community had been asking for for years. They changed the default behaviour in Office to block macros in files downloaded from the internet. No prompt to enable content, no yellow bar asking the user to make a decision. Just blocked.

It was a meaningful change, and it worked. Macro-based phishing campaigns that had been reliable commodity attack infrastructure for nearly a decade dropped off significantly. Threat actors shifted to container files, ISO images, HTML smuggling, and LNK-based delivery to get around it.

So why is macro restriction still a control in the Essential 8?

Because a default applied by a vendor is not the same as a control you own and can verify.

The gap between default and configured

The Microsoft change applies to supported versions of Microsoft 365 Apps, applied correctly, on managed devices, where the Mark of the Web is being set as expected.

That's a lot of conditions.

Organisations running older Office versions, or running mixed environments where some machines are on perpetual license Office and some are on Microsoft 365, may not have that default in place uniformly. Office 2016 and 2019 installations are still common, particularly in education and smaller businesses that haven't completed a full Microsoft 365 migration.

Even within Microsoft 365 environments, Group Policy and Intune configurations can override defaults in ways that aren't always intentional. Macro settings configured years ago for on-premises deployments don't automatically translate cleanly when an organisation moves to cloud management. The result is sometimes that macro restrictions are less restrictive than the administrator believes them to be.

When did you last verify what your macro policy actually does on a device that isn't your own machine?

Trusted locations and trusted publishers

This is where the residual risk lives for organisations that have otherwise done the right thing.

Trusted locations are filesystem paths where Office applies no macro restrictions regardless of where the file came from. The intent was to allow internally developed tools to function without friction. In practice, many organisations have trusted locations configured that are broader than they need to be, haven't been reviewed in years, and in some cases include paths that are writable by standard users or accessible from the network.

Trusted publishers work similarly. Macros signed by a certificate from a trusted publisher bypass the block. If that certificate was added loosely, or if the certificate has been compromised, the protection doesn't apply.

Neither of these are theoretical edge cases. They're common findings in environments that on paper have macro restrictions in place.

Legacy dependencies

The harder operational problem for a lot of organisations is that they have genuine business processes built on macro-enabled documents.

Finance teams running Excel models with embedded VBA. Operations teams using Word templates that pull from shared drives. Reporting tools built by a contractor years ago that nobody has replaced because they work and replacing them has never been prioritised.

This creates pressure to leave macro settings permissive, sometimes applied broadly rather than surgically, because the alternative feels like breaking something important.

The Essential 8 guidance here is reasonable. Block macros from internet-sourced files. For internal macro dependencies, require digital signatures from a trusted internal certificate rather than leaving macros open for all files. That means doing the work to inventory what actually needs macros, sign those files properly, and enforce the policy consistently.

Most organisations haven't done that inventory. Which means they don't actually know what they'd break if they tightened the policy, so they don't tighten it.

What this control is actually protecting against now

It's worth being honest that macro-based delivery is no longer the volume threat it was a few years ago. Attackers adapted when Microsoft changed the defaults, and most current phishing infrastructure has moved on to other delivery mechanisms.

The residual threat is more targeted. Adversaries who understand that their specific target is running an older Office version, or who have done enough reconnaissance to know a trusted location path, or who are specifically going after education or manufacturing environments where legacy macro dependencies are common.

That's a narrower threat than it used to be, but it's not zero, and it disproportionately affects the sectors that are already the hardest to defend.

Why is this still important?

The value of auditing this control isn't primarily about stopping the latest phishing campaign. It's about three things.

First, validating that your environment actually reflects the protection you think it has. The Microsoft default change is real, but defaults can be overridden, and mixed environments create gaps.

Second, cleaning up trusted locations and trusted publishers that have accumulated over time without clear justification. This is low-effort relative to the exposure it removes.

Third, building toward a signed publisher model for any legitimate internal macro dependencies, which means finally doing the inventory of what actually needs macros and treating those tools as something that needs to be maintained rather than ignored.

The Essential 8 includes this control not because macros are currently the most dangerous threat vector, but because the configuration surface around macro policy is genuinely complex and frequently misconfigured. The organisations that skip the audit because they think Microsoft handled it in 2022 are often the ones carrying the exposure.

Continuing the Series

This article forms Part 6 of our Essential Eight series examining how these controls operate in real environments.

Next, we will look at User Application Hardening.