Can VBA code be made completely uncrackable?

No. No protection method - for VBA, .NET, native code, or anything else - makes reverse-engineering impossible. The honest goal is to raise the cost of reverse-engineering above what an attacker is willing to pay. That is achievable for VBA, by moving business logic out of VBA into compiled and obfuscated binaries.

What is the strongest protection available for VBA today?

Migrating VBA business logic to a compiled .NET assembly, obfuscating it with an industry-standard .NET IL obfuscator, packaging it as an XLL add-in, and signing it with Authenticode. This combination removes the source from the shipped artifact, makes IL reversal expensive, and prevents tampering. Excel Armor automates this pipeline.

Is obfuscation the same as encryption?

No. Encryption requires a key to read the content; obfuscation makes the content harder to read but does not require a key. For shipped software, encryption alone is rarely useful because the key has to ship with the code to run, which means an attacker has both. Obfuscation is the standard control for shipped binaries.

Can VBA Really Be Protected?

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

Short answer: yes - meaningfully, but not absolutely. This page is the longer answer. It is written for Excel developers who are tired of vendor marketing claims and want a straight technical account of what works, what does not, and why.

The whole field suffers from one persistent problem: every vendor (us included) has a financial interest in your conclusion. We have tried to write this in a way that would hold up if you read it next to the documentation of any of the other tools in the market. If a claim on this page is wrong, tell us and we will correct it.

The right question

"Can VBA be protected?" is the wrong question. The right question is: "Can the cost of stealing my VBA be raised above the cost of paying for a licence?" That framing makes the problem solvable. It also makes the marketing claims you see in this space easier to evaluate. Any vendor who tells you their tool is "uncrackable" or "unbreakable" is selling you a property that does not exist - not for VBA, not for compiled C, not for anything. That language is the strongest possible signal that the vendor is selling marketing rather than security.

Real protection is economic. You want the attacker's reasonable estimate of the time and skill required to extract your logic to be larger than the price of just buying a licence. Get that right and the math takes care of the rest.

The threat model that matters in practice

Almost no Excel developer is being attacked by a state actor or a professional reverse-engineering shop. The realistic threats are:

Resale. A customer buys one licence and redistributes the workbook to their network.
Internal extraction. A former employee leaves with a copy and stands up a competing tool.
Casual copying. A competitor downloads your trial, opens the VBE, and copies your most interesting routines.
"AI-assisted" reverse-engineering. A user pastes your VBA into an LLM and asks it to explain or replicate the logic.

Notice what is not on that list: nation-state attackers, professional cracking groups, weeks-long IL deobfuscation campaigns. Those exist, but they are not your threat model unless you are selling something extraordinary. Designing protection for the realistic threat model is what makes it possible. Designing for the worst case is what leads vendors to make claims their products cannot meet.

What does not work (and why)

The VBA project password

The Excel VBA project password is not a security control - it is a UI flag that tells the editor whether to display the project tree. The underlying source code is stored in a binary stream documented by Microsoft ([MS-OVBA]) and can be read directly without the password ever being involved. Detailed write-up: Why the VBA password is not protection.

Worksheet and workbook protection

These features exist to prevent accidental edits. Microsoft documents them as such. The password algorithm collides on short inputs, the protection bits live in known places in the file, and the data behind protected sheets is never encrypted. Sheet protection is a usability control, not a confidentiality control.

"VBA obfuscation"

Renaming variables to aaa, aab, aac and stripping comments does make code annoying to read. It does not stop a determined reader, and it stops a casual reader for about thirty minutes. Worse, the algorithm structure is preserved verbatim - which is exactly the part of your IP that has commercial value. An attacker who cannot read your variable names can still read your business logic. VBA-level obfuscation is theatre.

Hidden modules, very-hidden sheets, "stealth" tricks

All of these rely on the assumption that the attacker uses the same UI you do. They do not. Anyone parsing the file format directly sees everything regardless of visibility flags. These tricks slow down a curious customer; they stop nobody who is actually trying.

What does work: the four-step pipeline

Every effective protection scheme for VBA-based Excel software ends up looking like the same four steps, in some order. Vendors differ in how they implement each step, not in which steps they include.

