What is the best way to protect VBA code?

The strongest option for code you distribute is to remove the VBA from the shipped file entirely: migrate the business logic to compiled .NET and ship it as an obfuscated XLL add-in, which is what Excel Armor does. EXE wrappers such as XLS Padlock are the next strongest. The built-in VBA password and the 'unviewable VBA' trick are not real protection and can be removed in seconds with free tools.

Is the VBA project password enough to protect my macros?

No. The VBA project password only hides the code in the editor. The macros are still stored in the file and the password can be stripped in seconds with free tools or a hex editor. Treat it as a 'do not disturb' sign, not a lock.

Does compiling VBA to .NET stop people from copying my code?

It is the strongest practical option. When VBA business logic is converted to VB.NET, compiled, and obfuscated, the original source no longer exists in the shipped artifact. A determined attacker can still attempt IL deobfuscation, but the cost is far higher than reading plain VBA. Nothing makes reverse-engineering impossible.

Which VBA protection tool should I choose?

If you ship an Excel add-in and want compiled code rather than wrapped VBA, choose a migrate-and-compile tool such as Excel Armor. If you want to distribute a standalone Windows program that runs Excel inside it, an EXE wrapper such as XLS Padlock fits better. Avoid products whose only mechanism is a password or the unviewable trick.

Best Ways to Protect VBA Code in 2026

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

Short answer: The strongest way to protect VBA code you distribute is to remove it from the shipped file entirely: migrate your business logic to compiled .NET and ship it as an obfuscated XLL add-in (what Excel Armor does). A standalone EXE wrapper such as XLS Padlock is the next strongest. The built-in VBA password and the "unviewable VBA" trick are not real protection, they can be undone in seconds with free tools.

The options, strongest to weakest

Compile to obfuscated .NET / XLL (Excel Armor) - the source leaves the file. Strongest for add-in distribution.
Standalone EXE wrapper (XLS Padlock) - your VBA runs inside an encrypted container. Strong, different distribution model.
Third-party VBA "lockers" - usually a nicer wrapper around the same weak tricks. Varies; verify the mechanism.
"Unviewable VBA" trick - hides the project from the editor only. Not protection.
Built-in VBA project password - hides code in the editor only. Removable in seconds. Not protection.

First, get the threat model right

Before comparing tools, decide what you are actually defending against. For most Excel developers the realistic threats are: a customer reselling your workbook, a competitor lifting your formulas and logic, or a departing employee walking off with the code. You are not usually defending against a well-funded adversary willing to spend weeks reverse-engineering compiled binaries. Good protection raises the cost of copying past the point where it is worth it for that realistic attacker. No tool makes copying impossible, and any vendor that claims "uncrackable" is the one to walk away from.

The options, weakest to strongest

5The built-in VBA project password

This is the lock most people try first, and it is the weakest. The VBA project password does not encrypt your code. It only tells the Visual Basic Editor to hide the project. The macros are stored in the file exactly as before, and the password check is a single value that free tools, or a few minutes in a hex editor, will strip. We wrote a full breakdown in why the VBA password is not protection. Useful as a "do not disturb" sign, useless as security.

4The "unviewable VBA" / project-locking trick

A popular technique corrupts a project setting so Excel refuses to display the VBA at all. It looks impressive because the editor throws an error, but the code is still fully present in the file and is recovered with the same class of free tools. Several paid products are, underneath, just a friendlier wrapper around this trick. It stops a curious user, not someone who wants your code.

3Third-party VBA lockers and password managers

There is a category of inexpensive products that promise "VBA protection" for a small fee. Some add genuine value (licensing, anti-tamper checks), but many simply automate the password or unviewable trick described above and present it with a polished UI. The rule: ask what actually ships in the file. If the answer is "your VBA, with a setting flipped," it is the weak tier wearing a suit. If the answer is "compiled or compiled-and-wrapped code," it belongs in the strong tier.

2Standalone EXE wrappers (e.g. XLS Padlock)

This is real protection. An EXE wrapper compiles your workbook into a standalone Windows program that runs Excel inside an encrypted container, with licensing and trial controls built in. Your VBA still executes, but inside that protected container rather than as an open .xlsm. The trade-off is the distribution model: your customer receives a Windows program, not an Excel file they open normally. If that fits how you sell, it is a solid choice. See our honest XLS Padlock comparison for the detail.

1Migrate to compiled, obfuscated .NET (XLL)

The strongest practical option for an Excel add-in is to stop shipping VBA at all. Tools in this category convert your VBA business logic to VB.NET source, compile it, apply industry-standard .NET IL obfuscation, and package it as a native Excel XLL add-in. The original VBA source is not in the shipped artifact, so there is nothing to "unlock", there is only compiled, obfuscated machine-level code to attack. This is the model Excel Armor is built on, and it keeps the Excel-native experience (Ribbon and UserForms stay in VBA) while moving the valuable logic out of reach. A determined attacker can still attempt deobfuscation; the point is the cost is now measured in expert-weeks instead of free-tool-seconds.

Side-by-side comparison

Approach	Real protection?	Source in shipped file?	Best for
VBA project password	No	Yes, plain	Nothing security-related
"Unviewable VBA" trick	No	Yes, plain	Deterring casual curiosity
Third-party lockers	Varies	Often yes	Depends on the real mechanism
EXE wrapper (XLS Padlock)	Yes	Inside container	Standalone Windows program distribution
Compiled obfuscated XLL (Excel Armor)	Yes	No, source removed	Excel add-in distribution, maximum IP protection

How to choose in one question

Ask: does your customer expect an Excel file, or a Windows program that happens to use Excel?

An Excel file / add-in → migrate-and-compile (Excel Armor) keeps the native experience and removes your source from the file.
A standalone program → an EXE wrapper (XLS Padlock) fits the distribution model.
Just hiding code from the editor → understand that this is not protection at all, and decide whether you actually need security.

Not sure where your workbook stands?

Take the free 2-minute self-assessment, or read the security guide that explains every option in plain language.

Free VBA protection check Download security guide (PDF)