{"id":5500,"date":"2025-08-11T22:31:59","date_gmt":"2025-08-11T21:31:59","guid":{"rendered":"https:\/\/mortenknudsen.net\/?p=5500"},"modified":"2026-07-24T17:10:19","modified_gmt":"2026-07-24T16:10:19","slug":"dont-let-macros-infect-your-business-enforce-signed-macro-policies","status":"publish","type":"post","link":"https:\/\/mortenknudsen.net\/?p=5500","title":{"rendered":"How to Enforce Macro Security by running only Excel macros signed with your own public-CA\u2013issued code-signing certificate \u2013 stored in Azure Keyvault (HSM)"},"content":{"rendered":"\n
It may be tempting to click \u201cEnable Macros\u201d when you open a spreadsheet, but macros are executable programs. Without a digital signature, you have no idea who wrote the code or what it might do. Malicious macros are a common attack vector for ransomware, data theft and other malware. Insisting on digitally signed macros<\/strong> from trusted publishers<\/strong> closes this door to attackers and protects your organization<\/strong>.<\/h6>\n\n\n\n

Macros are one of Excel\u2019s most powerful features: short Visual Basic for Applications (VBA) programs that automate repetitive tasks, manipulate data, or call other Office applications. However, the same automation that saves time also creates an attractive vehicle for malware. Microsoft warns that macros can introduce viruses or malicious software and therefore disables them by default. <\/p>\n\n\n\n

The safest configuration in modern Office apps is \u201cDisable all macros except digitally signed macros<\/strong>\u201d \u2013 unsigned macros do not run, and macros signed by an untrusted publisher prompt the user to trust the publisher or disable the macro. <\/p>\n\n\n

\n
\"\"
VBA macros should be disabled, except for digitally signed trusted macros<\/figcaption><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

To make your macros work seamlessly in this environment, you must sign them with a code\u2011signing certificate and distribute the certificate to users as a trusted publisher.<\/p>\n\n\n

\n
\"\"
List certificates are Trusted Publishers<\/figcaption><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

This guide explains why you need to disable unsigned macros, how to obtain a code\u2011signing certificate, where to store the private key (SafeNet USB token or Azure HSM), how to sign the macro in Excel, and how to use Microsoft Intune to distribute the publisher certificate. Necessary scripts are provided in my Github. The guide focuses on Excel but the same approach applies to other Office applications.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Update (July 2026) \u2014 troubleshooting 800403F4<\/code> and script improvements<\/h2>\n\n\n\n

Since publishing this guide I have had a few reports of the signing step failing, and
I hit it myself on a freshly built machine. The script has been updated to handle
every cause I ran into. If you are seeing this error:<\/p>\n\n\n\n

fail: AzureSignTool.SignCommand[0]\n      Signing failed with error 800403F4.<\/code><\/pre>\n\n\n\n
\u2026here is what is actually going on, and what changed.<\/p>\n\n\n\n
The real cause: vbe7.dll<\/code> cannot load<\/h3>\n\n\n\n
800403F4<\/code> is TRUST_E_SUBJECT_FORM_UNKNOWN<\/code> \u2014 Windows is telling you that no Subject
Interface Package claims the file. The obvious conclusion is that the SIPs are not
registered, but in my case they were registered perfectly: all six function entries,
both DLLs, correct 32-bit hive.<\/p>\n\n\n\n
The actual culprit is vbe7.dll<\/code>, which ships inside the Office SIP package. It is the
VBE7 runtime that msosipx.dll<\/code> uses to read the VBA project. If it cannot load, the
SIP silently declines every file, and the only symptom you ever see is 800403F4<\/code>.<\/p>\n\n\n\n
Two things in the SIP package readme must be in place, and neither was in my original
script:<\/p>\n\n\n\n
1. The Visual C++ x86 runtime is required.<\/strong> vbe7.dll<\/code> depends on it. Without it,
LoadLibrary<\/code> fails with error 126 (“the specified module could not be found”) on a
file that plainly exists \u2014 because it is a dependency<\/em> that is missing, not the DLL.<\/p>\n\n\n\n
https://download.microsoft.com\/download\/C\/6\/D\/C6D0FD4E-9E53-4897-9B91-836EBA2AACD3\/vcredist_x86.exe<\/code><\/pre>\n\n\n\n
2. vbe7.dll<\/code> must be discoverable via the registry.<\/strong> The readme says it can sit
alongside the SIP DLLs \u2014 but that resolves against the calling process’s<\/em> search path,
and signtool\/AzureSignTool live somewhere else entirely. Register the full path:<\/p>\n\n\n\n
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VBA\n    REG_SZ  Vbe71DllPath = C:\\Program Files\\Microsoft Office SIPs\\vbe7.dll<\/code><\/pre>\n\n\n\n
Write it to SOFTWARE\\WOW6432Node\\Microsoft\\VBA<\/code> as well, since the SIP is 32-bit and
reads the redirected view.<\/p>\n\n\n\n
The updated script does both automatically and verifies vbe7.dll<\/code> actually loads in a
32-bit process before it attempts to sign \u2014 so you get a clear message instead of a
hex code.<\/p>\n\n\n\n
winget will not install the x86 .NET SDK<\/h3>\n\n\n\n
This one caught a reader too. The original script called:<\/p>\n\n\n\n
winget install --id Microsoft.DotNet.SDK.8 --architecture x86 ...<\/code><\/pre>\n\n\n\n
winget matches on package ID only. If the x64 SDK is already installed it reports
“Found an existing package already installed\u2026 No available upgrade found”<\/em> and never
lays down the x86 payload. C:\\Program Files (x86)\\dotnet\\dotnet.exe<\/code> is silently
never created, and every subsequent step fails. The updated script uses the official
dotnet-install.ps1<\/code> with an explicit -Architecture x86 -InstallDir<\/code>, which works
reliably.<\/p>\n\n\n\n
Now on .NET 10 and AzureSignTool 7.0.1<\/h3>\n\n\n\n
.NET 8 goes out of support on 10 November 2026<\/strong>, so the script now defaults to the
.NET 10 LTS channel with AzureSignTool 7.0.1. These two must be kept in step \u2014 7.x
targets .NET 10, while 6.0.0 and 5.0.0 target .NET 8 \u2014 so both are set at the top of
the script with a note explaining the pairing.<\/p>\n\n\n\n
For the record: AzureSignTool 7.0.1 signs VBA projects without any problem. If you are
hitting 800403F4<\/code>, do not waste time downgrading the tool. It is almost certainly
vbe7.dll<\/code>.<\/p>\n\n\n\n
Other fixes in the updated script<\/h3>\n\n\n\n