Your supply chain doesn’t start with software. It starts with firmware.
Every server in your data center, every laptop on your network, every router, firewall, switch, printer, wireless access point, and VoIP phone. All of them run firmware. UEFI on your endpoints. Baseboard management controllers on your servers, always on, always network-connected, capable of full remote control even when the machine is powered off. NIC firmware from Intel and Broadcom. FortiOS on your firewalls. Cisco IOS on your switches. PLC firmware on your factory floor. Every one of those devices runs firmware your team has never looked at, and probably never will.
This is the deepest layer of your supply chain. And it’s the one nobody is watching.
Closed Binaries, Open Secrets
Firmware ships as a closed binary. You can’t read the source code. You can’t audit the components. You can’t see what’s inside.
But here’s what is inside: open-source dependencies. The same libraries, frameworks, and components that make up 70 to 90 percent of all modern software are embedded in firmware too. Linux kernels, communication protocol stacks, cryptographic libraries, sensor drivers, all bundled into a binary blob that the vendor ships and you deploy. The difference is that with application software, there’s at least an expectation of transparency. With firmware, there’s none. No vendor tells you what open-source components are in their firmware. No standard requires it. No questionnaire captures it.
The code is hidden from you. It isn’t hidden from attackers. Reverse-engineering firmware used to require deep, specialized expertise, the kind of work that took weeks and limited who could do it. AI erased that barrier. Attackers now use AI to decompile firmware binaries, map their open-source components, and generate working exploits for known CVEs in hours, not weeks. Microsoft’s CTO recently demonstrated AI reverse-engineering decades-old firmware live on stage, showing that even legacy embedded systems are now vulnerable to automated analysis. What used to be an elite skill is now fast, cheap, and scalable. They know what’s in your firmware better than you do. Better than your vendors do, in many cases. A vulnerability in an embedded library is invisible to your security tools but fully visible to anyone pointing an AI at the binary.
Updates That Never Come
Application software gets patched weekly. Operating systems push updates automatically. Firmware? You’re lucky if your vendor releases an update once or twice a year.
This isn’t negligence. It’s how firmware is built. Firmware is designed to be permanent, stored in ROM or flash memory, not meant to change after deployment. Update mechanisms are manual, inconsistent, and often require rebooting critical infrastructure, so they get deferred. Indefinitely. In OT and industrial environments, a single firmware patch can take 12 to 18 months to develop, validate, and ship. Many devices are never updated at all.
Eclypsium found that 99 percent of enterprise devices they analyzed had outdated or vulnerable firmware. Ninety-nine percent. For most organizations, patching stops at the OS and application level. Firmware isn’t on the list. And when a device hits end-of-life, updates stop entirely, but the device keeps running, with known vulnerabilities, for years. Cisco’s Small Business RV routers reached end-of-life with unpatched security flaws. They’re still being sold. They’re still deployed in production networks. The devices keep running. The vulnerabilities keep accumulating. The updates never come.
The OEM Chain
Even when a fix exists, firmware doesn’t travel like a software update.
A vulnerability is discovered. The chipmaker or firmware vendor develops a patch. That patch goes to each OEM — Dell, HP, Lenovo, Supermicro — who has to validate it, integrate it into their own BIOS release, test it across every affected model, and publish it. Then the enterprise has to schedule a maintenance window, reboot infrastructure, and deploy. Every link adds weeks. Most add months.
Consider CVE-2024-56161, a high-severity flaw in AMD’s microcode signature verification that affected every Zen 1 through Zen 4 CPU. Google reported it to AMD in September 2024. AMD shipped a fix in December. By February 2025, only four OEMs had released BIOS updates. Everyone else was still working through validation. Five months, and most enterprises were still exposed because the fix couldn’t travel through an OS update. It could only move through the OEM BIOS chain, the slowest delivery mechanism in enterprise IT. An attacker with AI can generate a working exploit for a published CVE in hours. The OEM chain needs months to deliver the fix. That math doesn’t work.
Patched Doesn’t Mean Safe
Your team found the vulnerability. Applied the patch. Closed the ticket. Moved on.
That’s exactly what happened across thousands of enterprises running FortiGate firewalls. Known FortiOS vulnerabilities were disclosed, patches were released, and security teams deployed them. The playbook worked. Or so they thought.
What nobody realized was that attackers had already been inside — in some cases, for more than two years. Before the patches landed, they planted a symlink in the firmware’s language files folder, a directory that stays publicly accessible on devices with SSL-VPN enabled. That link pointed to the root file system, giving persistent read-only access to configuration files, credentials, and internal network data. And when the firmware was updated to close the original vulnerabilities, the symlink survived. The patch didn’t touch it.
In April 2025, the Shadowserver Foundation reported over 16,000 compromised FortiGate devices across Asia, Europe, and North America, most of them already patched. Firewalls that enterprises trusted to defend their perimeter were silently leaking data to attackers, months after the security team had done everything right.
The device your team relies on to protect the network was the compromised firmware. And patching — the one action every security team is told to do — wasn’t enough.
What Maze Does About It
Maze is a deep-analysis risk engine built for exactly this problem.
Maze analyzes firmware directly: UEFI images, BIOS packages, network appliance firmware, embedded components. No source code required. No vendor cooperation needed. It surfaces CVEs, 1-day exploits, malware, and zero-days hidden inside closed firmware that no other tool can see into. The open-source components your vendor never disclosed, the vulnerabilities already being exploited in the wild. Maze finds them and gives your team clear remediation steps to reduce risk without waiting on the OEM chain.
Maze Dex continuously scans over 1,000 vendors, detecting critical firmware flaws before they’re weaponized. When the next FortiGate-level compromise hits — when the next firmware backdoor survives a patch — you’ll know before your vendor does.
No agents on your environment. No complex integrations. Simple API calls. Fast, seamless, non-disruptive.
For years, the only people looking inside your firmware were the ones attacking it. Maze changes that.