TL;DR: The 2026 Microsoft Digital Defense Report says AI is making attacks faster, cheaper and more automated. The critical PHP vulnerabilities of late October 2026 showed what that looks like in practice, and the work that followed was the same as it has always been. Find it, own it, patch it. AI changes the pace of security. It doesn’t change the fundamentals, which is exactly why ASD Essentials arriving now is worth paying attention to.
October is Cyber Security Awareness Month, so naturally I have spent part of it thinking about artificial intelligence, autonomous agents, increasingly sophisticated cyber attacks and the future of technology. I have also spent part of it dealing with PHP. The timing is almost too good.
In late October 2026, two critical vulnerabilities in PHP were disclosed, CVE-2026-109618 and CVE-2026-109619, with patches released across the currently supported branches. The vulnerabilities allow unauthenticated remote code execution in affected environments, which is about as much fun as it sounds. ASD’s ACSC advised organisations to identify where PHP exists, apply the available security updates and monitor the associated applications and systems for suspicious activity (cyber.gov.au). The standard response to major vulnerabilities.
Then there was the detail that made me laugh, slightly nervously. According to Snyk’s write-up, the bugs were found with AI assistance “in a runtime that has been in production for three decades.” A brand new way of finding old problems, in software a good chunk of the internet was quietly depending on long before I ever logged my first support ticket.
Anyone who’s spent time looking after enterprise technology can probably predict what happened next.
Find the PHP.
Find who owns the PHP.
Find out which version of PHP we’re running.
Find out whether it can actually be patched.
Find out whether the application sitting on top of it will survive being patched.
Find the person who knows why it was built that way in the first place.
Then discover that they left three years ago.
I exaggerate slightly on the last one. Although probably not by much.
What struck me wasn’t that we had another nasty vulnerability to deal with. It’s practically expected these days, and based on the direction of travel over the past few years, nobody running technology should be expecting that problem to get smaller. What struck me was how eerily familiar the actual work felt. For all the talk about AI-driven attacks, AI-assisted vulnerability research and increasingly autonomous security operations, when something serious lands we still end up asking some fairly boring questions, and it’s people, not AI agents, who have to do a lot of hard work in a short amount of time.
What do we have?
Where is it?
Who owns it?
Is it supported?
Can we patch it?
What will break if we do?
Why wasn’t this already being managed?
And, occasionally, why did someone ignore the process and go chasing the new shiny thing while this sat quietly in the corner? That last question generates some interesting discussions in meetings.
What the Microsoft Digital Defense Report is really telling us
Microsoft released its 2026 Digital Defense Report at the start of October, and the headline is that “AI is changing the physics of cybersecurity.” That’s a big claim. Having worked through it, I think the evidence mostly supports it.
Attack timelines are compressing. Nearly 40,000 CVEs were published in the first half of 2026, putting the year on track to roughly double, and Microsoft says AI is compressing parts of the attack chain from days to seconds. Over the past six months they’ve watched the threat landscape shift from AI assisting human operators, to AI directing attack activity, and on toward autonomous execution. To be fair to the report, it’s also careful to say that most complex real-world intrusions still involve meaningful human direction. The change is that work which used to need scarce expertise can increasingly be accelerated, repeated or handed to AI.
The number that stuck with me was the gap. The median time from a vulnerability being discovered in the wild to being weaponised has fallen to well below 24 hours, while enterprise remediation for critical external vulnerabilities can still take 30 to 60 days. Read those two numbers next to each other, then think about how long your last “find the PHP” exercise took.
The part of the report I’d encourage people to actually read is the bit that gets fewer headlines. Microsoft is quite direct that AI doesn’t erase the security lessons of the past decade. In many cases it just makes familiar weaknesses easier to exploit and easier to scale. User execution accounted for 30% of observed initial access, and valid accounts another 20%. Among detections tied to the five leading CVEs analysed in the report, 58% were associated with a single vulnerability first disclosed in 2020, CVE-2020-1472. Zerologon, for those of us who remember patching domain controllers in a hurry.
The report also makes the point that AI can make a weakness easier to find, but it can’t turn a well-governed identity into an overprivileged one, or expose a service that was never exposed in the first place. I’d happily put that on the wall of most operations teams. The acceleration is real. The paths it accelerates are mostly ones we already know about.
We keep confusing new implementations with new fundamentals
I’ve mentioned before that I have a slightly unfashionable view of modern infrastructure. A few months ago I raised some eyebrows by suggesting that networking hasn’t fundamentally changed that much since the 1990s. There are several network engineers currently preparing angry emails, so I’ll qualify that before they send them.
Of course networking has changed. We’ve virtualised it, automated it and distributed it. We have software-defined networks, hyperscale cloud environments, network virtual appliances and far more sophisticated approaches to segmentation, routing and security. The scale and operational complexity have changed enormously.
But an IP address is still an IP address. DNS still resolves names, a route table still tells something where to go, and firewalls still permit or deny traffic. Network Address Translation is still Network Address Translation. And the packet, blissfully unaware of our architecture diagrams, still needs to get from one place to another.
Servers went the same way. A Windows Server running in Azure does not become fundamentally different because nobody can point at the physical machine underneath it. It still has an operating system that needs patching, identities accessing it, logs it produces and a network it talks over. It might live in an Azure region rather than the poorly ventilated cupboard masquerading as a server room on the third floor, but many of the operational principles have survived the move.
Cloud wasn’t important because it invented computing again. It changed how we consumed it. We moved from hardware procurement, manual provisioning and long lead times towards APIs, infrastructure as code, elastic capacity, consumption models and workloads that could be deployed in minutes. Those are enormous changes. They just didn’t make infrastructure disappear. This distinction between new implementations and new fundamentals is increasingly how I think about AI as well, and it’s more or less what the Digital Defense Report is saying, with a great deal more telemetry behind it.
AI makes an awful lot of things faster
I have no interest in joining either side of the AI argument. The “AI will solve everything” crowd are exhausting. So are the people determined to prove it’s an overgrown autocomplete engine with no meaningful application to their work. My own experience sits somewhere considerably less exciting. AI is extraordinarily useful.
The mental model I’ve settled on is that we have suddenly given almost everybody access to a very capable collection of researchers, analysts, junior developers, administrators, architects and technical writers. Ask it to explain an unfamiliar technology and it probably can. Give it some PowerShell to review and it’ll probably find something useful. Ask it to summarise a hundred pages of documentation and you’ll get a reasonable starting point before you’ve finished making coffee.
Give it a defined process, decent documentation, appropriate tools and sensible guardrails and it becomes even more interesting. That’s where agents start to move beyond answering questions and into doing useful work. None of this is trivial, but I keep coming back to one problem. How do you know when it’s wrong?
I had this discussion with an engineering leader recently, and his view was that the people getting the most from AI tend to know both when to use it and when not to use it. I’ve been thinking about that ever since, because I suspect it describes the real capability gap rather well. Producing the output is getting easier. Judging the output isn’t.
If Copilot gives an experienced identity engineer a Conditional Access policy, they’ll probably notice when an exclusion creates an obvious hole. If it generates a PowerShell script for someone who has spent years administering Active Directory, that person will probably recognise when it’s about to do something exciting to 20,000 user accounts. A network engineer reading an AI-generated configuration has a mental model of what the packet will actually do. They aren’t just reading syntax, they’re comparing the output against years of experience, and that’s a very different thing.
Experience is mostly scar tissue
There has been an interesting argument floating around for a while that AI will remove much of the need for mid-level technical capability. Junior engineer plus AI apparently equals senior engineer. I’m not convinced.
A junior engineer with AI may well produce work significantly faster than a junior engineer without it. They may learn faster too, which I think is one of the more interesting opportunities AI gives us. But access to an answer isn’t the same as knowing why the answer is right.
Much of what we call experience in technology is really a collection of failures we’ve accumulated over time. We’ve seen DNS cause a problem that didn’t look remotely like DNS. We’ve watched a certificate expire somewhere nobody knew certificates existed, changed the thing that definitely couldn’t affect production immediately before it affected production, and discovered that the “temporary” firewall rule added six years ago is now apparently critical infrastructure. Experience is partly understanding technology, but it’s also knowing where the bodies tend to be buried.
AI can accelerate someone’s access to knowledge. I’m considerably less convinced that it can shortcut all of that judgement, which is why mentoring becomes more important rather than less. If we’re going to give junior engineers tools capable of producing senior-looking work, we also need to make sure we’re still teaching them how systems work, how to troubleshoot, how to test assumptions and, perhaps most importantly, how to recognise when they don’t understand something well enough yet. Otherwise we’ve solved the wrong problem. We’ve made people faster without necessarily making them better, and fast mistakes remain mistakes.
This is really a systems-thinking problem
The skill I’ve found most transferable throughout my career isn’t knowing a particular Microsoft product, networking platform or cloud service. It’s troubleshooting, and more specifically, fault isolation.
- What is this system actually trying to do?
- What does it depend on?
- Where does information enter?
- Where is it supposed to go?
- What happened immediately before it failed?
- Where did the process stop?
- What evidence do I have?
- What am I assuming?
Those questions worked when I was on a support desk in 2011, chasing Windows Server 2008 R2 and Exchange 2010 problems. They work in Active Directory, Azure, AWS, Kubernetes and Entra ID, and they work with APIs and Databricks. Rather annoyingly, they also work with AI agents. The products change constantly, but systems thinking travels rather well.
This is also why I worry about organisations outsourcing too much of the thinking to “the AI”. Not because AI shouldn’t be used to reason through a problem, I use it for exactly that. The risk comes when the human stops having a sufficiently good mental model to challenge the reasoning. You’ve outsourced the task and accidentally outsourced the judgement with it.
The vulnerability is technical, the scramble isn't
None of this is limited to AI. We spend enormous amounts of time discussing the sophistication of future attacks while continuing to create opportunities through basic operational failures. The Defense Report’s own data says as much, and anyone who has worked through an incident will recognise the list.
Asset inventories that aren’t quite current.
Systems that don’t have a clear owner.
Legacy applications nobody wants to touch.
Overly broad privileges.
Credentials that should have been changed years ago.
Logs nobody looks at.
Patches that can’t be deployed because nobody is confident about what they’ll break.
None of those problems are particularly interesting in isolation. Together, they account for an uncomfortable amount of risk.
The PHP scramble of late October was another reminder of the same thing. The vulnerabilities themselves are serious, and the official ASD’s ACSC PHP advisory specifically told organisations to identify PHP within their environments (cyber.gov.au). That first word, identify, is doing more work than it looks.
Before you patch the vulnerable technology, you have to know you have the vulnerable technology. Before you know that, someone needs to understand what they own. Then you need to know who operates it, whether it’s supported, what depends on it and what happens when you change it. And with weaponisation now measured in hours rather than weeks, you need to be able to do all of that quickly.
Suddenly we’re not talking about PHP. We’re talking about asset management, service ownership, lifecycle management, change management and operational discipline. The vulnerability is technical. The scramble around it often isn’t.
"Move it to cloud" isn't lifecycle management
There’s another uncomfortable part of this that comes up reasonably often. Technology organisations like new things. Engineers like building. Projects like transformation. Budgets are considerably easier to find for a cloud migration than for spending three months cleaning up configuration, documentation and ownership for something everybody already has.
I understand why. Building something new has a visible outcome, while preventative maintenance mostly produces the exciting outcome of nothing happening.
But moving a poorly understood workload into cloud does not suddenly make it well understood. Putting a legacy application behind a shiny cloud service doesn’t establish ownership. Migrating a neglected server doesn’t create a lifecycle plan, and adding an AI security tool doesn’t fix an application that can’t be patched. You can automate a poor process quite successfully. Now you just have a poor process operating at cloud speed.
There is a temptation with every technology cycle to believe that the next abstraction will finally free us from maintaining the boring layer underneath. It never quite works. Cloud abstracted infrastructure, SaaS abstracted applications, managed services abstracted platforms, and AI is beginning to abstract expertise. But abstraction is not elimination. Someone somewhere is still operating the thing, and someone in your organisation still owns the decision to depend on it.
What Cyber Security Awareness Month left me with
Maybe that’s what I’ve taken from Cyber Security Awareness Month this year. We’re entering a period where technology is going to become remarkably capable. AI will help discover vulnerabilities, it will help attackers exploit them, and it will help defenders analyse and patch them. Agents will automate increasingly complex operational processes. I expect all of that to continue, and the Defense Report suggests it’s happening faster than most organisations have planned for.
But after the agent has finished reasoning, something still needs an identity. It still needs permissions, and its actions still need logging. Someone needs to know what it’s allowed to do, what happens when it’s wrong, and who owns the systems it’s interacting with. Microsoft makes the same point from the other direction, warning that an AI agent with excessive permissions can create a new path to data, applications or infrastructure, and that as agents are given more autonomy, teams will need to watch for models taking actions that diverge from what their operators intended. That isn’t a new class of control. It’s identity, least privilege and logging, applied to a new kind of user.
And when the next critical vulnerability lands, possibly in the early hours of a Thursday morning as this one did for those of us in Australia, we’re still going to need to know where the affected software is running and whether we can safely patch it. None of that is cutting edge. Most of it would have been recognisable to a competent system administrator twenty years ago.
We’ve spent a lot of this technology cycle talking about how AI will change the work. I think it will, and I’m already seeing it happen. What I don’t think it changes is the need to understand the systems we’re operating. If anything, making technology faster increases the cost of not understanding it.
Which brings me to ASD Essentials
The timing of the new ASD Essentials is interesting in this context. On 15 October 2026, the Australian Signals Directorate launched ASD Essentials as the evolution of the Essential Eight. The initial chapters cover enterprise IT, operational technology and cloud, with AI-focused guidance also available. ASD describes the framework as a way to strengthen cyber defences and protect critical business functions while aligning security with an organisation’s operational requirements and risk profile (asd.gov.au).
What interests me isn’t that ASD has produced another security framework. We have frameworks. Lots of frameworks. My concern with frameworks has never been that they’re bad, because they’re useful ways of organising thought, identifying gaps and creating common language. The risk is when passing the framework becomes the objective.
ASD’s transition guidance reinforces something more useful. Existing Essential Eight investment isn’t being thrown away, but the controls are being assessed differently, and in some cases applied more broadly. The guidance explicitly maps the old controls into the new framework and asks organisations to consider where existing controls are sufficient and where they need strengthening (cyber.gov.au, cyber.gov.au). Restricting Microsoft Office macros, for example, now contributes to a broader principle around trustworthy software, so your existing macro controls still count, they just answer part of a bigger question. Assets and functions are also grouped into domains with similar risk characteristics, which means a control that works well in one part of the environment might only be partially effective in another. That’s a far more honest way of measuring it.
I like that. Not because a new framework magically solves cyber security, because it doesn’t, but because it acknowledges reality. Enterprise IT isn’t the same as OT. Cloud isn’t simply a data centre in someone else’s building. AI introduces different considerations. The implementation changes, while the objectives and responsibilities remain recognisable, which is the same new implementations versus new fundamentals argument I started with.
For organisations running critical infrastructure this becomes particularly important. An energy operator isn’t implementing cyber controls because MFA is inherently virtuous. A hospital isn’t monitoring systems because logs are nice to have. A water utility doesn’t segment networks because an architecture standard says diagrams look better with more coloured boxes. Those things support something larger, which is keeping the service operating, protecting the critical function, knowing what happened when something goes wrong, and recovering when eventually something does.
Cyber security is part of resilience, and that’s much more useful than treating compliance as the destination. One practical note while everyone works out what this means for them. Until regulators communicate changes, ASD’s advice is to keep meeting your current regulatory obligations, and both the Essential Eight and the Essentials will be maintained during the transition period. Nobody needs to tear up their maturity assessment this week.
Over the next few posts I’m going to work through ASD Essentials chapter by chapter, with the same lens I’ve used here. I’ll start with enterprise IT and what genuinely carries over from an Essential Eight program, then move on to operational technology and what it means for critical infrastructure operators, then cloud for organisations running mostly on SaaS and PaaS. I’ll finish with ASD’s AI considerations, and how they apply to agents that need identities, permissions and logging like everything else.
So by all means use AI. Build agents, automate the patching, move appropriate workloads to cloud and use the new framework. Just don’t confuse any of those things with doing the fundamentals well. After all the investment, automation, transformation programs and increasingly intelligent tooling, this Cyber Security Awareness Month still managed to give us a week where organisations around the world were told to go and find their PHP servers and patch them. There is something wonderfully grounding about that.
The tools keep getting smarter. The basics keep turning up for work.
