Access Dev Team Progress Update: VBA Macro Code Signing

The Microsoft Access Engineering Team presented a feature update session to the Denver Area Access User Group (DAAUG) on November 17, 2022.  The team covered four topic areas:

• New Web Browser Control
• VBA Macro Code Signing in Access
• Improvements in exporting Access tables to Dataverse
• Q&A with the new Access Prinicipal Engineering Manager, Dale Rector

Check out the full video on YouTube: New and Upcoming in Access.

Highlights

• Signing your Access applications with a trusted signature will help avoid macro warnings and complies with the Trust Center policy to only run signed code
• Signed projects do not need to be run from a trusted location
• You will need a digital certificate from a trusted 3rd party (DigiCert, etc.)
• If you make changes after signing code, Access will alert you that the signature is invalid on exit
• Runtime use does not invalidate the signature
• General security guidance is for organizations to run with the "Only run signed macros" policy setting; this feature supports that guidance
• Currently available in Beta Channel and Current Channel (Preview)

Background

Microsoft has been focusing strongly on security lately.

With the recent change to their VBA policy–blocking all untrusted code rather than simply warning about it–it will be increasingly important to find ways to convey to your users that your Access applications are trustworthy.  One way to do that is to apply a digital signature to the application.

A digital signature uses complex math to verify the integrity of your code.  If someone changes your code, then the digital signature becomes invalid.

Digital signatures have been used for years to sign compiled executables, but they have not been useful for Access projects.  That's because the signature becomes invalid whenever the signed source changes.  Once compiled, the bits of a traditional executable do not change.  The same cannot be said for an Access app.  As anyone who's ever tried to mark a front-end Access file as read-only will tell you, Access modifies a front-end file as soon as it is opened, even when running in runtime mode.

Thus, it made no sense to use traditional methods to sign an Access application.  As soon as the end user opened it for the first time, the signature would be invalidated and the file could no longer be trusted.  

You have actually been able to sign the VBA portion of an Access application for many years.  The problem is that only the VBA itself got signed.  The queries, Access macro objects, forms, and reports never got protected by the signature.  Since they could not be verified as safe, the front-end file as a whole could not be trusted.  And, so, the digital signature had no practical use.

Here's a quick recap:

• External signing tools cover too much (the signature is too easily invalidated)
• Internal signing tool covers too little (queries, etc. are not included)

You can use external tools to sign an Access front-end, but the signature is invalidated as soon as a user runs the file (even in runtime mode).  You can use the existing VBA digital signature tool, but it does not cover important parts of a front-end file.  Therefore, Access will not trust the totality of the file.

This new feature seeks to provide a Goldilocks solution: a digitial signature that covers just enough code and objects for the front-end file to be considered trustworthy, but not so much that normal end-user usage invalidates the signature.

Overview

Sachin Arunkumar presented this session starting at the 3:35 mark.

Here are the main points from Sachin's opening slide:

• Trust center has a setting to only run signed code
• Security Baseline for Microsoft 365 Apps recommends setting this
• Without this feature, Trusted Locations can be used
• When an Access VBA project is signed, it incorporates elements of the database into the signature
• Modifying code or relevant design invalidates the signature
• 'Run-time' use does not invalidate the signature

After discussing these points, Sachin then provided a brief demonstration of the feature in action.  He opened the Northwind database and switched to the VBA editor.  He went to Tools > Digital Signature..., selected a code-signing certificate issued by DigiCert (one of several trusted third-party code certificate providers), and then applied the signature.  

As far as I can tell, the user interface is identical to the legacy code-signing experience.  It would seem the changes are all behind the scenes.  I mention this so that you don't get too excited and try to follow along with Sachin's sample on a normal copy of Access.  As of November 2022, you need to be a member of the Office Insiders Program to test the new functionality.

He showed how applying the digital signature changed the startup behavior of Access: the signed version did not attempt to block the VBA code from running.

Next, he showed what happens when you make changes to a signed Access application.  In fact, nothing happens at first.  From what I could tell, there was no indication at all that you were making changes to signed code that would invalidate the signature.  However, when Sachin tried to close the application, he did get a warning from Access prompting him to re-apply the digital signature to the changed code.

After the demo, there was a brief conversation with moderator George Young about how the signing process would work with the new Northwind 2.0 sample database.  That may be a moot point, though, as it's not yet clear whether Microsoft will ultimately choose to digitally sign Northwind 2.0 or not.

Sachin closed out his portion of the presentation with a call for testers.  Anyone interested in testing the new feature in a real-world environment can do so by joining the Office Insiders Program.

Remaining Hurdles

The feature is available in preview channels now.  The Access team is looking for help in testing the feature in real-world scenarios prior to a general availability (GA) release.  It appears you need to be a member of the Office Insiders Program to test the feature at this time.

Features I Would Like to See Added (At Some Point)

There are two things I would like to see added to improve this feature:

• A visual indication of a project's signature status (perhaps incorporated in the VBIDE's window title):
  • Valid signature
  • Invalidated signature (for previously signed projects that have been modified)
  • Unsigned (for projects that have never been signed)
• A command-line flag to sign code as part of a one-click deployment script

Reading the Tea Leaves

Microsoft won't commit to a release month for a new feature until they are 90% confident in the date.  Me? Not so much.

Seeing as this feature is already in public beta, I expect it to be released for General Availability between January 2023 and March 2023.

My Final Thoughts

For my own Access applications, I avoid the macro warnings by using a custom installer to create a trusted location in the HKLM registry hive.  For most professional Access developers, I think that will continue to be the simplest solution to avoid macro warnings.

However, a digital signature from a trusted third-party certificate authority is more secure than relying on designated local folders.  I imagine that over time, machine-wide trusted locations will fall out of favor at Microsoft.  In their place, I expect to see a strong push for Access developers and power users to use this new code signing feature.

Like the migration to 64-bit Access, most users will be able to put this off for a while.  Someday, though, you'll probably have to bite the bullet and deal with it.

External references