AI makes cyberattacks more dangerous. Attackers use it to complete more work in less time and pursue more targets in parallel. Norwegian businesses must respond to that change by reducing the time between a warning and effective protection.
The response time must come down. A capable security team loses valuable time when it has to wait for an unanswered supplier ticket, a manager to approve downtime and the next maintenance window. Those delays belong to the business, not just the security department.
Installing security updates faster is essential. It is not enough. Management must also prepare for the interval before a fix exists: restrict the exposed service, stop the relevant attack path and keep essential work running through an approved alternative. If the attacker gets in first, the business needs controls that limit the damage and a recovery plan that has been tested.
My conclusion is clear: response capability must be built for faster attacks, with authority, access and protective measures ready before the next serious vulnerability becomes known.
Faster attacks are already documented
In a study published on 8 June 2026, Anthropic tested known Firefox vulnerabilities using public patches and prepared test environments. It reports that Mythos Preview developed code-execution exploits for eight of 18 flaws, with the first in under an hour. This was a retrospective, vendor-run evaluation of a standalone JavaScript engine, not a full browser or an internet campaign. Successful timings selected the fastest trials. It demonstrates capability under those conditions, not a universal one-hour attack deadline.
There is also evidence outside the laboratory. Anthropic's September 2026 misuse report describes selected campaigns from December 2025 to August 2026 in which intrusions took two to three hours and individual operators handled dozens of victims in parallel. Humans still made important decisions. These are the provider's investigated cases, not a representative survey or an independent measurement of AI's causal effect.
The wider picture needs the same care. Google Threat Intelligence Group's 30 September analysis recorded an average of 18 newly disclosed vulnerabilities with observed exploitation per month in January to August 2026, against 10.5 in 2025. It points particularly to exploitation of known flaws. Those are counts of distinct vulnerabilities, not attacks or victims; observation limits and disclosure patterns matter. The figures do not establish how much of the increase AI caused.
These findings show why the operating assumption must change. AI accelerates parts of the work between identifying a weakness and exploiting it, and supports parallel operations. Human involvement does not preserve a comfortable response window for defenders. Management must remove avoidable delays now, rather than wait for fully autonomous attacks.
Three situations that require different responses
Zero-day exploitation means using a vulnerability before a fix is available, often before the supplier knows about it. Terminology varies, but the business distinction is straightforward: can the supplier provide a supported correction now?
There are three situations management must prepare for:
| Situation | Required preparation and response | Unsafe assumption |
|---|---|---|
| The flaw is still unknown to defenders | Reduce exposed functionality, restrict access, separate services and prepare detection and recovery | That every unknown flaw can be recognised or blocked |
| A serious flaw is known, but no usable fix is available | Apply relevant, validated mitigations, restrict or suspend the affected function and investigate suspected compromise | That waiting for the supplier leaves the service acceptably protected |
| A fix exists, but has not reached all deployed systems | Test and deploy through an urgent process, verify coverage and follow up exceptions | That a downloaded update or closed ticket means the service is corrected |
An excellent patching process cannot install a nonexistent patch. Before the first warning, protection depends on decisions already made about architecture and access. After a warning, management must assess immediate containment instead of treating the absence of a patch as a reason to wait.
For the concrete Node.js releases from 21 October, the separate update guide identifies versions and deployment checks. The decision here is broader: how does the company protect an exposed service and keep operating while a permanent fix is unavailable or incomplete?
One security flaw creates targets across many businesses
The same vulnerable software component is often present in many businesses. A reliable exploit against a common, internet-accessible configuration gives attackers a method to reuse across those targets. AI reduces parts of the specialist work involved in preparing and running repeated attacks. The business consequence is greater pressure on every exposed installation, including those whose owners would previously have seemed too small to interest a skilled attacker.
Several conditions must coincide: the vulnerable code must be reachable, the exploit must work reliably across relevant versions, the attacker must find targets and execute at scale, and protections must fail or be absent. Scanning an address, identifying a vulnerable version and successfully stealing data are different outcomes. One domain can host several services, and one service can support many domains. A website count is therefore a poor substitute for a verified count of compromises.
Automation at large scale also predates generative AI. NIST's June 2017 testimony on WannaCry described more than 230,000 affected computers across over 150 countries and automatic spread. Microsoft had issued the relevant patch in March, before the May outbreak. The case shows the potential of automated reuse; it is not evidence of AI-driven zero-day exploitation.
The strategic change is the economics of attack. As the work per target falls, smaller gains become worth pursuing. A Norwegian company does not need to attract weeks of a specialist's attention to suffer a serious breach. It only needs to be one exposed target in a repeatable operation.
That is why mass exploitation belongs in continuity planning now. Claiming that AI will compromise millions of services within a particular period would go beyond the evidence. Waiting for such a victim count before improving response would be a serious management mistake.
A response measured in minutes requires decisions made beforehand
The bottleneck is often larger than the cybersecurity team. Someone must identify the affected service, reach the person with access, decide what disruption is acceptable, obtain a supplier change and verify the result. Hiring faster analysts will not remove a process that still requires the chief executive to approve every precaution on a Friday evening.
Australian government guidance published on 6 July 2026 explicitly asks executives and boards to consider greater tolerance for brief outages caused by rapid remediation. It also recommends narrowly scoped, pre-approved and reversible automated responses. Its audience is government, critical infrastructure and large enterprises. The underlying trade-off is useful for Norwegian businesses, but this is foreign guidance, not a Norwegian legal obligation.
Management must decide in advance which actions the on-call team is authorised to take without fresh business approval. Depending on the service, those actions include suspending one integration, restricting a public administrative interface or putting a portal into a safe maintenance mode. Define the trigger, permitted scope, accountable owner, customer consequences and conditions for reopening.
Do not grant a general instruction to shut down everything. An untested action can interrupt production, create safety problems or prevent staff from serving customers. The right action depends on the service and must be prepared with the people responsible for operations. Where a safe shutdown is difficult, the case for removing unnecessary exposure and improving separation beforehand becomes stronger.
If an important service runs around the clock, its urgent decision route must also work outside office hours. For a small AS, start with a clear agreement with its existing provider and a business contact with authority. It does not require the company to build its own security operations centre. It does require knowing what happens when the normal contact is unavailable.
The interval before a patch is available
Consider a hypothetical Norwegian professional-services company with a portal for confidential customer documents. On Friday afternoon, its provider warns of a serious vulnerability in the portal software. No supported fix is available. The provider cannot yet establish whether the company's configuration exposes the flaw.
Before that warning arrives, management must establish whether external portal access is safe to suspend and prepare an approved alternative for exchanging necessary documents. Define which integrations must pause, what message customers receive and who has authority to act. The alternative must preserve confidentiality and traceability; moving documents into ordinary, unapproved email is not automatically a safe fallback.
The technical team must assess which temporary controls address the actual attack path. A web application firewall rule may help with some requests and miss others. An identity control may reduce exposure for one flaw while doing little against another that can be triggered before login. A protective measure needs a stated scope and a check that it is active.
This is a hypothetical decision exercise, not a claim that portal shutdown is always necessary. Its purpose is to expose the business choice before the warning arrives: how much interruption will the company accept to reduce an uncertain but serious risk?
Once there are signs of intrusion, vulnerability remediation and incident response must proceed together. NSM's incident-handling checklist, updated on 19 October 2026, advises isolating affected systems while leaving devices powered on, activating prepared plans and obtaining expert help. A patch alone does not remove stolen credentials, persistence or data already taken. Follow the incident team's plan for preserving evidence and reopening services.
Make one compromised service less useful to an attacker
Prepare for an attacker gaining access to one service. The business must limit what that initial access gives them, even while the cause is still being investigated.
A document portal does not need permission to administer the company directory, read unrelated customer databases or alter backups. Giving its technical account those permissions makes one breach unnecessarily damaging. Remove unnecessary access and separate accounts and services. Verify that the portal still performs its legitimate task within those narrower boundaries.
Ask the team to demonstrate those boundaries in an authorised exercise. Can the service reach systems it has no business using? Can its account change the recovery copies? Will security records remain available if the service is compromised? Test a realistic customer workflow after tightening access so that improved protection does not silently break delivery.
Recovery must cover the business service, including identities, integrations and trustworthy data. A backup that has never supported a successful restoration leaves a major uncertainty. Decide which work can continue manually and how it will be reconciled when normal operation returns.
These measures reduce the damage from a compromised service. They are not a guarantee against every unknown flaw. They make resilience a property of the wider system, rather than a hope that one exposed application will always remain secure.
Use AI to shorten defensive work, with verifiable results
Use AI to shorten defensive work as well. Start with bounded tasks: comparing a supplier notice with an asset inventory, preparing a proposed configuration change, drafting regression tests and organising incident evidence. Require measured time savings and results that the team can check.
In its 21 October account of the PHP vulnerability response, OpenAI says AI-assisted discovery gave maintainers and providers time to coordinate fixes and protections before disclosure. It says, to its knowledge, defenders found the flaws before attackers. This is the provider's account, not proof that all systems were protected. The case illustrates a defensive lead from AI-assisted discovery. That is a reason to invest in verified defensive use, alongside faster response.
Measure your own result. Did the tool identify the affected services accurately? Did the proposed change pass testing? Was the production state independently verified? Keep the scope of automatic action tied to demonstrated reliability and potential consequence. A completed tool action is not proof of protection. Verify the resulting production state.
NSM's established advice is to install security updates quickly, centrally and as automatically as possible. Its five measures chiefly concern user devices. Keep routine updating reliable and strengthen the urgent route for exposed services. Ordinary updates should not need a new approval meeting each time.
Ask for elapsed time and remaining exposure
A promise to respond to a ticket within an hour can mean only that someone acknowledges it. Management needs to distinguish that from a change that actually reduces risk.
A credible warning of active exploitation against an exposed service must trigger the urgent process immediately. Assign an owner and assess the protective action without waiting for the next maintenance meeting. The response must start in minutes. Completing a safe fix depends on the service and the available remedy; those constraints make prepared containment more important.
For every serious alert, record when it was received, when the affected services were identified, when the protective action became effective and when the permanent correction was verified. Show the systems still exposed, including those outside the main provider's contract. An excellent average can conceal the one internet-facing system that nobody owns.
Set service-specific targets using business consequence, exposure and the actions available. Exercise them against a case with no patch, an unavailable supplier contact and a failed deployment. There is no single public statistic that supplies a safe universal deadline for all systems. If the exercise needs hours just to identify an owner, that is an actionable gap regardless of the eventual exploit timeline.
The board's choice is what the organisation is prepared to tolerate
Management must bring a concrete proposal: which important services need a faster response, which temporary interruptions it seeks authority to accept, where supplier terms are inadequate and what investment will reduce the longest delays. The board must challenge material risk, resources and evidence that the arrangement works. It should not select individual firewall rules or approve every patch.
The UK NCSC's assessment to 2027 warned in 2025 that AI would shorten exploitation timelines and improve skilled actors' zero-day capabilities. It expected humans to remain involved in advanced attacks and judged fully automated execution from end to end unlikely by 2027. That was a forecast, not a ceiling on capability. The presence of a human operator does not give the defending company time for a slow approval chain. Management must plan around observed attack speed and revise those plans as capabilities develop.
For the next management meeting, choose one important internet-facing service and ask: If its supplier warns of a serious flaw tonight and has no patch, who can reduce exposure, what can they do, and how will we know it worked? Use the board reporting guide to record the unresolved business risk, and the guide to the chief executive's incident decisions if compromise is suspected.
AI makes cyberattacks more dangerous. The answer is faster, verified patching and a business prepared to contain exposure before a patch exists. Give the team clear authority, test the protective actions and measure the time until they work. Response speed is an operating requirement, not a task to postpone until the next incident.
Sources checked on 23 October 2026. The document-portal company is hypothetical. Mass exploitation is discussed as a conditional scenario, not a prediction of a particular number of victims or a date. Management recommendations and the proposed measurements are the author's analysis. The illustration is AI-generated.