Most companies know they need to install security updates.
The difficult part is making it happen properly.
A business may have servers, employee laptops, cloud applications, websites, firewalls, remote access tools and third-party software. Each system may receive different updates at different times.
Some patches can be installed quickly.
Others require testing.
Some systems cannot be restarted during business hours.
Some applications are so old that an update may break them.
Now artificial intelligence is adding another layer to the problem.
Advanced AI systems are becoming capable of reviewing large amounts of software and infrastructure to identify vulnerabilities. This could help defenders find weaknesses earlier. It could also give attackers a faster way to discover systems that have not been properly secured.
On 14 July 2026, the United States announced plans to bring AI developers and essential service providers together in a new cybersecurity coordination group. The purpose is to share information about vulnerabilities discovered by advanced AI systems and coordinate how those weaknesses should be addressed.
This is not only a government or critical-infrastructure issue.
It points to a wider problem for businesses:
Finding vulnerabilities is becoming easier. Fixing them properly is still difficult.
What Is the New AI Cybersecurity Group?
The new coordination group is designed to connect companies that develop advanced AI systems with organisations providing essential services.
These services include areas such as finance, healthcare and energy.
According to Reuters, AI developers and service providers will be able to share information about software and infrastructure weaknesses discovered by AI systems. The aim is to prevent duplicated work and coordinate responses before attackers can take advantage of those weaknesses.
The move reflects growing concern that AI can identify security vulnerabilities at scale.
Security researchers may use this capability to improve protection.
But malicious actors may try to use the same technology to find an easier way into critical systems.
That creates a race.
One side is trying to discover and fix the problem.
The other side is trying to exploit it first.
Why AI Changes Vulnerability Management
Traditional vulnerability management already produces a large amount of information.
A normal vulnerability scan may identify:
- Missing security updates
- Outdated operating systems
- Unsupported applications
- Weak configurations
- Exposed network services
- Unnecessary open ports
- Old web plugins
- Insecure encryption settings
- Known software vulnerabilities
- Default or weak credentials
The difficult part is not producing a long report.
The difficult part is deciding what to do next.
AI may make scanning and analysis faster. It may help review more code, detect unusual patterns and connect information from different systems.
However, more findings can also create more noise.
A company may suddenly receive hundreds or thousands of alerts.
Without a proper process, the security team may struggle to identify which findings require immediate action.
That is why AI does not replace vulnerability management.
It makes good vulnerability management more important.
Not Every Vulnerability Carries the Same Risk
One of the most common mistakes is treating every vulnerability equally.
A security scan may label several findings as critical or high risk. But the actual business risk depends on context.
For example, a vulnerability affecting an internal test server may not carry the same risk as one affecting a public customer portal.
A weakness that requires physical access may not be as urgent as one that attackers can exploit remotely through the internet.
A vulnerability may be more serious when:
- The affected system is accessible from the internet
- Attackers are already exploiting it
- The system contains sensitive data
- The system supports critical business operations
- No additional security control is protecting it
- The affected software is old or unsupported
- The system uses a privileged account
- The vulnerability allows remote code execution
- The system is connected to other important infrastructure
Businesses therefore need risk-based prioritisation.
The goal is not simply to close the largest number of findings.
The goal is to reduce the most serious business risk first.
Start With What Attackers Are Already Exploiting
A vulnerability may be technically serious, but that does not always mean attackers are actively using it.
At the same time, a vulnerability with a lower technical score may already be widely exploited.
That is why businesses should not rely only on severity scores.
The US Cybersecurity and Infrastructure Security Agency maintains a Known Exploited Vulnerabilities catalogue to help organisations identify vulnerabilities that have evidence of active exploitation. CISA recommends using this information as part of vulnerability prioritisation.
This gives businesses a more practical starting point.
Review vulnerabilities that are:
- Already being exploited
- Exposed to the internet
- Connected to critical systems
- Able to provide administrator-level access
- Affecting sensitive or regulated data
These should normally receive attention before less urgent findings on low-impact systems.
Your Asset Inventory Comes First
A business cannot protect systems it does not know it has.
This sounds obvious.
In practice, many companies do not have a complete technology inventory.
An old virtual machine may still be running.
A test website may still be accessible.
A former vendor may still have remote access.
An old firewall may no longer receive updates.
A forgotten WordPress installation may still contain vulnerable plugins.
A cloud server may have been created for a temporary project and never removed.
These forgotten systems can become easy entry points.
Before improving patch management, businesses should know:
- What servers they operate
- What operating systems are installed
- What business applications are being used
- Which websites and portals are public
- Which cloud services are connected
- Which devices can access company data
- Which network and security appliances are deployed
- Who owns each system
- Whether the software is still supported
- Whether each system is business-critical
A reliable inventory gives the company a clear starting point.
Without it, vulnerability scanning will always be incomplete.
Internet-Facing Systems Need Faster Attention
Any system that can be reached from the internet carries additional risk.
Examples include:
- Company websites
- Customer portals
- Web applications
- VPN gateways
- Remote desktop services
- Email servers
- Cloud management portals
- Firewall interfaces
- API endpoints
- File transfer services
- Public databases
These systems are easier for attackers to find and test.
Automated tools can scan large parts of the internet looking for outdated or poorly configured systems.
AI may make this process even faster and more targeted.
Businesses should maintain a clear list of internet-facing systems and review them regularly.
Unnecessary services should be disabled.
Administrative interfaces should be restricted.
Multi-factor authentication should be enabled where supported.
Unsupported systems should be upgraded or replaced.
Patching Should Be Treated as Preventive Maintenance
Companies normally understand the importance of maintaining physical equipment.
Vehicles need servicing.
Air-conditioning systems need maintenance.
Fire extinguishers need inspection.
Electrical equipment needs testing.
Software also needs maintenance.
NIST describes enterprise patch management as the process of identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades. It frames patching as preventive maintenance that can help reduce compromises, data breaches and operational disruption.
This is a useful way for management to look at it.
Patching is not an unnecessary technical interruption.
It is part of keeping business systems reliable and secure.
Postponing every update because downtime is inconvenient may eventually create a much larger disruption.
A controlled maintenance window is usually easier to manage than an emergency response after a breach.
Why Companies Delay Security Updates
There are valid reasons why some patches are not installed immediately.
A business may worry that the update will:
- Restart a production server
- Cause application compatibility issues
- Interrupt customer access
- Affect database performance
- Break an old business application
- Require vendor assistance
- Remove a custom configuration
- Create unexpected downtime
These concerns should not be ignored.
Patches can cause problems when installed without planning.
But delaying indefinitely is not a safe solution either.
A better process is to assess the risk, test where possible and schedule the update based on urgency.
For a serious internet-facing vulnerability that attackers are already exploiting, the company may need emergency action.
For a lower-risk internal system, the patch may be installed during the next maintenance window.
The response should match the risk.
Installing the Patch Is Not the Final Step
Another common mistake is assuming that clicking “install” completes the work.
A patch may fail.
The device may not restart properly.
The update may be rolled back.
The software version may remain unchanged.
A cluster may contain several servers, but only some may receive the update.
A remote employee’s laptop may not have connected to the management platform.
This is why verification is essential.
After patching, the company should confirm:
- The correct update was installed
- The system restarted successfully
- The application is functioning normally
- The vulnerability is no longer detected
- Security services are still operating
- Monitoring has resumed
- Backup remains available
- No unexpected configuration changes occurred
NIST includes verification as a core part of enterprise patch management, not an optional extra.
A patch that was scheduled but never successfully applied still leaves the company exposed.
What If a Patch Is Not Available?
Sometimes a software vendor has not released a fix.
In other cases, the system cannot be patched immediately because it supports an important business process.
That does not mean the company should do nothing.
Temporary controls may reduce the risk.
These can include:
- Blocking vulnerable services at the firewall
- Restricting access to approved IP addresses
- Disabling the affected feature
- Isolating the system from other networks
- Increasing security monitoring
- Removing public internet access
- Applying a vendor-provided workaround
- Requiring VPN access
- Limiting user privileges
- Replacing the affected application
These measures do not always remove the vulnerability.
They can reduce the chance that attackers will reach or exploit it while the company prepares a permanent fix.
The workaround should also have an owner and an expiry date.
Temporary controls have a habit of becoming permanent when nobody follows up.
Vulnerability Scanning and Penetration Testing Are Different
Businesses sometimes treat vulnerability scanning and penetration testing as the same service.
They are not.
A vulnerability scan uses automated tools to identify known weaknesses, missing updates and insecure configurations.
A penetration test involves authorised security professionals attempting to exploit weaknesses and demonstrate how an attacker could move through the environment.
Vulnerability scanning is useful for regular monitoring.
Penetration testing provides deeper validation at selected intervals or before important launches.
A company may need both, depending on the systems involved and its risk level.
For example:
- Monthly or quarterly vulnerability scanning may identify new weaknesses.
- Penetration testing before a website or system goes live may identify exploitable design problems.
- Retesting after remediation confirms whether important weaknesses were properly fixed.
Neither service replaces daily security management.
A penetration test conducted once a year cannot protect an unpatched server for the remaining eleven months.
Who Should Own Patch and Vulnerability Management?
The technical team may carry out the work.
But ownership should not remain unclear.
A practical responsibility structure should define:
- Who maintains the asset inventory
- Who runs or reviews vulnerability scans
- Who evaluates business impact
- Who approves emergency maintenance
- Who communicates downtime
- Who tests the update
- Who confirms successful installation
- Who accepts the risk if patching is delayed
- Who reports progress to management
Business owners and department leaders may need to be involved when a patch affects an important service.
For example, IT may identify an urgent vulnerability on the accounting server.
Finance understands when the system can be taken offline.
Management decides whether emergency maintenance is justified.
The vendor may need to confirm application compatibility.
Patch management works best when responsibility is shared clearly.
A Practical Vulnerability Management Process
A good process does not need to be overly complicated.
It should be repeatable.
Step 1: Identify
Maintain an inventory of devices, servers, applications, cloud systems and internet-facing services.
Run regular vulnerability scanning and review vendor security notifications.
Step 2: Prioritise
Consider active exploitation, internet exposure, business importance, sensitive data and the potential impact of compromise.
Do not prioritise only by the number shown in a scan report.
Step 3: Plan
Determine whether the system can be patched immediately, requires testing or needs temporary protection.
Assign an owner and target date.
Step 4: Test
Where possible, test important patches on a non-production system or a small group of devices first.
Confirm that applications continue to work.
Step 5: Deploy
Install the patch using an approved maintenance window or emergency process.
Communicate expected downtime when necessary.
Step 6: Verify
Confirm that the update succeeded and rerun the vulnerability scan.
Check that services, security tools and backups are operating normally.
Step 7: Report
Provide management with a clear view of outstanding critical vulnerabilities, overdue actions and accepted risks.
This makes vulnerability management visible rather than leaving it inside technical reports.
Where Managed Support Can Help
Some companies do not have enough internal resources to monitor every system continuously.
The IT team may already be handling users, applications, hardware, vendors, email and daily support.
Vulnerability and patch management can easily fall behind.
A managed support arrangement can help with:
- System monitoring
- Operating system patching
- Vulnerability review
- Maintenance scheduling
- Endpoint management
- Alert escalation
- Backup monitoring
- Security reporting
- Remediation coordination
However, the scope must be clear.
Server-level vulnerability management does not automatically include website application scanning.
Operating system patching does not automatically cover every third-party application.
Monitoring does not automatically include penetration testing.
Businesses should understand what is included, what is excluded and who is responsible for each layer.
What Management Should Ask
Management does not need to review every technical vulnerability.
But it should ask practical questions.
- Do we know all our internet-facing systems?
- Are any critical systems running unsupported software?
- Which vulnerabilities are currently overdue?
- Are attackers already exploiting any of them?
- How quickly do we patch critical systems?
- Do we verify that patches were installed successfully?
- Who approves delays?
- Are backups available before major updates?
- Are vendors meeting their responsibilities?
- Can we respond quickly to an emergency vulnerability?
Clear answers show that the process is under control.
Vague answers such as “the antivirus should handle it” or “the provider manages everything” should be investigated further.
The Bigger Lesson
AI may help businesses find security weaknesses earlier.
That is useful.
But discovery is only the beginning.
A vulnerability report does not protect the company.
A dashboard showing a critical alert does not protect the company.
An AI assistant explaining the problem does not protect the company.
The risk is reduced only when someone takes action.
That may mean installing a patch, changing a configuration, restricting access, replacing unsupported software or temporarily isolating the system.
AI can improve detection.
The company still needs a reliable process for remediation.
Closing Thoughts
The new US coordination group between AI developers and essential service providers shows how quickly AI is becoming part of cybersecurity operations. Advanced systems can identify software and infrastructure vulnerabilities at a scale that was previously difficult to achieve.
This could help defenders.
It could also make the gap between well-managed and poorly managed businesses much wider.
Companies with complete asset inventories, proper monitoring, clear patching responsibilities and tested recovery procedures will be better prepared.
Companies that do not know what systems they operate may struggle to keep up.
The lesson is straightforward.
Know what you have.
Identify what is exposed.
Prioritise what attackers can exploit.
Patch based on risk.
Verify that the fix worked.
Keep backup ready in case something goes wrong.
AI may help find the weakness.
Your vulnerability management process determines whether that weakness remains open.
At Net Onboard, we help businesses protect and maintain their cloud environments through managed hosting, server monitoring, cybersecurity, backup and business continuity services.
If your company needs to review its server security, vulnerability exposure, patching process or backup readiness, Net Onboard can help build a practical approach based on your infrastructure and operational requirements.