Protect an Access database with password encryption, a split design, Windows folder permissions, ACCDE files and trusted locations, and know where Access security stops.
The strongest protection built into Access is to encrypt the database with a password: open the file in exclusive mode, then choose File > Info > Encrypt with Password. After that, the file cannot be read without the password, in Access or in any other program.
That is one password for the whole file. Access has no per-user accounts or table-level permissions in the current .accdb format, so real protection comes from combining encryption with Windows folder permissions, a split design, and backups. This page covers each layer and is honest about where Access stops.
What Access can and cannot do
Need
Possible in Access?
How
Stop someone who obtains the file from reading it
Yes
Encrypt with a database password
Control who can open the file
Yes, outside Access
Windows (NTFS) and share permissions
Stop users changing forms, reports and code
Mostly
Distribute a compiled .accde front end
Block untrusted macros and VBA from running
Yes
Trust Center and trusted locations
Give different users different rights to tables
No
Move the data to SQL Server or another server database
Record who changed what
Not built in
Server database, or your own audit code
User-level security, the workgroup (.mdw) system from older versions, only works with the legacy .mdb format. It is not available for .accdb files and was never strong.
Encrypt the database with a password
Encryption needs exclusive access, so everyone else must be out of the file.
Start Access and choose File > Open > Browse.
Select the database file. Click the arrow beside the Open button and choose Open Exclusive.
Choose File > Info > Encrypt with Password.
Type the password in the Password box, type it again in , and click .
Build Access forms with the Form tool, Form Wizard and Blank Form, switch between Layout and Design view, add controls, restrict data entry and fix #Name? and #Error.
Access may show a message that encrypting with a block cipher is incompatible with row level locking and that row level locking will be ignored. That is expected; click OK. The database uses page-level locking from then on.
Three things to know before you do this:
There is no recovery. Microsoft's documentation is explicit that a forgotten password cannot be retrieved and the database cannot be opened without it. Store the password in a password manager.
Everyone shares the same password. You cannot tell who opened the file, and removing one person's access means changing the password for all.
Only .accdb files get strong encryption. Passwords on old .mdb files are easily removed with widely available tools. Convert with File > Save As > Access Database first.
Change or remove the password
Open the database with Open Exclusive.
Choose File > Info > Decrypt Database.
Enter the current password and click OK.
To change the password, decrypt and then encrypt again with the new one.
Split the database
A split database is two files: a back end holding only the tables, on a shared folder, and a front end holding queries, forms, reports and code, with linked tables pointing at the back end. Each user gets their own copy of the front end.
Splitting is the standard design for any multi-user Access application. It reduces corruption, lets you update the application without touching the data, and lets you protect the two parts differently.
Make a backup copy of the database.
On the Database Tools tab, in the Move Data group, click Access Database.
Click Split Database, choose the shared folder for the back-end file, and click Split.
To encrypt a split database, Microsoft's guidance is to do it in this order:
Encrypt the back end with a password.
In the front end, delete the linked tables and link them again (External Data > New Data Source > From Database > Access, then Link to the data source). Access asks for the back-end password.
Encrypt the front end.
The back-end password is stored in the front end's link information so users are not prompted for each table. Anyone who can open the front end can therefore reach the data, and can read that password if the front end itself is not encrypted. This is why step 3 matters.
Restrict access with Windows permissions
Folder permissions are the only way to decide which people can open an Access back end. Put the back end in a folder that only the right group can reach:
The first command grants Modify to the user group and Full control to administrators; the second removes the permissions inherited from the parent folder, leaving only those two entries. Run them in that order so you do not lock yourself out. Check the result with icacls "D:\Data\Sales".
Users need Modify, not just Read and Write, on the folder. Access creates a lock file (.laccdb) beside the database when the first user opens it and deletes it when the last one leaves. Without permission to create and delete files there, users get read-only or "file already in use" errors.
The consequence is a real limit: anyone who can use the database can also copy the back-end file. Encryption is what keeps that copy useless to someone without the password.
Distribute a compiled front end
To stop users altering forms, reports and VBA, give them an .accde file instead of the .accdb:
Open the front end.
Choose File > Save As > Save Database As > Make ACCDE, then Save As.
In an .accde, VBA source code is removed and forms, reports and modules cannot be opened in Design view. Tables and queries remain fully accessible, so this protects your application, not your data. Keep the original .accdb; you cannot turn an .accde back into an editable file, and you need the source to make changes.
Trusted locations and the Trust Center
When you open a database from a location Access does not trust, it disables VBA, macros with unsafe actions, and action queries, and shows a Security Warning bar. This protects your computer from malicious code inside a database someone sends you.
Rather than clicking Enable Content on every file, add the folder that holds your front end as a trusted location:
Choose File > Options > Trust Center > Trust Center Settings.
Select Trusted Locations and click Add new location.
Browse to the folder, select Subfolders of this location are also trusted if needed, and click OK.
Keep trusted locations narrow. Trust a specific application folder, never Downloads, Desktop, Documents or a whole drive. Network folders are refused unless you tick Allow Trusted Locations on my network (not recommended); the better pattern is a local trusted folder for each user's front end, with only the back end on the network.
Files downloaded from the internet or received by email carry a Windows marker that blocks their macros regardless of the Security Warning bar. Unblock a file only if you trust its source, through Properties > Unblock in File Explorer.
Things that look like security but are not
Hiding tables or the Navigation Pane. Anyone can turn hidden objects back on in the options, or link to the tables from another database.
Startup options and disabling the Shift bypass key. These settings are stored as database properties that another Access file or script can reset.
A VBA project password. It stops casual viewing of code only.
A login form you build yourself. It controls the user interface. The tables behind it are still open to anyone who can open the file.
All of these are reasonable for keeping well-meaning users on the intended path. None of them stop someone who wants the data.
Back up, and compact
Protecting data includes protecting it from loss. Access databases can become corrupt after a dropped network connection or a crash.
Use File > Save As > Back Up Database for a dated copy, and include the back-end folder in scheduled file backups. Copy the file when no one has it open.
Run Database Tools > Compact and Repair Database periodically on the back end. It reclaims space and repairs minor damage.
Avoid opening the back end over Wi-Fi, VPN or synchronised folders such as OneDrive. Unreliable connections and sync conflicts are a common cause of corruption.
An .accdb file cannot exceed 2 GB.
When to move the data out of Access
If you need individual logins, table or row permissions, auditing, encryption managed by a server, or regulatory compliance for personal or financial data, keep Access as the front end and move the tables to a server database. SQL Server Express is free, and the SQL Server Migration Assistant for Access converts the tables and relinks them. Dataverse and SharePoint lists are the Microsoft 365 alternatives for lighter workloads.
