Patching is no Longer a Routine, IT House-Keeping Task; Should Be Automated

... min read

Guest
2nd October, 2026

In an e-mail interview with Digital Creed, Apu Pavithran, Founder and CEO of Hexnode discusses why patching must move beyond IT housekeeping to risk- and exposure-based remediation. He suggests ways of determining high-risk vulnerabilities, automating low-risk deployments. And he stresses on the importance of verifying remediation rather than assuming deployment equals protection.

According to Verizon’s 2026 Data Breach Investigation Report, vulnerability exploitation now accounts for 31% of breach entry points. This indicates that an enterprise’s security posture is directly dependent on its exposed vulnerabilities, which in turn relies on effective patch management.

Yet, enterprise patching has not kept up to speed. Most organizations still rely on monthly cycles, fixed maintenance windows and manual patching protocols.

Apu Pavithran, Founder and CEO of Hexnode explains why patching must move beyond IT housekeeping to risk and exposure-based remediation.

Edited excerpts from the interview:

Why is traditional, calendar-based patching (like Patch Tuesday) insufficient for modern enterprise threat landscapes?

The challenge with calendar-based patching is that vulnerabilities don’t follow a predictable schedule. Fixed maintenance cycles can leave a gap between discovering a weakness and fixing it. At the same time, AI-assisted tools help attackers move faster – from mapping an organisation’s attack surface to identifying vulnerabilities and developing exploits.

Take the SharePoint attacks in July 2025. Attackers exploited vulnerabilities that the month’s initial security updates had only partially addressed, prompting Microsoft to release additional fixes. Waiting for the next scheduled patching window would have left affected organisations exposed for longer.

Testing and staged rollouts remain essential to avoid disruption. The problem comes when every update depends on manual assessment, approval and deployment, slowing down the response even when the risk calls for urgency.

If attackers can use AI and automation to move at machine speed, defenders should use them to shorten the remediation cycle too. Automated patch management can continuously scan endpoints, identify missing updates, prioritise them based on exploitability, exposure and business criticality, and deploy routine patches within predefined policies. Human oversight still matters—the aim is to focus it on exceptions and changes that carry significant operational risk.

Why calendar-based patching falls short

Vulnerabilities don’t follow a schedule. Fixed patch windows leave gaps that AI-assisted attackers can use quickly.
Example: in the July 2025 SharePoint attacks, attackers exploited flaws that the month’s first updates only partly fixed, so Microsoft had to release more fixes.
Testing and staged rollouts still matter. The problem is needing manual approval for every update.
Automation should scan, prioritise and deploy routine patches within set policies. People should handle the exceptions and the high-risk changes.

With AI’s capabilities accelerating vulnerability discovery and exploitation, the current patching model risks exposure. CERT-In’s timely guidance on AI-accelerated vulnerability protection and response draws attention to the issue’s seriousness and relevance for India. Especially, the 6-hour reporting mandate and the urgency for incident response and remediation. How can AI be used to accelerate vulnerability discovery, particularly on endpoints?

AI’s value here is its ability to make sense of large volumes of endpoint data much faster than a team could manually. By continuously examining device behaviour, configuration changes, application activity, performance signals, patch status and compliance data, it can spot unusual patterns that may point to a weakness or attempted exploitation.

An AI-powered orchestration layer across enterprise tools takes this further by bringing those signals together. AI can connect information from endpoint management, security and identity systems with policies and historical incidents to understand the context, identify potentially affected endpoints and help determine what needs attention first.

For example, a missing patch might initially look like a routine update task. But if a security tool also flags suspicious activity on that device, and identity data shows the user has privileged access, AI can connect those findings and recognize that the situation needs more urgent investigation. The orchestration layer can then coordinate the next steps across the relevant tools, within agreed policies and approval requirements.

Natural-language queries also let administrators explore device, policy or compliance states without navigating multiple dashboards. Predictive threat intelligence can help assess which weaknesses are more likely to be targeted. Together, these capabilities shorten the time between spotting a signal and making an informed decision—particularly valuable when organizations need to assess incidents and report those covered by CERT-In’s requirements within six hours of noticing them or being notified.

AI for finding vulnerabilities on endpoints

