By Hiran de Silva
There’s a phrase that crops up far too often in LinkedIn posts, tech webinars, and internal policy conversations. This morning, Owen Price repeated it again: “VBA is blocked in most organizations.” It’s a statement delivered with such casual certainty that few ever stop to ask: Why? What exactly is the threat? What specific damage are we so determined to prevent?
Let’s ask the question plainly: What is it that VBA (Visual Basic for Applications) is supposed to be doing that makes it uniquely dangerous—more so than Python, JavaScript, or even Excel formulas?
You’ll usually hear some hand-wavy reply about “security,” or “it could be used maliciously.” Press further, and the explanations dry up. Yet ironically, the very same people advocating for Python rarely pause to admit: Python can do everything VBA can do—and more. It too can modify code, alter data, and interface with external systems. So why is VBA singled out?
Let’s dissect this.
1. The Worm That Launched a Thousand Misconceptions
The origin of VBA’s bogeyman status lies in the late 1990s and early 2000s. Yes, there was a brief and annoying trend of “Word worms”—self-replicating macros sent via email attachments. Often, they were written by young, mischievous coders more interested in showing off than stealing data. These “worms” spread by emailing themselves to the user’s contacts. But Microsoft quickly addressed the issue by implementing macro warnings and disabling auto-execution by default.
The threat was real—but it was short-lived, well-mitigated, and largely historical. Still, the fear lived on. The idea that “VBA is dangerous” calcified into a kind of folklore, passed down across generations of IT professionals like the tale of a cursed object. It’s become the Thanksgiving turkey myth: we still cut the turkey in half when cooking—not because we need to, but because our grandmother’s oven was too small 50 years ago.
2. The Real Issue Isn’t VBA. It’s User Empowerment
If you really want to know why VBA (and similar tools) are frowned upon in many IT circles, you need to look at the broader issue: control.
VBA isn’t banned because it’s insecure. It’s banned because it gives users the power to build their own solutions. That’s what the term “EUC” (End User Computing) was invented to contain. It was a label slapped on anything that wasn’t built by the IT department but still functioned—and often functioned better—than official systems.
Back in the 90s, this might have meant a rogue Access database, or a self-updating Excel workbook. Today, it could be a Power Automate flow or a Power App. But the underlying tension remains unchanged: users are solving problems faster than IT departments can approve of them.
3. Helpdesk Blame Games and The Fear of Support
Another reason you’ll hear: “Users build things in Excel, then call the helpdesk when it breaks.”
Let’s break that down.
The IT department installs a sandboxed version of Excel. A user builds a VBA tool to speed up a reporting process. Something goes wrong. The helpdesk is called. They haven’t seen the spreadsheet. They can’t debug it. The conclusion? “Let’s ban VBA.”
But by that logic, we should also ban formulas, Power Query, and pivot tables. They all break. They all cause user confusion. But that’s the price of democratized productivity. And crucially: the alternative isn’t fewer support calls—it’s fewer solutions.
4. The Modern Irony: New Tools, Same Fear
You might think we’ve moved on. Today, we have Power Automate, Power Apps, Office Scripts. Microsoft now markets empowerment to the user as a feature, not a flaw. So surely IT departments have evolved?
Not quite.
Attend any enterprise tech roadshow and you’ll see three separate sessions: one for end users (usually empty), one for business managers (mildly interested), and one for IT professionals (standing room only). In the IT track, the most excitement isn’t about what Power Automate can do—but about the kill switch. That’s right: they celebrate the fact that all those powerful features can be turned off with a single toggle.
So now we’re in a strange place. C-suite leaders believe their teams are empowered with modern tools. Meanwhile, behind the scenes, many IT departments are disabling everything except the superficial fluff—so they can tick the box without losing control.
5. The Great Misunderstanding: VBA ≠ Risk. Misuse Does
Can VBA print all your confidential documents? Technically, yes. So can Python. So can PowerShell. But why would an internal department head embed malicious code into a tool designed to help their own team?
We’re conflating internal business tools with external unknown threats. If a manager builds a VBA solution to automate reconciliation, it’s no more a threat than a driver using a car to get to work. Sure, someone somewhere might misuse a car—but you don’t outlaw driving because of bad drivers.
6. The Laughable Logic of “VBA is Not Allowed”
The statement “VBA is not allowed” is rarely backed up with clear policy or reason. More often, it’s parroted from outdated dogma—like someone shouting, “Don’t touch that! It’s dangerous!” without checking if the danger even applies anymore.
Let’s be honest. If the issue is programming, then Python should be blocked too. If the issue is user empowerment, then we need a deeper conversation about governance, ownership, and trust—not lazy bans.
7. Conclusion: Don’t Cut the Turkey in Half
There is no valid reason in 2025 to say “VBA is not allowed” without explaining the context. If your issue is governance, say that. If it’s maintainability, say that. If it’s shadow IT, fine. But let’s stop pretending VBA is inherently malicious. It’s not. It’s a tool. Like every other tool, it’s only as dangerous—or powerful—as the person using it.
The real question isn’t “Should we block VBA?” The real question is: Do we want empowered users—or not?
And if the answer is no, you’d better be prepared to build every tool, automate every workflow, and support every need yourself. Good luck with that.
Postscript:
Let’s remember the grandmother’s oven. The reason we cut the turkey in half no longer exists. But the ritual lives on—pointless, unquestioned, and defended with passion.
Much like banning VBA.
Add comment