AI is changing cyber attacks. Your security cannot stand still.

A recent CNBC report carried a striking warning from Palo Alto Networks CEO Nikesh Arora: approximately US$1 trillion of cybersecurity infrastructure needs modernising to address AI-driven threats. That is his assessment, rather than a finding that every existing security product needs replacing. But it raises a question worth asking: are our systems, and the way we manage them, keeping pace?

It is my view is that New Zealand businesses should take this seriously without jumping straight to a new shopping list.

The priority is understanding which systems we depend on, where we are exposed, and whether we can respond quickly when something changes. Recent incidents involving websites, remote-support tools and firewalls show why that matters.

WordPress: when a website update becomes urgent

On 17 July 2026, WordPress released security updates addressing serious weaknesses in its core software. One vulnerability chain could allow an attacker to take control of an affected website without first logging in. The WordPress team considered the risk serious enough to enable forced updates through its automatic-update system.

There was a direct AI connection, but an important distinction: AI helped a security researcher find and report the weakness. Searchlight Cyber researcher Adam Kues described using an AI model to discover and develop the vulnerability chain, followed by human analysis and responsible reporting to WordPress. That is not evidence that AI caused the criminal attacks that followed.

Wordfence (A WordPress plugin) subsequently reported probing on the day of disclosure and substantial exploitation attempts from the following day. By its late-July report, its firewall had blocked more than 11 million attempts among the customers covered by its protective rule. Those were attack attempts, not 11 million compromised websites.

There is also a positive side to this example. Wordfence did not observe a corresponding surge in compromised sites and credited the coordinated response, including automatic updates and protective firewall rules. AI-assisted research helped defenders, and prompt action appears to have limited the damage.

For a business owner, the practical question is straightforward: who is responsible for your website’s security maintenance?

A website should not fall outside the security conversation simply because a separate agency built it. I would want the same clarity about its maintenance, updates and incident response that I expect for the rest of the business.

ScreenConnect: trusted support software, unexpected behaviour

In late August, Huntress investigated incidents across unrelated organisations where people had been tricked into installing attacker-controlled ScreenConnect clients. Researchers found modified clients that could pass malicious scripts to other systems connecting through ScreenConnect, creating what they described as worm-like behaviour. Huntress also described one script as likely generated by a large language model.

ConnectWise’s 3 September advisory acknowledged an issue affecting file-transfer behaviour in ScreenConnect support and access sessions, covering both cloud and on-premises deployments. The advisory reviewed for this article listed a fix in development and provided an interim mitigation involving file-transfer permissions.

For me, this illustrates two responsibilities. Vendors need to investigate and communicate promptly. Providers and customers need a process for acting on that guidance, including temporary restrictions while a permanent fix is being developed.

It also demonstrates why patching and incident response are different jobs. Huntress recommended rebuilding affected systems from known-good media because of the complexity of the activity it found. Closing an entry point does not automatically remove everything an attacker has already installed.

AI can also make familiar attacks more effective

Not every AI-assisted attack depends on a newly discovered software flaw.

In February, Amazon Threat Intelligence reported an attacker using commercial generative AI services to help compromise more than 600 FortiGate devices across over 55 countries between 11 January and 18 February 2026.

AWS did not observe exploitation of FortiGate software vulnerabilities in that campaign. Instead, the attacker took advantage of exposed management interfaces, weak credentials and single-factor authentication. AI helped the attacker apply familiar techniques at scale.

Updating a firewall is essential, but it does not compensate for leaving its administration interface unnecessarily exposed or protecting it with inadequate authentication.

The lesson is not that the fundamentals have stopped working. It is that we cannot afford to apply them inconsistently.

This is relevant to New Zealand businesses

New Zealand’s National Cyber Security Centre has already called for action. On 23 June, it joined its Five Eyes counterparts in warning organisations to prepare for increased vulnerabilities and incidents associated with advances in AI. Its message placed responsibility with business leaders as well as technical teams.

The underlying maintenance problem is not new. In its 2025 threat report, the NCSC identified delayed patching as a contributing factor in a significant proportion of its recorded high-impact incidents over the preceding five years. It also described attackers scanning exposed systems and exploiting them at scale.

A smaller organisation should not assume that an attacker needs to know its name first. Being reachable through vulnerable technology can be enough.

Keeping an environment current means more than updating laptops

When I talk about keeping systems current, I mean the whole environment and the responsibilities around it. There are four areas I would put in front of a business’s leadership team.

