We Are Still Managing Security Like It’s 2006

And we should be embarrassed about it.

Mark Twain once observed that history may not repeat itself, but it sure does rhyme. In information security, we have taken that as a design principle.

Let me be direct: if you stepped out of the information security industry in 2000 and walked back in today, you would recognise almost everything. The tools have different names. The vendors have fancier slide decks. The conference badges have better lanyards. But the problems? Identical. And more to the point — still unsolved.

Policy compliance. Identity and access management. Vulnerability management. Monitoring. Application code security. Third-party risk. These were the canonical domains of enterprise security a quarter century ago. They remain the canonical domains today. Pick up any CISO’s priorities list from 2001 and compare it to 2026. I’ll wait.

The uncomfortable truth is not merely that we haven’t solved these problems. It’s that in many cases we are still applying the same failed remedies, iterating on approaches that demonstrably do not work, and calling it progress because the tooling looks shinier.

Identity is the clearest example of collective self-deception. Least privilege has been an industry principle since before most current practitioners entered the workforce. We have spent billions of dollars on IAM platforms, PAM solutions, role-based access control frameworks, and Zero Trust marketing collateral. And yet, if I walked into a typical large financial institution today and pulled an access certification report — which I have done, many times — I would find users with accumulations of entitlements that bear no relationship to their actual job function, service accounts with domain-level permissions because someone solved an integration problem the lazy way six years ago and nobody cleaned it up, and access reviews that are rubber-stamped by managers who have neither the time nor the visibility to understand what they’re approving.

We built tooling around a fundamentally manual, exception-driven model and called it governance. The result is identity sprawl wearing a compliance veneer. A more mature approach layers dynamic, context-aware controls over a consolidated identity fabric — drawing on frameworks like OWASP’s ESAPI to enforce access decisions at the application layer in real time, rather than relying on static entitlement tables that are out of date the moment they are certified. This is also one of the more compelling legitimate applications of AI in security: using machine learning to model normal access behaviour, surface anomalies, and inform dynamic enforcement decisions in ways that no static ruleset could anticipate.

Vulnerability management is patching theatre. The industry settled early on a mental model — find the vulnerability, apply the patch, close the ticket — and never seriously revisited it even as the underlying reality changed completely. Today’s infrastructure is dynamic: containerised, ephemeral, continuously deployed. The notion of applying a patch to a running system and expecting a stable, known-good state is architecturally incoherent in a significant portion of modern environments.

The correct answer, in many contexts, is not to patch. It’s to destroy and rebuild from a known good baseline. Immutable infrastructure. If your application tier is containerised, a vulnerable image should be killed and replaced, not surgically patched in place. That approach exists. It is not exotic. Parts of the industry practice it. But the mainstream vulnerability management workflow — scan, ticket, patch, rescan — is still operating on a mental model inherited from physical server estates in 2003.

We keep applying 2003 logic to 2026 architecture and expressing frustration when the numbers don’t improve.

Application security is still largely pretending that you can test quality in rather than build it in. The dominant model remains: develop custom code, run it through SAST, DAST, and pen testing, find the flaws, remediate them, ship. Repeat indefinitely, because new code means new flaws. The security team is positioned at the end of a pipeline it has no control over, doing triage on problems that were created upstream.

The alternative is obvious and still underutilised: build software from verified, known-good components wherever possible. Treat your software supply chain as a security control surface. If your developers are assembling applications from rigorously vetted libraries and frameworks with understood security properties, the custom attack surface shrinks dramatically. This is not a new idea. The industry has been gesturing at it for years. But the gravitational pull of “scan and fix” is strong because it fits the existing org chart — security reviews something engineering built — rather than requiring genuine integration at the design layer.

Third-party risk management is perhaps the most egregious example of applying a static lens to a dynamic problem. The standard model asks a vendor to fill out a questionnaire once a year, maybe runs a BitSight scan on their external perimeter, and files the result as a completed assessment. That vendor is now “assessed.” The relationship might run for years on the strength of that initial snapshot.

The problem is that an organisation’s security posture is not a fixed property. It changes continuously — new leadership, a reorganisation, a budget cut, a breach that hasn’t surfaced publicly yet, a key person leaving, a migration to a new cloud provider. A point-in-time assessment tells you what a vendor looked like on the day they answered your questionnaire. In a world where the threat environment and operational context shift constantly, that is nearly worthless as a risk signal.

Continuous monitoring of third parties — behavioural signals, threat intelligence, external surface changes — is technically achievable today. It requires a different operating model and a willingness to treat third-party risk as a living programme rather than an annual compliance exercise. Most organisations haven’t made that shift.

The common thread across all of these is that the industry built its operating models during a period when enterprise IT was relatively static — physical hardware, long release cycles, defined perimeters, stable vendor relationships. The security disciplines that developed in that era were reasonably well-suited to it. They are poorly suited to an environment defined by continuous deployment, software-defined everything, cloud-native architecture, and supply chains of extraordinary complexity.

We are, in the most literal sense, managing a 2026 threat environment with 2006 mental models. The tools have been updated. The underlying logic has not.

There is a definition, often attributed to Einstein though probably apocryphal, of insanity as doing the same thing repeatedly and expecting different results. I am not in the business of calling colleagues insane. But I am in the business of calling out patterns that don’t work.

The security industry has a habit of rebranding existing approaches — adding “AI-powered” to the front, or “Zero Trust” to the back — and presenting incremental tooling improvements as conceptual progress. That is not progress. Progress looks like fundamentally reconsidering whether the operating model is correct, not whether the dashboard is better.

Some organisations are doing this. They are rebuilding identity around continuous, behavioural, context-aware signals. They are treating infrastructure as immutable and disposable. They are integrating security into software supply chains rather than bolting it onto the exit. They are monitoring third-party risk as a continuous data stream rather than an annual form. What distinguishes these organisations is not budget, nor headcount, nor the particular vendor stack they’ve assembled. It is the presence of a coherent security architecture — a deliberate, documented strategy that sets direction, forces alignment across domains, and provides a rational basis for deciding what to do next. That architecture also manifests at the application layer: a reusable, modular framework that builds software from known-good components in known-good patterns, shrinking the vulnerability surface by design rather than by remediation. That practice is sorely lacking in most security departments, which tend to operate as a loose federation of tool-owning teams, each optimising locally, none responsible for the overall logic of the programme. Without architecture, you don’t have a security strategy. You have a collection of initiatives that happen to share a budget line.

These are not experiments. They are production practices in organisations serious enough to ask the harder question: not “how do we do this better” but “is what we’re doing the right thing at all?” And critically, they are organisations where the CISO has used the authority of the role to drive that architectural discipline beyond the security department — working with and through the CIO and Enterprise Architect to ensure that secure-by-design principles are adopted across IT, not merely advocated for from the outside.

The rest of the industry would benefit from asking the same question. Loudly, and without waiting another quarter century for the answer.

Joël Van Dyk is a cybersecurity architect and strategist with three decades of experience at systemically important financial institutions. He writes about enterprise security architecture, risk economics, and the transition to post-quantum cryptography at joelvandyk.com.