Can VBA code really be protected from copying?

Yes, but not with the built-in password. Real protection means removing the VBA source from the file you ship, by compiling the logic to obfuscated .NET. That does not make copying impossible, but it raises the cost from seconds with a free tool to expert-weeks of reverse-engineering.

How do I lock VBA code so others cannot see it?

Hiding the project in the editor (the password or the 'unviewable' trick) does not lock anything, the code is still in the file. To truly stop others reading it, the source must leave the file, which means compiling to .NET and obfuscating, then shipping an XLL add-in instead of an xlsm.

Do I need to learn .NET to protect my VBA?

No. A migration tool such as Excel Armor converts your VBA business logic to VB.NET for you and compiles it. Your UserForms and Ribbon stay in VBA. You do not have to write new .NET code unless you want to.

How to Protect VBA Code From Being Copied

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

Short answer: The VBA project password does not protect anything, it only hides code in the editor and is removed in seconds with free tools. To truly protect VBA, the source has to leave the file you ship: migrate your business logic to compiled .NET, obfuscate it, and distribute it as a signed XLL add-in. That is what Excel Armor automates, and it keeps your Ribbon and UserForms in VBA.

Why the obvious method does not work

Almost everyone starts with Tools → VBAProject Properties → Protection → Lock project for viewing, sets a password, and assumes the code is safe. It is not. That password does not encrypt the code, it sets a flag that tells the Visual Basic Editor to hide the project. The macros are still stored, in full, inside the file. Free utilities, or a couple of minutes with a hex editor, remove the flag and reveal everything. The "VBA project unviewable" trick is the same idea with a different flag, and fails the same way. We cover the mechanics in why the VBA password is not protection.

The lesson: if the source is still in the file, it is not protected. Real protection has to take the source out of the artifact you hand to your users.

The four steps that actually protect VBA

Stop treating the password as security. Keep it if you like for tidiness, but assume anyone who wants the code can read it as long as the VBA is in the file.
Remove the source from the shipped file. Convert your VBA business logic to .NET source and compile it. Once compiled, the original VBA no longer exists in what you distribute, there is nothing to "unlock."
Obfuscate the compiled code. Apply industry-standard .NET IL obfuscation so that even decompiling the assembly yields tangled, hard-to-read output rather than your clean logic.
Sign it and control distribution. Code-sign the add-in with your own certificate so Windows and your customers trust it, and add licensing hooks so a single purchase cannot be freely passed around.

The result is a native Excel XLL add-in that behaves like any other add-in for your users, while the valuable logic ships as compiled, obfuscated machine-level code instead of readable VBA.

Do you have to rewrite everything in .NET?

No. The practical approach keeps your UI in VBA (Ribbon, UserForms, the parts that are tedious to rebuild) and moves only the business logic out to compiled .NET. A migration tool does the VBA-to-VB.NET conversion for you. Excel Armor's Migrator, for example, converts the logic and produces a ready-to-compile MSBuild project, and the Armor step packages, obfuscates, and prepares it for signing. You stay in control of the readable VB.NET source.

What protection cannot do

No method makes reverse-engineering impossible. A determined, well-resourced attacker can attempt to deobfuscate compiled .NET. The goal is not perfection, it is raising the cost of copying past the point where it is worth it for the realistic threats: resold workbooks, lifted formulas, code taken by a departing employee. Compiling and obfuscating moves that cost from "free tool, a few seconds" to "expert, many weeks." Any product that promises "uncrackable" is overselling, and that is a reason to be skeptical of it.

See where your workbook stands

Take the free 2-minute self-assessment, or read the security guide that walks through every protection method in plain language.

Free VBA protection check Download security guide (PDF)