Your organization runs macros that process payroll, generate reports, or drive critical business workflows. After a Windows 11 rollout — or a file migration from .xls to .xlsx — those macros suddenly throw security warnings. Users click "Enable Content" every time they open a file, or worse, macro execution is blocked entirely by policy. The fix is digital code signing, and this guide walks through doing it correctly at enterprise scale.
Microsoft has tightened macro security significantly since Office 2016. By default, Office now blocks macros from files downloaded from the internet (enforced by the Mark of the Web flag), and many enterprise Group Policy configurations set macro security to "Disable all macros except digitally signed macros."
This means an unsigned macro — even one your company has run for ten years — will be silently blocked or will prompt the user for approval on every file open. Neither outcome is acceptable in a production environment.
Digitally signing your VBA projects solves this by establishing a chain of trust: the macro is signed with a certificate, the certificate is trusted by the machine, and Office runs the macro without prompting.
| Certificate Type | Best For | Trust Scope | Cost |
|---|---|---|---|
| Self-signed (SelfCert.exe) | Single-developer testing | Only the machine that created it | Free |
| Internal CA (AD CS) | Enterprise deployment via GPO | All domain-joined machines | Free (requires AD CS role) |
| Commercial code signing cert | Files distributed outside your org | Any machine that trusts the issuing CA | $200–500/year |
For most enterprises, the internal CA certificate is the right choice. It costs nothing extra if Active Directory Certificate Services is already deployed (it usually is), and certificates can be distributed to all machines automatically via Group Policy.
Microsoft ships a tool called SelfCert.exe with Office for creating self-signed certificates. It is only appropriate for development and testing — the certificate is trusted only on the machine that created it.
C:\Program Files\Microsoft Office\root\Office16\ (adjust for your Office version)SELFCERT.EXEDo not use self-signed certificates for enterprise deployment. When you open a signed file on another machine, Office will show a "The publisher could not be verified" warning and the macro will still be blocked. Use an internal CA certificate instead.
If your organization runs Active Directory Certificate Services (AD CS), you can request a code signing certificate from your internal CA. This is the enterprise-grade approach.
If your AD CS admin needs to create a code signing template: in the CA snap-in, duplicate the "Code Signing" template, set the Subject Name to "Supplied in the request," and publish it to the CA.
Once you have your certificate, sign the macro in the Office VBA editor:
The VBA project is now signed. The signature is stored inside the file.
Signing the file is only half the job. Every user's machine must trust the signing certificate. Do this via GPO:
cacert.cer) from certmgr.msc → Trusted Root Certification Authoritiescacert.cergpupdate /forceAfter the GPO applies, all domain-joined machines will trust your internal CA. Macros signed with your internal CA certificate will run without prompting.
LegacyLeaps converts .xls to .xlsx and .mdb to .accdb while preserving all VBA code — so you sign once, not rewrite from scratch.
Try the Free ScanIf you distribute macros to customers or partners outside your domain, a commercial code signing certificate from a trusted CA (DigiCert, Sectigo, GlobalSign) is the right choice. These certificates are already trusted by Windows on any machine worldwide.
The signing process is identical to the internal CA approach — the only difference is that the certificate is issued by a commercial CA rather than your internal AD CS. Pricing is typically $200–500/year for a standard code signing certificate.
Once certificates are in place, configure the correct macro security level via Group Policy using the Office ADMX templates:
| Value | Setting | Recommended? |
|---|---|---|
| 1 | Disable all macros without notification | Too restrictive for most orgs |
| 2 | Disable all macros with notification (default) | Users get prompts — OK for small orgs |
| 3 | Disable all macros except digitally signed macros | Yes — enterprise best practice |
| 4 | Enable all macros | Never — major security risk |
Even with "disable all except digitally signed" set, users may still see a one-time prompt to "Trust the publisher" the first time they open a signed file. To eliminate this entirely, push the signing certificate to the Trusted Publishers store via GPO:
.cer file.cer fileAfter GPO applies, macros signed with this certificate run with zero prompts on all covered machines.
This is a question we hear constantly: if you migrate a file from .xls to .xlsm, or from .mdb to .accdb, does the digital signature survive?
No — the signature is invalidated during format conversion. This is expected behavior. Any modification to a signed VBA project — including a format change — invalidates the signature, because the signature is computed over the binary content of the VBA project.
The good news: the VBA code itself is preserved intact during migration (LegacyLeaps verifies this as part of every conversion). You are re-signing working code, not debugging broken code.
The workflow after migration:
For large batches, this re-signing step can be automated with a PowerShell script using the Microsoft.Office.Interop.Excel COM interface — contact your LegacyLeaps done-for-you team if you need this as part of a bulk migration engagement.
This usually means the certificate has expired, been revoked, or the file was modified after signing. Check the certificate expiration date in certmgr.msc. If the file was modified by any process after signing (including an auto-save or compatibility check), you need to re-sign.
Check two things: (1) Is the certificate in the Trusted Publishers store on the user's machine? (2) Did the file come from the internet? Files with a Mark of the Web (Zone.Identifier alternate data stream) are blocked even if signed — strip the MOTW with Unblock-File in PowerShell or via file Properties → Unblock.
The certificate must be in your Personal store (not just the Trusted Publishers store) on the machine where you are signing. Request the certificate again or import it with the private key (.pfx format).
Run gpresult /r on a problem machine to see which GPOs are applied. Verify the machine is in the correct OU and that GPO inheritance is not blocked at a parent OU.
LegacyLeaps preserves your VBA code during format conversion. Scan your file library for free — see exactly what you're working with before committing to migration.
Download Free ScannerDigitally signing VBA macros for enterprise deployment is a three-part process: obtain the right certificate (internal CA for domain environments, commercial CA for external distribution), sign the VBA project in the Office editor, and push the certificate to the Trusted Publishers store via Group Policy. Done correctly, macros run silently on all covered machines with no user prompts.
If you are migrating legacy files as part of a Windows 10 EOL or Office upgrade project, plan for a re-signing pass after conversion. The code survives migration — the signature does not, by design. Build the re-signing step into your migration runbook and document which certificate was used so you can automate renewals before it expires.
Practical fixes for legacy Excel and Access problems. No spam.