Encrypting and Password-Protecting an MS Access Database

Every few weeks someone emails me because they've realised their Access database is sitting on a shared drive with no protection at all. Payroll figures, customer lists, supplier prices, all of it wide open to anyone who can find the file. The good news is that Access has built-in tools for this, and setting them up takes minutes. The catch is that a lot of people do it wrong, or expect more protection than it actually provides. Let me walk you through how it really works.

Password protection vs encryption: they're the same thing now

In older versions of Access, you could set a password on a file that only stopped casual users from opening it. The data itself sat in plain text, and anyone with a hex editor could read it. That's no longer the case. In Access 2010 and every version since, setting a database password automatically encrypts the underlying file. The two are tied together.

So when we talk about encrypting and password-protecting an MS Access database today, we're describing one action: you set a password, and Access scrambles the entire file using strong encryption. Nobody can open it, and nobody can read the raw file contents, without that password.

How to actually set it up

The feature is called Encrypt with Password, and it lives in a slightly awkward spot. Here's the exact sequence for a standard .accdb file:

1. Close the database if it's open, then reopen it in exclusive mode. To do that, go to File, Open, browse to the file, and click the small arrow next to the Open button. Choose Open Exclusive.
2. Go to the File tab, then Info.
3. Click Encrypt with Password.
4. Type your password twice and click OK.

The exclusive-mode step trips people up constantly. If the database opens normally, the encrypt option will be greyed out or throw an error. Access needs sole control of the file before it can encrypt it.

If you lose the password on an encrypted Access file, there is no back door. Microsoft can't recover it, and neither can I. Write it down somewhere safe before you set it.

Choosing a password that's worth setting

Encryption is only as strong as the password behind it. A four-letter word protects nothing. I tell clients to use at least twelve characters, mixing letters, numbers, and a symbol or two. A short passphrase like "BlueOffice7Ledger" is far easier to remember and far harder to crack than something like "Pass123".

One practical note: store the password in a proper password manager, not in a sticky note on the monitor and not in a text file called "passwords" sitting next to the database. I've seen both.

The split-database problem nobody warns you about

Most well-built Access systems are split into two files: a front-end with your forms and reports, and a back-end that holds the actual tables. If you've read my guide on splitting a database, you'll know why. When it comes to encryption, this matters a lot.

The data lives in the back-end. That's the file you need to encrypt. But once you password-protect the back-end, the front-end can no longer connect to its linked tables automatically, because it doesn't know the password. You have to re-link the tables and supply the password so Access stores the connection. It's not difficult, but if you skip this the whole system stops working, and people panic.

So the correct order is: encrypt the back-end first, then re-link the front-end tables using the password. Do it the other way around and you'll waste an afternoon.

What password protection does and doesn't cover

This is where I try to set honest expectations. File-level encryption protects the file. It does not give you user accounts, permission levels, or an audit trail of who changed what. Everyone who opens the database gets the same password and the same access to everything inside.

The old user-level security model that used to handle permissions was retired with the .accdb format. If you genuinely need per-user access control, that's usually the point where a database has outgrown Access and belongs on SQL Server, which I've written about separately.

Common mistakes I get called in to fix

A few patterns come up again and again:

• Encrypting the front-end instead of the back-end. The forms get locked, but the actual data file stays exposed.
• Setting a password and never backing up the file. If that single encrypted file corrupts, you've lost everything with no unprotected copy to fall back on.
• Storing the password inside the database's own VBA code. Anyone who can open the file can read it, which defeats the purpose.
• Assuming a password stops copying. Someone can still copy the encrypted file to a USB stick. They just can't open it. That's fine, but people misunderstand what protection they've got.

A sensible security setup for a small business

If you want a straightforward, defensible arrangement without overengineering it, this is what I usually recommend:

1. Split the database into front-end and back-end if it isn't already.
2. Encrypt the back-end with a strong password and re-link the front-end tables.
3. Keep the back-end on a folder that only the right people can reach through Windows permissions.
4. Run automatic backups of the encrypted file, and confirm the backups actually restore.
5. Store the password in a shared password manager your team can access.

That combination handles the realistic threats a small office faces: a lost laptop, a nosy visitor, a file that ends up on the wrong shared drive.

If you'd like a hand getting this set up correctly, or you're not sure whether Access is still the right home for sensitive data, my team and I are happy to take a look. We can encrypt an existing database, sort out the front-end links, and check your backups are sound. Existing-database work like this starts from $30/hour, and I'm always glad to give you a straight answer before you commit to anything.