AI can analyse device behaviour, configuration, application activity, patch status and compliance data far faster than a team can by hand.
An orchestration layer links signals from endpoint, security and identity tools. For example, a missing patch plus suspicious activity plus a user with privileged access means the device needs urgent attention.
Plain-language queries and predictive threat intelligence speed up decisions. This helps teams meet CERT-In’s 6-hour deadline.

In what ways does exposure-based remediation differ from traditional patch management when prioritizing which assets to address first?

It starts with asking what a vulnerability means for your business. Traditional patching often starts with the release schedule or severity score. Exposure-based remediation adds context: can an attacker reach the affected system, is the vulnerability being exploited, and what could happen if that system were compromised?

Imagine two systems with outstanding patches. One is an isolated test machine with a higher-severity vulnerability. The other runs an internet-facing business application with a lower-scoring vulnerability that attackers are actively exploiting. The second system may need attention first because there is a more immediate path to business harm.

Severity still matters, but it cannot answer every question. Teams also need to consider access privileges, existing safeguards, sensitive data and the system’s role in daily operations.

That gives them a practical order of work. The most exposed and consequential risks move to the front, while lower-risk updates follow an agreed schedule. Where a patch isn’t available or cannot be deployed immediately, remediation may also involve restricting access or applying a temporary mitigation.

Exposure-based vs. traditional remediation

It adds context to the severity score: Can an attacker reach the system? Is the flaw being exploited now? What would a compromise cost the business?
Example: an internet-facing app with a lower-scored but actively exploited flaw can come before a high-severity flaw on an isolated test machine.
Teams should also weigh access privileges, existing safeguards, sensitive data and how much the business relies on the system.
When no patch exists yet, restrict access or apply a temporary fix.

What checks or guardrails must be in place before enabling automated patching for routine software and OS updates?

Before switching on automation, teams need to agree on what it can deploy, where it can act and when it must stop. That means verified update sources, clear device eligibility, testing requirements and approval rules for changes with significant operational consequences.

The July 2024 CrowdStrike outage is a reminder of why deployment safety matters. It resulted from a faulty content configuration update affecting Windows systems—not a cyberattack or a conventional OS patch. The broader lesson for patching is to consider how widely a problematic update could spread and how quickly teams could stop it.

Start with a small, representative group of devices and expand only after the agreed health checks pass. Set failure thresholds that pause deployment, maintenance windows that account for business needs, and restart deadlines with sensible limits on user deferrals.

Teams also need a tested recovery plan. Some updates support rollback; others require a different recovery process, so a universal “undo” button cannot be assumed.

Finally, restrict who can change or override policies, record approvals and outcomes, and limit the endpoint data available to automated systems. Routine work can then proceed within clear boundaries, with consequential or uncertain decisions returning to a person.

Guardrails before turning on automation

Define verified update sources, which devices qualify, testing rules and approval rules.
The July 2024 CrowdStrike outage, caused by a faulty configuration update, shows why it matters how far and how fast a bad update can spread.
Start with a small group of devices. Set failure thresholds that pause rollouts, sensible maintenance windows and limits on how long users can delay restarts.
Have a tested recovery plan, since rollback isn’t always possible. Restrict who can override policies, and log approvals and outcomes.

What post-deployment verification methods (e.g., automated rescanning, configuration validation) should teams implement to ensure protection?

An “installed successfully” message is only the beginning. Teams still need to determine whether the vulnerability has been addressed, the update has taken effect and the device can do its job.

Start with an automated rescanning of affected endpoints, checking the installed version and confirming any required reboot. Reconcile the results against the deployment list so that offline devices, failed installations and endpoints that have stopped reporting don’t disappear from view.

For example, an update might install correctly on a group of laptops but disrupt the VPN application employees need to work remotely. A deployment report could show success while users are experiencing a business outage. That is why functional checks belong alongside security checks.

Validate encryption, firewalls, authentication settings and endpoint protection against the approved baseline. Check critical applications and services, then monitor crashes, errors and performance changes as deployment expands.

Devices that fail verification should enter a clear remediation workflow. Rollback may be appropriate where supported, but teams must account for the vulnerability it could reintroduce and apply compensating controls where needed. Continued monitoring helps catch devices that later drift back into an exposed state.

Checking that patches worked

