In roughly 60% of breaches, a patch was already available when attackers got in. That finding comes from J.P. Morgan’s July 2026 report, “Patchmageddon,” and it shifts the question from whether a fix exists to how long it takes to deploy.
That window is shrinking fast. The same report describes AI tools that can reverse-engineer a newly released patch and turn it into a working exploit in minutes. Every day an available patch sits undeployed is a day attackers can use.
For third-party apps managed in Microsoft Intune, many of those days go to packaging. IT teams download the installer, build the package, write detection rules, test, and assign, then repeat it all for every app and every release. The result is delayed patching that nobody planned for.
Here’s how fast the exploitation window is closing, where Intune app packaging slows things down, and what it takes to close the gap.
How fast attackers now exploit new vulnerabilities
Exploiting vulnerabilities is now the most common way attackers break in. According to the 2026 Verizon Data Breach Investigations Report, exploitation accounted for 31% of initial access in breaches, up from 20% a year earlier.
Many of those attacks start right away. More than a quarter of the vulnerabilities newly listed as exploited in the first half of 2026 were already under attack on the day they went public, according to the Zero Day Clock.
Patching hasn’t kept pace. Verizon found that organizations took a median of 43 days to fully fix known exploited vulnerabilities, up from 32 days, and only about a quarter of them were fully fixed at all.
Old vulnerabilities stay in play, too. In a single week in late August 2026, the typical vulnerability attackers went after had been public for four years, according to the Zero Day Clock.
A patch cycle measured in weeks leaves third-party apps exposed during the riskiest period. An update that never ships leaves them exposed for years.
Why available patches go unapplied
If the patches exist, why do so many sit undeployed? According to TuxCare’s 2026 Open Source Landscape Report, 61% of security incidents among enterprise open source users involved patches that were available but never applied. Downtime constraints were the most common reason for delays, cited by 43% of respondents.
That survey focused on open source environments, but the same causes show up wherever IT teams deploy updates:
Fear of breaking something. An update that disrupts a business-critical app or forces an unplanned restart becomes its own incident. When testing hasn’t been done, waiting feels safer than deploying.
Too few people with the right skills. Packaging a Win32 app correctly takes specialized knowledge. When that knowledge sits with one or two people, every update waits on their availability.
Every update is its own project. Third-party vendors release on their own schedules, and each release needs the same preparation before it can go out. The work rarely batches neatly, so the queue grows faster than it shrinks.
No proof that patches landed. Without device-level confirmation, IT can’t tell which endpoints are still running the vulnerable version, and gaps go unnoticed until someone goes looking.
Where Intune app packaging slows third-party patching
While Intune handles Windows and Microsoft 365 updates well, third-party apps are harder to manage. Microsoft’s Enterprise App Management helps by offering a catalog of prepared Microsoft and non-Microsoft Windows apps that Intune can keep up to date. However, the catalog only includes apps Microsoft has prepared, and Microsoft makes no guarantee that a requested app will be added.
Apps outside the catalog, custom and internal apps, and tenants without Enterprise App Management still go through the standard Win32 process.
For every new release, that process typically looks like this:
Download the installer from the vendor and confirm it’s the right version and architecture.
Find the silent install and uninstall commands. Intune requires Win32 apps to install without user interaction, so someone has to work out which switches each installer supports.
Wrap the installer as a .intunewin file using the Microsoft Win32 Content Prep Tool.
Write detection rules so Intune can confirm the app installed correctly.
Configure supersedence so the new version replaces the old one.
Test the package on a spare device or virtual machine before it reaches users.
Assign the app to the right groups.
Verify the rollout and troubleshoot any devices that failed.
Then the vendor ships another update, and the cycle starts over. Multiply those steps by every third-party app in the environment, and every release each one ships, and Intune Win32 app deployment becomes a standing backlog. That backlog is where “available” turns into weeks.
What a faster third-party patching process needs
J.P. Morgan’s report recommends that organizations run the latest software versions and shorten their patch testing and deployment timelines. For third-party apps in Intune, that comes down to a few operational requirements:
A current inventory of third-party apps. Every patching decision starts with knowing which apps and versions are running on which devices.
Trusted, verified installer sources. Pulling installers from vetted sources reduces the risk of deploying a tampered or malicious package.
Automated packaging. Silent install and uninstall commands, detection rules, and supersedence should be generated for each release automatically, without hand-written scripts.
Automatic detection of new versions. When a vendor ships an update, the new package should be built without waiting for someone to notice the release.
Automated testing and security scanning before deployment. Testing every build on a clean machine removes one of the main reasons teams hold updates back.
Staged rollout. Deploying to a pilot group first limits the impact if an update does cause problems.
End-user controls. Deferrals, restart prompts, and grace periods let updates go out without interrupting someone mid-task.
Deployment status and audit visibility. Per-device reporting confirms that each patch actually landed and leaves a record for audits.
Questions to measure your third-party patch window
Before changing tools or processes, it helps to know where your team stands today. These questions show how wide your exposure window really is:
How many days pass between a vendor release and Intune assignment for your top 10 third-party apps? This number is your real patch window, and it’s often longer than teams expect.
How many people on your team can package a Win32 app correctly? If the answer is one or two, every update depends on their availability.
When did you last delay an update because testing wasn’t done? Frequent delays point to a testing bottleneck, not a scheduling one.
Can you prove a patch reached every device? Without per-device confirmation, an update that looks complete may still leave endpoints exposed.
How agentic packaging shortens the path from release to deployment
J.P. Morgan’s report makes a point that’s easy to miss among the warnings: the same AI tools used to find and exploit vulnerabilities can also help fix them. Agentic packaging applies that idea to the slowest part of third-party patching.
In an agentic packaging workflow, AI agents take on the repetitive steps of Intune app packaging. They read the installer, work out the silent install and uninstall commands, build the package, and generate the detection logic. Each build is then tested on a clean machine, and the results go to an admin for review before anything is published to Intune.
See agentic packaging in action on October 21
A patch that already exists is only as useful as the time it takes to reach every device. For third-party apps in Intune, much of that time goes to packaging.
Agentic packaging takes the repetitive work out of each release, so new versions can move through testing and into a staged rollout without sitting in a queue.
Splashtop is hosting a 30-minute webinar, “From Manual to Agentic Packaging: Simplifying App Deployment with Microsoft Intune,” on October 21 at 8am PT / 11am ET. Microsoft MVP Maxime Guillemin and Splashtop Head of Product Brandon Shopp will walk through how AI and agentic workflows reduce packaging effort and errors, including a look at agentic packaging in action.
