Macro security: The risks of allowing or blocking macros and a game-changing new approach

Sam Brazier-Hollins, Head of Cyber, oobe

In recent years, the landscape of macro security has evolved. After decades of macros being enabled by default, Microsoft have turned them off, then back on (temporarily), then back off again, and at least blocking those originating from the internet seems to have stuck. But where does this leave us?

Changing the default settings is a start, but it really doesn’t help enterprises, that like it or not, require macros to perform day-to-day and mission-critical tasks, and will likely continue to for years to come.

The macro dilemma - A historical perspective

Like so many technologies of yester-year, macros and Visual Basic for Applications (VBA) – the language macros are written in – were created in the days before ‘secure by design’.

They are great for automating repetitive tasks in Office – from formatting to data ingestion – but with their power, comes risk. They can also launch other Win32 applications, invoke command line and PowerShell commands, and pull and push content to and from the internet – all the things that attackers want to do!

At almost every cyber-focused conference I’ve attended over the last few years there has been at least one presentation about an exciting/scary incident that started off with a simple macro execution.

Risks of allowing and blocking macros

The simple solution to the risk posed by macros would appear to be to block them (as Microsoft recommends). But in reality, this is neither simple nor effective. For businesses than run on macros, attempting to turn them off is akin to getting rid of email. At best you severely impact productivity, but likely users will be forced to circumvent controls by doing things like sending macro-enabled files to their personal PC where they can run them without intervention – and in doing so cause potential data spills.
But at the other end of the spectrum, allowing all macros to execute spells just as much disaster.

If you are lucky, and your security tools, processes and people are very good, you will just waste time cleaning up alerts and removing quarantined macros. But everyone’s luck runs out at some point, and you are left responding to a ransomware outbreak or a public data spill – two things which are even less fun than they sound.

The macro security gap

So where does that leave you? You can’t turn them off, but you can’t just let them run either.

There are two options that are generally recommended, either leveraging Trusted Locations or digitally signing trusted macros.
While technically possible, I am yet to see an effective implementation of Trusted Locations at scale, so we’ll discount that as an option (but I’d love to hear from you if you have seen it work).

That leaves us with digitally signing trusted macros – and that last part is important.

If you just sign every existing macros in your environment, and macros you get via email, and every macro you create (most likely using code found on the internet), you just end up back at the allow all option but with extra steps.


To be effective from a security risk point of view, you need to first inspect the macro and determine if it is safe, and from an operations and user-experience point of view, you need this to be user-driven and automated, including the signing process itself. Also, as with ever other security related process, it needs to attributable and auditable too.