An “installed successfully” message doesn’t prove protection. Rescan endpoints, confirm the installed version and any required reboot, and check results against the deployment list.
Run functional checks as well as security checks. For example, a patch can install fine but break the VPN.
Check encryption, firewall, authentication and endpoint protection settings against the approved baseline. Watch for crashes and performance problems.
Devices that fail go into a remediation workflow. Keep monitoring for devices that drift back into an exposed state.

How do modern endpoint management platforms support Zero Trust architecture through continuous device posture checking rather than point-in-time compliance snapshots?

A point-in-time compliance snapshot tells you whether a device meets security requirements at that moment. But what happens after that check? Settings can change, protection can be disabled, or a device can fall behind on updates. Zero Trust operates on “never trust, always verify,” so teams need to keep checking whether that device still meets the conditions for access.

Modern endpoint management platforms help by monitoring devices and reassessing signals such as patch status, encryption, firewall status, password settings, application compliance and signs of tampering. They share updated posture information with identity and conditional access systems, which can allow, limit or block access as risk changes.

If a device stops reporting, it can be marked non-compliant. If a security issue appears, it can trigger an alert or automated remediation. Once the issue is resolved, the device is checked again before access is restored. That keeps verification ongoing—a device passing one check doesn’t mean it stays trusted indefinitely.

Zero Trust and continuous posture checks

A one-time compliance check goes out of date quickly. Endpoint management platforms keep re-checking patch status, encryption, firewall, passwords and signs of tampering.
They pass this information to identity and access systems, which can allow, limit or block access. Devices that stop reporting are marked non-compliant.

What strategies can IT teams use to manage non-traditional or unmanaged endpoints (such as BYOD, IoT/OT systems, and cloud workloads) within a zero-trust framework?

Personal devices, IoT/OT systems and cloud workloads are now part of everyday IT environments. Within Zero Trust, who owns an endpoint or where it connects from isn’t enough to establish trust. Access needs to depend on a verified identity, the endpoint’s current security condition and the resource being requested.

For BYOD, teams can use multi-factor authentication, single sign-on and conditional access to bring user and device context into that decision. Before granting access, device-trust and compliance checks can assess the operating-system version, screen-lock settings, encryption and application compliance.

For IoT/OT systems and cloud workloads, the same principle applies, but the controls need to fit the environment. Teams need unique machine or workload identities, certificate-based authentication where supported, network segmentation and continuous monitoring, with access limited to what each system actually needs. Centralised identity management helps apply consistent policies across users, devices and workloads, making it easier to withdraw access when risk changes.

The aim is to keep verifying, keep access limited and maintain central oversight—even when an endpoint cannot be managed like a conventional corporate device.

Unmanaged endpoints (personal devices, IoT/OT, cloud workloads)

Access depends on a verified identity, the device’s current security state and what it’s trying to reach, not on who owns it or where it connects from.
For personal devices: MFA, single sign-on, conditional access and device compliance checks.
For IoT/OT and cloud workloads: unique machine identities, certificate-based authentication, network segmentation, minimal access and central identity management.

How is behavioral AI transforming endpoint protection from reactive malware signatures to real-time anomaly detection and predictive management?

Behavioral AI gives IT teams a broader view of what’s happening on an endpoint. Rather than relying only on malware signatures, it continuously looks at how processes run, how files and memory are used, what users are doing and where devices are connecting.

That activity helps AI establish what normal behaviour looks like and flag meaningful deviations in real time. By connecting multiple signals, it can spot suspicious behaviour associated with previously unknown threats, fileless attacks or the exploitation of zero-day vulnerabilities.

It can also look at historical patterns alongside current endpoint conditions to help teams anticipate emerging risks, prioritise vulnerable devices and identify preventive steps. This helps teams move beyond reacting to known malware and towards spotting unusual activity early and managing risk more proactively.

Behavioural AI

It goes beyond malware signatures by learning what normal process, file, memory, user and network activity looks like.
It flags unusual behaviour in real time, which can catch unknown threats, fileless attacks and zero-day exploits. It also uses past patterns to predict risks and prioritise devices.

Pavithran has over 15 years of experience in enterprise software and cybersecurity. He has transformed Hexnode from a small startup into a global leader trusted by organizations in over 130 countries.

CYBERSECURITY