This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
What is "Access 2013 or later database" file format this article is referring to?
Is it they just have misspelled Access 2003 with its old mdb file format? It looks like it is still not possible to sign code in accdb database created with Office 365 (Access 16.0.10730.20348) and I still have to use the old mdb file format if I want code signing to work; otherwise "Disable all macros except digitally signed macros" policy prevents the app from functioning normally. I've seen a lot of folks asking similar questions with no good answers. As others pointed out, the suggested "Package and Sign" feature is utterly useless as it is creating a signed package with still unsigned accdb inside. Once unpacked from the archive, the database is still not trusted.
A family of Microsoft relational database management systems designed for ease of use.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Answer accepted by question author
After some discussion on a different platform, the information shown there is correct if you're using the older .mdb format. You just can't sign a .accdb or .accde file.
Some of those apps are over 15 years old. I don't do any new development in Access, but still have to support that pesky legacy code until it is replaced.
I agree with everything you said, which is why I would never deploy a commercial application in Access.
Yes, I can make a trusted location, but it is not the real solution to the problem. Trusted locations can be disabled by policies, and if not, nothing can prevent users from placing malicious apps in trusted locations. I'll keep signed mdbs then.
I'm running 2019, and can perform the steps indicated here (and I've got a current Comodo/Sectigo certificate), but of course when I go to save it I get the message about not being able to sign an .accdb file. So the steps are correct, but of course they don't really work. Not sure why they're still there.
In 2007 and above the only way to avoid that message is to place the database in a Trusted Location. You can create a Trusted Location with code, but if you're deploying this application you'd be much better off doing this in the installation process, otherwise, you'll always get that initial "This database is not trusted blah blah" message.