Why the VBA Password Is Not Protection

Published: 2026-05-17   ·   By Noam Brand, founder, Excel Armor

Most Excel developers ship workbooks with a VBA project password set in Tools → VBAProject Properties → Protection, and reasonably assume that protects their code. It does not. The VBA password was never designed as a security control, and it has been trivially bypassable for over twenty years. This is not a controversial claim - it is documented behaviour, and the bypass procedure is on the first page of Google.

This article is not a how-to. It explains why the password fails, what threat model that leaves you in, and what actually works. If you are looking for cracking instructions, this is the wrong page; we deliberately do not publish them.

Defensive framing. The rest of this page is about understanding the threat to your own code. If you have lost the password to a workbook you own and need to recover access, talk to a vendor who specialises in that, or to Microsoft support - not to us.

What the VBA password actually is

When you set a VBA project password, Excel writes a flag into the workbook's internal storage saying "the IDE should refuse to open the project tree without this password." The source code itself is stored in a documented binary stream (commonly called vbaProject.bin inside the zipped .xlsm container) in a format that has nothing to do with the password. The password is not used to encrypt the source. It is not used to obfuscate the source. It is checked by one specific UI surface (the VBE) and ignored by everything else.

That means the source code on disk is readable to anything that knows the binary format - and the binary format is documented in [MS-OVBA], Microsoft's own open specification. There is no secret to keep.

The three bypass paths (described, not enabled)

Bypasses fall into three categories. We mention them so you understand the surface area; we do not publish step-by-step instructions.

  1. Lying to the editor. The "is protected" bit lives in a known place in the binary stream. Flip the bit, the editor stops asking for a password. The original password is not recovered or needed - it is simply made irrelevant.
  2. Replacing the password. Substitute the protected stream with one whose password you know. The editor accepts your password and shows the (unchanged) source.
  3. Skipping the editor entirely. Parse vbaProject.bin directly using the published specification, or with any of a dozen public libraries that do this in 50 lines of Python. The VBE is never involved. The password is never involved.

The third category is the one that makes the password fundamentally not-protection. Even if Microsoft hardened the editor tomorrow, the source code is still right there on disk in a documented format.

What this means for your threat model

If you ship a password-protected workbook, here is who can read your VBA today:

  • Any customer who runs one of a dozen free tools listed on the first page of Google.
  • Any developer with five minutes and a hex editor.
  • Any AI assistant you ask "how do I open a VBA project without the password," which will cheerfully explain it.
  • Anyone who has ever taken a beginner reverse-engineering course.

The realistic threat is not a state actor. It is your customer's intern, a competitor evaluating your workbook, or a former employee who left with a copy. Against that audience, the VBA password achieves zero. Against a determined attacker willing to spend hours, it achieves zero. There is no audience for which the VBA password is the right control.

"But I also locked the worksheet structure"

Worksheet protection (cells, sheets, workbook structure) is a different feature and a different conversation. It is also not designed as a security control - it is designed to prevent accidental edits. The password on those features uses a weak hash that collides quickly, and Microsoft has been explicit in their own documentation that worksheet protection is not intended to keep data confidential.

Sheet protection makes sense for the use case Microsoft built it for: stopping a user from typing in the wrong cell. It does not protect your IP.

What actually works

There is one principle: do not ship the source code. Every effective protection method is a variation on that principle:

1. Move logic to a compiled binary

Take the business logic out of VBA and put it into something that compiles to machine code or to IL. VBA in the workbook then becomes a thin wrapper that calls into the binary. The user can see the wrapper; they cannot see the logic.

That binary can be a classic DLL (C++, COM), a .NET assembly, or - the most Excel-native option - an XLL add-in that Excel loads directly.

2. Obfuscate the binary

Even compiled code can be reversed. Obfuscation (renaming, control-flow flattening, string encryption) raises the cost to a point most attackers will not pay. For .NET specifically, there are mature open-source obfuscators that are considered the industry standard for IL hardening.

3. Sign the binary

Authenticode signing does not stop reverse-engineering, but it stops a different attack: tampering. A signed XLL or DLL refuses to load if it has been modified, which closes the door on "patch out the license check" attacks. It also gives your buyers a verifiable identity, which matters for IT departments deciding whether to allow your add-in.

4. Bind to a licence

Once the code is compiled, you have a place to put licence checks that cannot be edited out in a hex editor. Machine-bound activation, time-limited trials, feature flags - all become possible.

What Excel Armor does, in one paragraph

Excel Armor is a two-stage pipeline that automates the four steps above for Excel developers. The Migrator reads your VBA project, converts the business logic to VB.NET source and an MSBuild project, and leaves your UserForms and Ribbon in VBA. The Armor stage builds that .NET project, applies industry-standard .NET obfuscation, packages it as an Excel-native XLL with code-signing scaffolding and licensing hooks, and produces a shipping artifact in which the original VBA business logic no longer exists. See how it works on the homepage.

The honest limits

None of this makes your code impossible to reverse-engineer. It makes it expensive. The right question is not "can it be cracked," it is "is cracking it worth more than the price of a licence." For most Excel software, the answer to that question with a compiled obfuscated XLL is "no," and the answer with a VBA password is "yes."

If a vendor in this space tells you their product is uncrackable, the correct response is to leave. We will not tell you that. We will tell you that we move the bar from "free tool, sixty seconds" to "skilled adversary, days of work," which is the bar that matters in practice.

Get the full IP protection checklist

A short, practical PDF for Excel developers: the seven places VBA code leaks, a self-assessment matrix, and the protection decisions that actually move the needle.

Download the guide (PDF) Compare XLS Padlock vs Excel Armor

Related reading