VBA project password
Quick visual lock against accidental opening. Many free tools can remove it. Useful for honest users only.
VBA code protection
Four layers around your VBA.
Stack what your threat model needs.
VBA protection is not binary. XLS Padlock ships four independent layers: project password, hide-and-lock, bytecode compilation, and VBE access denial. Stack one or stack all four. The right choice depends on who you ship to and how aggressively you expect them to reverse-engineer.
From readable source to compiled bytecode.
Layer 3 is the hardest to defeat. You move the procedures you select into the XLS Padlock VBA editor, which compiles them to bytecode stored in the application. The original logic leaves the workbook: where the macro used to run, only a call to the CallXLSPadlockVBA helper remains.
Each layer beats a different class of attack.
Hide-and-lock VBA
The XLS Padlock manager locks the VBA project so it cannot be viewed, accessed, or modified. Anyone who opens it sees a Project is unviewable message, and because the workbook is encrypted inside the EXE, password-removal tools cannot reach the source.
VBA Compiler
You move the critical parts of your macros into the XLS Padlock VBA editor and compile them to bytecode. You then replace the original code with a call to the CallXLSPadlockVBA helper, so the source logic leaves the workbook and runs only inside the secure application.
VBE access denied
The compiled application can forbid opening the Visual Basic Editor (Alt+F11), so end users cannot open the VBE to inspect the project.
Three threat models, three depths of protection.
Just hide the source from honest users
Use the VBA project password plus hide-and-lock. Fastest setup, no code refactoring. Good enough if your customers will not actively reverse-engineer.
Compile the IP, keep the wiring
Move your sensitive procedures into the XLS Padlock VBA editor and compile them, while leaving event handlers and UserForm code in plain VBA. Best balance of security and developer ergonomics.
Compile aggressively, refactor as needed
Move as much business logic as you can into the VBA editor and compile it: math libraries, calculation engines, exporters, anything that does not depend on Excel UI events. Expect to adapt some code (explicit Application object, supported objects only), but you maximize the protected surface.
Lock the project, compile the IP, deny the editor.
For most commercial workbooks, the right baseline is layers 2, 3, and 4: hide the project from the Excel UI, move sensitive code into the XLS Padlock VBA editor to compile it, deny VBE access at runtime. Skip layer 1 (the project password) since it adds nothing once the EXE refuses to open the editor anyway.