Step 1: Remove the source from the shipping artifact required

The single most important step. As long as VBA source is in the file you ship, no amount of wrapping it makes that source disappear. The realistic options are:

Compile to a separate native binary (DLL). Classic, works, but writing the C/C++ yourself is a steep on-ramp for a VBA developer.
Compile to a .NET assembly or XLL. The middle road. .NET is much closer in style to VBA, the tooling is free, and Excel-DNA gives you Excel-native XLLs out of the box.
Wrap the workbook in a container EXE. Used by some vendors. The VBA still exists - it lives inside the container - but the container is what ships.

Excel Armor takes the .NET route: its Migrator converts VBA business logic to VB.NET source plus an MSBuild project. UserForms and Ribbon stay in VBA, so the Excel-native UX is preserved.

Step 2: Obfuscate the binary required

Compiled is not the same as unreadable. Both native binaries and .NET assemblies can be reversed with public tooling. Obfuscation - control-flow flattening, string encryption, identifier renaming, anti-debugging - raises the cost. For .NET, Excel Armor applies an industry-standard open-source IL obfuscator as part of the build.

What obfuscation does not do is make code mathematically irreversible. It makes reversing slow and expensive. That is the entire goal.

Step 3: Sign the binary strongly recommended

Authenticode signing on Windows does two things. First, it gives your customer's IT department a verifiable identity for your code, which matters for whether they will allow it to load. Second, and more important for protection: a signed binary refuses to load if its bytes have been modified. That closes the door on "patch out the licence check" attacks, which are otherwise the easiest path through any of the protection above. Excel Armor produces an MSBuild project ready for Authenticode signing; you supply the certificate.

Step 4: Bind execution to a licence recommended

Once your logic is compiled and signed, you have a stable place to enforce licensing: machine fingerprinting, time-bounded trials, feature flags, online activation. The choice of licensing model is yours; the important point is that licence checks inside compiled, obfuscated, signed code are dramatically harder to defeat than licence checks inside VBA.

Where the field disagrees

Different products in the VBA protection space make different bets on the four steps. There is no single "best" answer - there are honest trade-offs:

Compile to .NET XLL vs. wrap in EXE. XLL keeps the Excel-native experience and ships compiled code. EXE wrapping is simpler to adopt but keeps your VBA inside a container. We made our bet on XLL; see the trade-offs.
Free obfuscator vs. proprietary obfuscator. The mainstream open-source .NET obfuscators are free and battle-tested; some vendors use proprietary obfuscators. Both can work. "Custom obfuscator we wrote in-house" is sometimes a red flag, sometimes not - ask the vendor for a description of what their obfuscator actually does.
Built-in licensing vs. BYO licensing. Some vendors couple protection and licensing tightly; others leave licensing to you. There is no right answer.

Marketing claims that do not survive contact with reality

Independent of which vendor you choose, the following claims should make you walk away:

"Uncrackable" / "unbreakable" / "impossible to reverse-engineer." Not true of any product, anywhere, at any price.
"Military-grade encryption protects your code." Encryption is irrelevant if the key ships with the code, which for runnable software it must.
"AES-256 prevents reverse-engineering." See above - what stops reverse engineering is obfuscation, not encryption.
"Our protection has never been broken." How would the vendor know? Successful crackers do not publish.

(For full transparency: our own homepage does reference AES-256 in the context of licensing artefacts, where encryption is the correct primitive. We try not to use it as a stand-in for "your code is safe." If you ever see us drift in that direction, call us out.)

What we sell, in plain language

Excel Armor automates Step 1 (Migrator converts VBA business logic to VB.NET and produces an MSBuild project) and Step 2 (industry-standard obfuscated XLL is the output), provides scaffolding for Step 3 (Authenticode-ready build), and includes hooks for Step 4 (machine-bound licensing). We do not promise uncrackability. We promise to move your code from "free tool, sixty seconds" to "skilled adversary, days." For most Excel developers, that is the difference between being copied freely and being paid.

See the full pipeline

The security guide covers the threat model, the protection categories, and the practical decision tree for choosing among them.

Download the security guide (PDF) See how Excel Armor works