March 30, 2026
5m 56s

Exploitation of vulnerabilities is the top initial access vector for bad actors in 2026, according to Verizon Business’s annual cybersecurity report.
According to the 2026 Data Breach Investigations Report (DBIR), vulnerabilities were exploited in 31% of the breaches studied for this year’s report, up from 20% in last year’s report. More alarmingly, only 26% of critical vulnerabilities were fully remediated by organizations in 2025, a drop from the previous year’s 38%.
“This DBIR finding hits a very real issue I see in the embedded world,” said James Sheridan, CEO and head engineer at Sheridan Technologies.
Unlike web apps and other software, embedded software can’t “just patch” old vulnerabilities — at least not easily. Embedded software is tied to hardware, vendor SDKs, legacy libraries, and other factors. Patching isn’t always realistic, which is something attackers are aware of.
“Where I see this play out is not usually some dramatic movie style exploit, it is more ordinary than that,” said Sheridan. “A product ships with an outdated network stack. A vendor SDK has a known issue, but updating it risks breaking drivers. Debug interfaces were useful during development and never fully locked down. OTA updates were planned for later and never made it into the first production release. A device uses a certificate, key, or credential pattern that made sense during prototype development but should never have survived into production. Those are the kinds of things attackers love because they age badly.”
Simple exploits are enticing to attackers, and now, they are even easier to find with the increased capability of AI models to find vulnerabilities at scale.
“The findings in the 2026 DBIR point to a very real problem the industry has already been facing,” Joseph M. Saunders, CEO and Founder of RunSafe Security, said. “Now, AI is accelerating vulnerability discovery. We will likely see a further increase in initial access as the top cybersecurity risk, and patching challenges will only compound.”
Patches aren’t always released for embedded software. However, even when patches are available, many organizations don’t install them, worried that the update will create new problems in their tech stacks.
“From my experience, embedded systems are becoming more exposed as devices become more connected and software stacks grow complex while systems are expected to remain highly stable,” said developer Manita Ngarmpaiboonsombat.
Edward Tian, CEO of GPTZero, says that he’s seen many organizations tolerate known vulnerabilities rather than risk breaking something with a patch.
“Earlier this year, I conducted an internal application review and discovered there were components within that application that, despite being known internally to be well over a year out of date, more than likely could have been updated a long time ago,” he said. “Nobody wanted to take the chance of an unplanned outage and a problem for their end users by going through the process of updating them, thus they continued to postpone doing so.”
This mindset means that some organizations are seeing the patches themselves — rather than the vulnerabilities — as the risk.
“In many cases, the embedded software has functioned as expected and without problems for several years,” said Tian. “Therefore, when the time comes to issue a security update for the embedded software, the organization does not see issuing the update as an accepted industry best practice but, rather, sees it as introducing an unacceptable risk.”
This creates a dangerous environment, and one that attackers are happy to exploit.
Traditionally, security teams have treated patching as a monthly project, but that has to change. When it comes to patching vulnerabilities, organizations need to move fast. Attackers are speeding up their exploits, testing vulnerabilities as soon as they become public.
This can be complicated for embedded software, said Ngarmpaiboonsombat.
“One of the biggest challenges is balancing security updates with operational reliability, as organizations need extensive validation before deploying into the production environments,” he said.
To act quickly on new updates and patches for embedded systems, organizations will need to plan ahead and be aware of the complexities of their tech stack.
“What I would recommend is pretty practical,” said Sheridan. “Maintain an accurate inventory of embedded devices and firmware versions, know which third-party components and SDKs are inside your products, build and preserve an SBOM, treat secure update capability as a product requirement, not just a nice-to-have, and lock down debug access before production. Then threat model the device, the cloud connection, the mobile app, and the manufacturing process together. When updating firmware is risky, use compensating controls: network segmentation, access control, monitoring, and limiting exposed services.”
Continuous maintenance is key, says Tian.
“Successful organizations have begun putting application maintenance into their daily operation and not treating the process as an ad hoc maintenance project every 30 days or so,” he said.