Legacy code, modern phishing: why COBOL is not the problem (nobody remembers how the machine thinks)

Ok, this is more than personal imho.. a public tender goes out.
Sogei, the Italian state technology backbone responsible for tax systems, financial infrastructure, and core public digital services, is looking for COBOL programmers – AD 2026, right.

Most people smile at that headline and some joke about the sixties.
Others make nostalgic comments about punch cards and me am in the middle, because that reaction is the first mistake.

COBOL was born in 1959 to process business transactions, it was designed to be verbose, predictable, and stable. If you’re new to this, think about its core that is designed not crash dramatically and not improvise (AI, gotcha!).
It does exactly what it is told, reliably, at scale – and that is why it still runs large parts of the global financial system.

Bank systems still settle transactions on COBOL-based cores.
Governments still calculate taxes and pensions on COBOL-driven engines.
Insurance platforms, payment processors, clearing houses, that’s the skeleton of modern economies was not rewritten for the cloud.

It was WRAPPED.
The real risk now is not the language but the growing distance between the people operating the system and the logic embedded inside it.
Really, the engineers who built these environments are retiring (or just are.. dead), and documentation is incomplete, and iInstitutional memory is thinning.
Meanwhile.. modern identity providers, web front-ends, APIs, automation agents, and cloud connectors are layered on top of systems never designed for today’s authentication and authorization complexity.

Legacy systems were built in an era of perimeter trust and controlled environments; modern infrastructures assume distributed identity, zero trust principles, and dynamic access models: when the two meet, the glue is often fragile.

Let’s see:
– shared administrative accounts
– static credentials
– minimal session logging
– limited behavioral monitoring
– access controls retrofitted rather than designed

Now add phishing.
Lads and gets, the risk is served.
Not ransomware or zero-day exploits, just a believable email, a modified invoice, a contextual request that matches an ongoing project.

If a compromised identity gains access to a legacy financial core, the attacker does not need to understand COBOL deeply, they need to understand trust boundaries and human behavior.
Here phishing becomes the bridge between modern manipulation and historical infrastructure – the young musketeer and the diinosaur, if I may say.

We like to imagine attackers exploiting obscure buffer overflows in ancient code, but, hey!, the truth is more mundane, huge more! They inherit credentials and reuse legitimate access and operate through accounts that already have permission.

Opaque is the underlying system, isn’t it?
Ok now, when few people understand how the machine thinks, accountability falls and weakens, highlighting that small manipulations can live longer before being noticed.

So, why are stressing this much about awareness?
Frank Zappa was “measuring it” with a plastic chicken (right, that one!) and we’re measuring on failures we see each day!
Because legacy systems amplify the consequences of human error: and could be the assistant who approves a change, or the engineer who extends access temporarily, or the manager who assumes the request makes sense because it fits the calendar, or just you.

You can migrate interfaces to the cloud and still depend on forty-year-old logic underneath.
You can implement MFA on top of a system that was never designed for granular identity tracking.
You can deploy agents and automation against cores whose behavioral baseline nobody has fully mapped in years.
But if your critical infrastructure runs on code older than your governance model, then security is not a tooling problem..

COBOL is not dangerous (HAIL COBOL), ignorance layered over legacy is.
And phishing is the simplest way to exploit it.