Does encrypting an xlsm protect the VBA macros inside it?

Only while the file is closed. Once someone with the password opens it, the VBA is fully readable, the encryption no longer applies. Anyone you distribute the file to has the password, so for protecting code from your own users, file encryption does nothing. The macros need a separate approach: compiling them out of the file into obfuscated .NET.

Is Excel's password encryption strong?

For modern Excel, the workbook-open password uses real AES encryption and is strong against opening the file without the password, as long as the password itself is strong. This is different from the VBA project password, which is not encryption at all and is removed in seconds.

How to Encrypt an Excel .xlsm File

Published: 2026-06-27 · Last reviewed: 2026-06-27 · By Noam Brand, founder, Excel Armor

Short answer: To encrypt an .xlsm, open it in Excel and go to File → Info → Protect Workbook → Encrypt with Password, then set a strong password. Excel encrypts the whole file with AES, so it cannot be opened without that password. Important: this protects the file at rest, not the macros once an authorised user opens it. To protect the VBA code itself, you have to compile it out of the file, which is what Excel Armor does.

Step by step: encrypt the workbook

Open your .xlsm in Excel.
Go to File → Info.
Click Protect Workbook → Encrypt with Password.
Enter a strong password and confirm it. Store it safely, if you lose it the file is not recoverable.

From now on, the file is encrypted with AES. Anyone without the password sees only ciphertext. For the realistic goal of "stop a stranger who finds the file on a lost laptop from reading it," this is genuinely strong, as strong as your password.

What encryption protects, and what it does not

Workbook encryption protects the file at rest. The moment someone with the password opens it, everything inside, cells, formulas, and crucially your VBA macros, is fully available. That matters because of one simple fact:

Everyone you distribute the file to has the password. If you ship an encrypted tool to customers, you also give them the key. From that point, the encryption is doing nothing to protect your code from them, they are inside.

So encryption is the right tool for confidentiality in transit and storage. It is the wrong tool for protecting intellectual property in code you distribute. Those are different problems.

Two different passwords, do not confuse them

Workbook-open password (the one above): real AES encryption, strong, protects opening the file.
VBA project password: a separate, much weaker setting that only hides the macros in the editor. It is not encryption and is removed in seconds. See why the VBA password is not protection.

Setting the second one gives a false sense of security. It does not encrypt your macros, and it does not survive contact with anyone who actually wants the code.

How to actually protect the macros

If your real concern is that customers or competitors will copy your macro logic, encryption will not do it. The reliable approach is to remove the code from the file:

Convert the VBA business logic to .NET and compile it.
Obfuscate the compiled assembly with industry-standard .NET IL obfuscation.
Ship it as a native Excel XLL add-in, with the UI staying in VBA.

Now there is no readable macro in what you distribute, only compiled, obfuscated code. Excel Armor automates this whole pipeline. See how to protect VBA code, step by step for the full method.

Encrypting the file is not enough?

Find out whether your macros are actually exposed with the free 2-minute self-assessment.

Free VBA protection check Download security guide (PDF)