Digital Signatures: Fixing “The VBA project is not digitally signed.”

The message “The VBA project is not digitally signed” indicates that Excel has blocked a macro-enabled workbook (.xlsm or .xlsb) because your Trust Center security policy requires macros to carry a valid, trusted digital certificate. When a workbook lacks this cryptographic signature, or contains a signature that has expired, been revoked, or was invalidated by recent code changes, Excel treats the VBA project as untrusted and disables all automated routines.

Quick Fix:

If this is your own workbook on a personal computer, adjust macro security by going to File > Options > Trust Center > Trust Center Settings > Macro Settings and selecting Disable VBA macros with notification. For enterprise or shared workbooks where policy mandates signatures, apply a valid certificate inside the Visual Basic Editor via Tools > Digital Signature, or move the file into an approved Trusted Location.

Why Digital Signatures Matter in Excel

A digital signature uses public-key cryptography to verify two critical details:

1. Authenticity: It confirms the exact identity of the developer or organization that authored the macro project.
2. Integrity: It proves that the VBA code has not been altered, tampered with, or infected by malware since it was signed.

[ VBA Code Written ] ──► [ Applied Digital Certificate ] ──► [ Valid Signature Embedded ]
                                                                       │
[ Code Modified or Cert Expired ] ─────────────────────────────────────┴──► [ Signature Invalidated / Blocked ]

When Excel’s Trust Center is configured to “Disable VBA macros except digitally signed macros,” the application checks the workbook’s internal signature container (vbaProject.bin) against your Windows Certificate Store before executing any code. If no signature is present, or if the signature does not chain to a Trusted Root Certification Authority, execution is blocked immediately.

Diagnostic Flowchart: Distinguishing the Cause

Use this decision tree to determine whether you need to adjust Excel settings, sign your own code, or request an updated file from a publisher:

Who created the workbook?
 │
 ├── You (Internal / Personal Automation)
 │     ├── Can you change Excel Trust Center settings?
 │     │     ├── YES ──► Switch setting to "Disable VBA macros with notification" OR add folder to Trusted Locations.
 │     │     └── NO (Locked by Group Policy) ──► Generate a certificate (SelfCert.exe or Corporate PKI) and sign via Tools > Digital Signature.
 │     │
 └── Third-Party Vendor / External Source
       ├── Did the file arrive via email, download, or web drive?
       │     └── Check File Properties: Unblock "Mark of the Web".
       ├── Did the macro work previously but suddenly stopped?
       │     └── Check certificate expiration date or check if someone edited the VBA code after signing.
       └── Did the signature become corrupted during file transfer?
             └── Inspect the certificate details in Excel to verify root trust.

Practical Solutions

1. Adjust Macro Security Settings (Fastest for Local Development)

If your computer is not managed by strict enterprise Group Policies, you can allow unsigned macros to prompt you for permission on startup instead of blocking them silently.

1. Open Excel and click File > Options.
2. Select Trust Center on the left menu, then click the Trust Center Settings… button.
3. Click Macro Settings in the left sidebar.
4. Change the selection from Disable VBA macros except digitally signed macros to Disable VBA macros with notification.
5. Click OK, close Excel, and reopen your workbook.
6. A yellow message bar will now appear under the Ribbon. Click Enable Content to run your code.

If macros remain blocked or the yellow warning bar does not appear after modifying this setting, review “Macros have been disabled”: Troubleshooting the “Trusted Locations” security block.

2. Move the Workbook to a Trusted Location

If corporate policy prevents changing global macro settings, adding a dedicated local or network folder to your Trusted Locations allows Excel to bypass signature checks for any workbook stored inside that specific directory.

1. In Excel, go to File > Options > Trust Center > Trust Center Settings.
2. Select Trusted Locations on the left.
3. Click Add new location….
4. Browse to the folder where your automated spreadsheets are stored (e.g., C:\ExcelTools\).
5. Check Subfolders of this location are also trusted if necessary, and click OK.
6. Save or move your workbook into this folder. When opened from here, the VBA project executes without requiring a digital signature.

3. Sign the VBA Project Using SelfCert.exe (Local Machines Only)

If you must provide a digital signature but do not have an official enterprise Public Key Infrastructure (PKI) certificate, Microsoft Office includes a built-in tool called SelfCert.exe to create a self-signed certificate for personal use.

Note: A self-signed certificate is valid only on the specific computer where it was generated. If you send the file to a colleague, their computer will not recognize your local root and will flag the signature as untrusted.

1. Create the Certificate:
   • Close Excel.
   • Open File Explorer and navigate to your Microsoft Office installation folder (typically C:\Program Files\Microsoft Office\root\Office16\ or C:\Program Files (x86)\Microsoft Office\Office16\).
   • Locate and run SelfCert.exe.
   • In the Your certificate’s name box, type a descriptive name (e.g., MyDevCert), then click OK.
2. Apply the Certificate to the VBA Project:
   • Open your macro workbook and press Alt + F11 to enter the VBA Editor.
   • Click Tools > Digital Signature… from the top menu.
   • Click Choose…, select the certificate you created (MyDevCert), and click OK.
   • Save the workbook (Ctrl + S) and close the VBA Editor.
3. Trust the Self-Signed Certificate:
   • Reopen the workbook. When the security prompt appears, click Trust all documents from this publisher (or view the certificate and install it into your local Trusted Root Certification Authorities store).

4. Re-signing After Code Modifications (Invalidated Signatures)

A common point of confusion occurs when a workbook that was previously working suddenly triggers signature errors. In Excel, any change made to the VBA code instantly breaks an existing digital signature.

• If you edit a single line of code, add a comment, insert a new UserForm, or rename a module, the cryptographic hash no longer matches.
• Excel invalidates the signature upon the next save.
• The Fix: Whenever code changes are finalized, re-open Tools > Digital Signature, re-select your valid organizational certificate, and re-save the file.

If repeated saves or crashes cause persistent binary corruption within the signature container, see Troubleshooting “Digital Signature” corruption in Macro-Enabled workbooks.

Common Confusion: Missing Signatures vs. Unviewable Projects

Users often confuse signature-related execution blocks with project locking errors:

• “The VBA project is not digitally signed” (Security Block): The code exists and can usually be viewed in the VBA Editor (Alt + F11), but Excel refuses to execute procedures from worksheet buttons or shortcuts due to Trust Center policy.
• “Project is Unviewable” (Structural/Interface Lock): The VBA editor blocks expanding the module tree entirely. This is typically caused by legacy shared workbook mode or file protection rather than certificate issues; see “Project is Unviewable”: Solving errors when trying to open protected VBA projects.

If the macro does not trigger a security warning but fails with a notification that the procedure cannot be found, verify that the routine is declared publicly in a standard module as outlined in Fixing “Cannot run the macro… The macro may not be available in this workbook.”

Enterprise Deployment & Security Warning

When distributing automated workbooks across a multi-user corporate network, do not rely on local SelfCert.exe certificates or lower Trust Center settings across user machines.

For reliable organization-wide distribution:

• Obtain a code-signing certificate issued by your enterprise Certificate Authority (CA) or a trusted commercial vendor (such as DigiCert or Sectigo).
• Ensure the public certificate is pushed to all client machines’ Trusted Publishers store via Active Directory Group Policy (GPO).
• Ensure timestamping is enabled during the signing process so the signature remains valid even after the initial certificate reaches its calendar expiration date.