Access Dev Team Progress Update: VBA Macro Code Signing
The Access team offers a sneak peek at the new and improved VBA code signing experience. The feature is in public beta, and Microsoft is looking for testers.
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.
Hi George
Responding to part of your mail, I downloaded a new copy of Northwind as part of my testing and noticed that the file created from the template didn't need to be unblocked. No MOTW it seems.
In my various failed attempts to install a certificate in various test ACCDB files, I even tried running Access as an administrator. It made no difference
I'm not sure that asking forum members to add a code certificate to uploaded ACCDB file is viable. Whilst it would confirm that the user had checked the file before uploading, I'm not sure whether adding a certificate would guarantee there was no malicious code included
With regard to the Northwind 2.0 question, I think it's a bit more complicated than simply yes or no. All Access templates are, and I assume will continue to be, downloaded from MS sites as template files (.accdT) which can be used to instantiate a new copy. In my mind, the idea that the template itself could be signed is sort of beside the point. You'd have to suggest that anything downloaded from an MS site is untrustworthy without the code certificate. Maybe I'm reaching too far in that thinking.
The question I would like to see addressed is whether the resulting instance of an .accdB created from the template would also carry the code certificate if it were part of the template. And how would that work?
Also, participating in various Access forums, I see another area where the use of Code signing certificates opens new questions. One of the most important would be whether such sites should, or even could, ask that sample accdbs uploaded to the site carry a valid code certificate. And if not, whether we'd be obligated to warn other forum participants about it.
Apologies for the length of this answer
Like you, I also distribute my apps using an installer and set the install location as trusted during the setup process. I also use a code signing certificate purchased from Sectigo to verify the files when clients purchase and download them from my website
However, whilst this new feature is probably of no immediate benefit to me, I am still very interested in seeing it in action.
I do see the benefits, particularly where company policy does not allow users to create trusted locations, or save ACCDB files to existing trusted locations. In such cases, the only way to get code to run is to change the 'Macro settings' in the Trust Center to Enable All Macros (not recommended; potentially dangerous code can run)!
To me, allowing that seems far worse than setting trusted locations but that's another issue . . .
Anyway, a few months ago, a fellow Access developer reported that code run in that setup now runs FAR more slowly that if run from a trusted location. He provided an example database and I was able to confirm this.
The difference was significant (Typically 900ms instead of 30ms - 60x slower).
I forwarded the supplied database to the Access team who also verified this to be the case.
The explanation is that when code isn't trusted, it has to run through a malware detection process called Antimalware Scan Interface (AMSI). It seems to do this not once, but every time it runs!
Here is a blog post that describes the AMSI feature: https://www.microsoft.com/en-us/security/blog/2018/09/12/office-vba-amsi-parting-the-veil-on-malicious-macros/
And this page https://support.microsoft.com/en-us/office/malicious-macros-were-found-9e461c61-69d1-4ea9-a386-9ad0deaccfdd specifically mentions that the AMSI scan does not occur if a file is in a trusted location, or if the VBA macros are signed with a certificate.
So I'm very interested to see if the new feature works.
I've watched all 3 videos about this feature by the MS team and tried using it myself.
Over the past fortnight I've attempted to sign several databases on 3 machines running 365 on insiders channels - both Current (Preview) and Beta. I have tested with both my Sectigo certificate and ones created locally using SelfCert.exe.
In each case, the process has failed with a message that Access 'cannot save the certificate at this time'. In other words, the same message we have seen for years. I have verified that both types of certificate work with MDB files and with other Office apps such as Excel files.
I have asked for further information/explanation from MS but not yet received an answer. I've also reached out to other MVPs but so far none seems to have tested it.
Have others reading this article been able to get this new feature to work?