The Problem (Q-score 4, ranked #205th of 303 in the Excel VBA archive)
The scenario as originally posted in 2009
I’m responsible for developing a large Python/Windows/Excel application used by a financial institution which has offices all round the world. Recently the regulations in one country have changed, and as a result we have been told that we need to create a “locked-down” version of our distribution.
After some frustrating conversations with my foreign counterpart, it seems that they are concerned that somebody might misuse the python interpreter on their computer to generate non-standard applications which might be used to circumvent security.
My initial suggestion was just to take away execute-rights on python.exe and pythonw.exe: Our application works as an Excel plugin which only uses the Python DLL. Those exe files are never actually used.
My counterpart remained concerned that somebody could make calls against the Python DLL – a hacker could exploit the “exec” function, for example from another programming language or virtual machine capable of calling functions in Windows DLLs, for example VBA.
Is there something we can do to prevent the DLL we want installed from being abused? At this point I ran out of ideas. I need to find a way to ensure that Python will only run our authorized programs.
Of course, there is an element of absurdity to this question: Since the computers all have Excel and Word they all have VBA which is a well-known scripting language somewhat equivalent in capability to Python.
It obviously does not make sense to worry about python when Excel’s VBA is wide-open, however this is corporate politics and it’s my team who are proposing to use Python, so we need to prove that our stuff can be made reasonably safe.
Why community consensus is tight on this one
Across 303 Excel VBA entries in the archive, the accepted answer here holds niche answer (below median) status — meaning voters are unusually aligned on the right fix.
The Verified Solution — niche answer (below median) (+9)
Verbal answer — walkthrough without a code block
Note: the verified answer is a prose walkthrough. If you need a runnable sample, check Excel VBA entries ranked in the top 10 of the same archive.
“reasonably safe” defined arbitrarily as “safer than Excel and VBA”.
You can’t win that fight. Because the fight is over the wrong thing. Anyone can use any EXE or DLL.
You need to define “locked down” differently — in a way that you can succeed.
You need to define “locked down” as “cannot change the .PY files” or “we can audit all changes to the .PY files”. If you shift the playing field to something you can control, you stand a small chance of winning.
Get the regulations — don’t trust anyone else to interpret them for you.
Be absolutely sure what the regulations require — don’t listen to someone else’s interpretation.
When to Use It — vintage (14+ years old, pre-2013)
Ranked #205th in its category — specialized fit
This pattern sits in the 97% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Excel VBA archive for a higher-consensus alternative.
What changed between 2009 and 2026
The answer is 17 years old. The Excel VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.