Know what needs maintaining, and who owns it

Start with the systems the business depends on: computers, servers, firewalls, websites, business applications, cloud services and remote-access tools.

The NCSC’s patching guidance emphasises maintaining an accurate inventory, assigning responsibility and tracking whether updates have actually been applied.

My recommendation is to make those responsibilities explicit across Layer3, your internal team and any specialist suppliers. A website agency may maintain the website. An application vendor may control updates to a business system. Your internal team may own particular devices.

What matters is that everyone knows where their responsibility begins and ends, and that nothing is left without an owner.

Give urgent security changes a faster approval path

Routine maintenance should be planned, tested and communicated. An actively exploited weakness in an exposed system may need a different timetable.

The NCSC recommends being prepared to accelerate the normal patching process for emergency updates and understanding the risk of delaying them.

That means agreeing in advance who can approve an urgent change, how staff will be notified and what temporary disruption the business can accept.

We should minimise downtime, but leaving a known exposure in place is also a decision with consequences. Sometimes a controlled interruption is the more responsible choice.

This is not an argument for installing every update without thought. It is an argument for matching the response to the risk, rather than automatically waiting for the next convenient maintenance window.

Plan for systems reaching the end of support

A replacement decision should not begin only when equipment fails.

The NCSC’s guidance calls for organisations to identify and plan upgrades or replacements before systems reach the end of support. That planning belongs alongside budgets and business priorities, not just on an engineer’s task list.

Where a system cannot be replaced immediately, I would expect a documented plan: what risk remains, what temporary protections are possible, who owns the decision and when the situation will be reviewed.

“It still works” is not, by itself, a security assessment.

Maintain the protections around the software too

Patching is one part of the answer. Reducing unnecessary internet exposure, strengthening access controls, monitoring for compromise and preparing to contain incidents are just as important.

This is also one of the reasons we use ThreatLocker application control in customer environments where it forms part of the agreed security service.

Rather than allowing any application to run simply because someone has been able to download or install it, application control restricts execution to software that has been approved.

We do occasionally get pushback when this blocks a legitimate application that has not yet been approved. But that friction is intentional.

If users can freely run any software they receive or download, an attacker has the same opportunity.

The recent ScreenConnect activity is a good example of why controlling what is allowed to execute on a device matters.

Application control is not a replacement for staff awareness, patching, endpoint protection or monitoring. It is another layer.

If someone is persuaded to install an unexpected remote-access tool, preventing that application from running can provide an important additional barrier before the situation becomes an incident.

For staff, my practical advice remains to use the agreed support channel and verify unexpected requests before installing software or granting remote access.

For management, it is to understand that some of the controls that occasionally create inconvenience are there specifically to reduce these risks.

The ScreenConnect and FortiGate examples are reminders that secure configuration, controlled access, application control and human decisions matter alongside the version number.

Vendors and IT providers need to be accountable

The scrutiny cannot stop at customers.

In February 2026, Microsoft published an investigation into attacks through internet-facing SolarWinds Web Help Desk installations. Those intrusions, observed in December 2025, enabled attackers to move beyond the help-desk application towards other valuable systems.

It is another reason to examine the security of the software used to support a business, not just the software staff use every day.

I expect vendors to invest in secure development, take credible reports seriously, communicate clearly and provide reliable fixes. Publishing an advisory is not automatically a sign of failure. How a vendor discovers, handles and resolves the problem is important.

Those expectations also apply to providers like Layer3. We should be (and are) clear about the systems we manage, the risks we identify, and the action required. Where responsibilities are shared, we need to make that arrangement understandable rather than assuming everyone has the same view.

The answer is a maintained environment, not just another product

AI does not make every vulnerability equally urgent, and we should not describe every incident as an AI attack.

What these examples show is the value of being able to identify a relevant threat, understand its impact and act. Sometimes that means an update. Sometimes it means restricting a feature, changing access arrangements, investigating suspicious activity or replacing a system that can no longer be maintained appropriately.

As CEO of Layer3, my priority is to help customers make those decisions with a clear understanding of the risk. That includes explaining what needs attention now, what can be planned and where a business decision is holding up an important improvement.

I would start with three questions:

1. Which systems need urgent attention?
2. Who is responsible for them?
3. What is preventing the work from being completed?

We do not need to panic. We do need to stop treating security maintenance as something that can always wait.

Speak with your Layer3 team about reviewing your outstanding security recommendations, upcoming support deadlines and arrangements for urgent changes.