CISA's emergency directive on Cisco ASA and Firepower devices, issued in September 2025, opened with a chore: identify every instance in your environment. For a handful of firewalls, that's an afternoon. For a telco or a bank with gear spread across dozens of sites, it's a project, and it raises a question most security programs have never had to answer. What software is actually running inside the devices we own?
Your customers probably have a vulnerability management program. It scans the network, matches versions and banners against CVE lists, and feeds a ticket queue. That works well for what it can see.
A network scan looks at a device from the outside. Firmware composition analysis opens the image and lists what's inside. They answer different questions, and mature programs often fund only the first.
It helps to keep four terms apart:
NetRise studied 100 networking devices (routers, switches, firewalls, VPN gateways and access points) and found an average of 1,267 components and 1,120 known vulnerabilities per device. About 20 per device were weaponized, and 7 of those were reachable over the network. That's vendor research on a small sample, so treat it as a rough shape: over a thousand findings per device and a handful that matter.
Telecom operators run multi-vendor networks on equipment that stays in service for years, and much of it sits at the edge. After Salt Typhoon, CISA, NSA, FBI and partner agencies published hardening guidance for communications infrastructure in December 2024. It says the compromises it examined lined up with existing weaknesses in victim infrastructure, with no novel activity observed.
The broader data points the same way. In the 2025 Verizon DBIR, edge devices and VPNs rose from 3% to 22% of vulnerability-exploitation breaches, and only 54% of those flaws were fully fixed, with a median of 32 days. The 2026 edition put exploitation ahead of stolen credentials as the top way in.
Banks have the mirror problem. Security appliances, network gear, ATMs and payment terminals come from a short list of suppliers, and the bank didn't write a line of their firmware. Supplier attestations and questionnaires describe a moment in time. Auditors increasingly want evidence, and NetRise can supply the underlying evidence from the software itself. It doesn't make an institution compliant, so ask which standards your customer is actually audited against.
In ED 25-03, attackers exploited two zero-days and modified ROMMON on ASA 5500-X units without Secure Boot, so the implant survived reboots and software upgrades. Firmware composition analysis wouldn't have detected that implant or stopped the exploit. That's forensics and runtime territory.
What it could have helped with is the directive's first step: which devices carry the affected software, across which sites. In a large fleet, that's the slow part.
NetRise Turbine analyzes compiled firmware images, appliances and applications without source code or supplier participation. It builds the SBOM from the artifact, ranks vulnerabilities by reachability and exploit data, and flags risk with no CVE attached, such as hard-coded secrets, weak keys and misconfigurations. NetRise Provenance covers the open-source side: who maintains a component, and how far a compromise travels.
It sits next to EDR, SIEM and vulnerability management. It doesn't detect attacks, doesn't patch anything, and needs the firmware image to analyze. Fixes still depend on what the supplier ships.
NetRise published a customer story about a global broadband solutions provider that builds devices for service providers. It had OEM firmware to validate before release, no source code, and QA engineers who needed to know what mattered. Each release candidate now goes through binary analysis as a standard QA step, ranked by network accessibility, KEV listing, EPSS score and execution-aware reachability.
The story reports qualitative results: repeatable analysis, sharper prioritization, and conversations with OEM and chipset partners that run on evidence instead of speculation. It gives no figures, so we won't either.
Two lessons carry over to your accounts. The analysis stuck because it became a step in a workflow the team already ran. And the provider credited its choice partly to onboarding: a dedicated demo environment and instruction on reading the results. An operator or bank on the receiving end of vendor gear faces the same triage problem, and the same services gap.
Four questions open it:
Partners can build services around the answers: a product visibility workshop, an assessment of a sample of devices, help interpreting and ranking results, and re-analysis when firmware or disclosures change. Those are services you'd design and price yourself. NetRise provides the analysis platform, and it lists a managed offering too, so ask us what that covers. Not every account will want any of this. The ones running lots of vendor gear under audit pressure probably will.
Want to test the conversation on a real account? Talk to our DLX team about a partner demo, bring a customer scenario, and we'll walk through what a firmware analysis would produce and what services could sit around it.