βοΈπͺπ§βπΌCP - Microsoft 365 Apps - Macro Signing
The yellow bar has been talking users into running attacker code for twenty years. This policy takes away the button and only lets through macros somebody actually signed.
What this policy is about πβ
An invoice arrives. It looks like an invoice. It opens in Excel, the content is blurred behind a helpful notice explaining that the document was created in a newer version and you need to click Enable Content to see it properly, and the user, who processes forty invoices a day and has never once been told otherwise, clicks it.
That is the entire attack. No exploit, no vulnerability, no clever technical work. Just a macro, a plausible document and a button that Office has been putting in front of people since the nineties.
This policy sets the Trust Center so that only macros carrying a valid digital signature from a publisher the device already trusts will run. Everything else is blocked outright, with no prompt and therefore nothing to click.
"Disable all except digitally signed macros" does not show the yellow bar with a tempting button. Unsigned macros simply do not run. Removing the decision is the point: no amount of training beats a well-made lure, and users should not be the last line of defence against a document.
Why this matters π΅οΈβ
Macro-borne malware refuses to die because it does not need anything to be broken. It needs a file, a story and a click, and it lands in a mailbox that is expecting attachments. For an accounts department, a document from an unknown sender is not suspicious, it is Tuesday.
Microsoft did move the needle here: since 2022, macros in files downloaded from the internet are blocked by default in Microsoft 365 Apps, which killed off the laziest version of the attack. It did not solve the problem. Files arriving over a file share, a partner's SharePoint, a USB stick or a syncing folder never pick up the Mark of the Web that triggers that block, and the default remains a prompt rather than a wall. Requiring signatures closes the door the default leaves ajar.
The upgrade path is also unusually kind. Legitimate business macros keep working the moment somebody signs them, and signing is a one-off job per macro, not an ongoing cost. Most customers find the real number of business-critical macros is between zero and three, and everyone had assumed it was dozens.
π οΈ Configurationβ
Where: Intune admin center β Devices β Configuration β Create β Windows β Settings catalog β Administrative Templates β Microsoft Word 2016 / Excel 2016 / PowerPoint 2016 β Application Settings β Security β Trust Center.
Configure the same pair for each application in a single profile:
| Setting | Value |
|---|---|
| VBA Macro Notification Settings (Word) | Enabled β Disable all except digitally signed macros |
| VBA Macro Notification Settings (Excel) | Enabled β Disable all except digitally signed macros |
| VBA Macro Notification Settings (PowerPoint) | Enabled β Disable all except digitally signed macros |
| Block macros from running in Office files from the Internet (Word, Excel, PowerPoint) | Enabled |
| Prevent Excel from running XLM macros | Enabled |
| Require that application add-ins are signed by Trusted Publisher (Word, Excel, PowerPoint) | Enabled |
| Assignment, include | All users |
| Assignment, exclude | π‘οΈπ§βπΌππβοΈGroup - Unsigned Macros Allowed users |
Do not skip the XLM row. Excel 4.0 macros predate VBA, live in a hidden sheet, and are controlled by a completely separate setting. Lock VBA down without this and you have moved the attack rather than stopped it, which is a genuinely popular technique precisely because so many baselines forget it exists.
Keep the internet block even though it is the default. Defaults are a starting position, not a guarantee; they get changed by other policies, by inherited configuration, and by whatever a previous administrator was doing. State it explicitly and it survives.
Signing is the other half of this policy. A signed macro only runs if the signing certificate is in the device's Trusted Publishers store, so a customer with real business macros needs a code-signing certificate deployed there before this profile lands. Deploy the public certificate through a configuration profile, sign the macros once, and the entire estate can then run them while everything unsigned stays blocked.
Caveats β οΈβ
This tattoos, hence the inverse. The settings write to HKCU\Software\Policies\Microsoft\Office\16.0\<app>\security. Removing a user from this profile does not restore the previous Trust Center behaviour; the values stay put. Anyone who genuinely needs unsigned macros back must also receive βοΈπͺπ§βπΌπCP - Microsoft 365 Apps - Macro Signing - Exemption.
Find the macros before you deploy, not after. The rollout is not technically risky; it is politically risky, because the one workbook that runs month-end close is invariably discovered on the last working day of the month. Ask the customer, then ask the finance team directly, because they will not consider their spreadsheet to be "a macro."
Trusted Locations are a loophole with a legitimate use. Files in a Trusted Location bypass macro restrictions entirely. That makes a locked-down, read-only network share a workable holding pen for a business-critical macro while it waits to be signed. It also makes an inherited Trusted Location pointing at somewhere users can write a straightforward bypass of this whole policy. Audit for them on takeover.
Old formats deserve a separate look. Legacy .doc and .xls files carry macros in ways the modern formats do not, and customers who still exchange them tend to do so with exactly the partners you would least like to inherit a document from. Blocking legacy formats outright is a bigger conversation than this page, but it belongs on the list.
Assignment is user-scoped. These are HKCU settings, so this profile targets users, not devices. That is deliberate: a finance user who needs an exemption should carry it across every machine they sign in to.
ASR is the complementary control. The Attack Surface Reduction rule that blocks Win32 API calls from Office macros stops a signed-but-compromised macro from doing the interesting part. Signatures answer who wrote this; ASR answers what is it allowed to do. Deploy both.
π₯ Assignment scopeβ
Baseline for all users. Shared and kiosk devices inherit it through whoever signs in, which is the correct behaviour for a user-scoped Office setting.
Exception group membership is per user, requires a named workbook or application, an approver and a review date, and should come with a plan to sign the macro rather than an open-ended pass.
Worth verifying at tenant takeover: existing Trusted Locations, existing Trusted Publishers certificates, and whether anyone previously set macro notification to Enable all macros, which some vendor installers still recommend in documentation written a decade ago.
π Relatedβ
- βοΈπͺπ§βπΌπCP - Microsoft 365 Apps - Macro Signing - Exemption: the paired inverse for documented exceptions.
- π‘οΈπ§βπΌππβοΈGroup - Unsigned Macros Allowed users: the exception group both policies hinge on.
- π§±πͺπ»ES - Attack Surface Reduction Rules: stops macros doing damage even when they are allowed to run.
Take the button away and the twenty-year-old attack stops working. Sign the three macros that matter and nobody even notices. π