Alexander Kozlov and Sergey Anufrienko (Kaspersky) examined the layered boot security of Qualcomm's MDM9207 IoT/M2M modem chipset, widely deployed via module vendors (Telit, Quectel, and others) in smart utility meters, retail and security equipment, logistics trackers, and networking gear. Their research, tracked as CVE-2026-25262 and affecting a family of related Qualcomm chips (MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, SDX50), worked through the chip's full chain of trust, from the application processor's BootROM, through its secure factory-download protocol, TrustZone's memory protections, the secondary bootloader, and down to the separate BootROM running on the modem's own communications processor, and found that each stated security guarantee held only until it met the next layer down. This write-up stays at the concept level: what a chip's boot security is supposed to guarantee, why a "physical access required" bug is still a real supply-chain and device-security concern, and how defenders should think about it. It deliberately omits the specific bypass mechanics, memory addresses, and debug-enablement steps from the talk.
Post 13 of my Black Hat Asia 2026 series. Hardware boot-security research like this is usually only actionable with direct physical or JTAG-level access to the device, so the value for most readers is architectural: understanding why layered hardware trust is hard to get right everywhere at once, and what that means for anyone deploying embedded/IoT devices at scale.
1. Why a cellular modem chip's boot security matters
The MDM9207 isn't a phone chip, it's the kind of low-cost cellular modem module that goes inside smart utility meters, retail payment and security terminals, logistics trackers, and industrial networking equipment. Devices like these are frequently deployed in the field with no physical oversight: a meter on a pole, a tracker on a truck, a terminal in an unattended kiosk. For that class of device, the chip's own boot security is the last line of defense, there's no data center perimeter, no locked server room, just the chip and whoever can get physical access to it.
The chip's documented security model rests on a small number of promises, and the research is organized around testing each one:
- The application-processor BootROM only executes verified (signed) code.
- TrustZone restricts access to the communications-processor (modem) subsystem's memory from the main application processor.
- The communications processor's own BootROM cannot be read out.
- The communications processor's BootROM likewise only executes verified code.
Each of those bullets is a distinct hardware or firmware control, implemented by a different mechanism, at a different stage of boot. That's a reasonable design, defense in depth is supposed to mean that if one layer is bypassed, the next one still holds. The talk's throughline is that, on this chip family, the assumptions were tested one at a time and each was found not to hold, which meant an attacker with physical access to the device could progressively work from the outermost layer (the factory download interface) down to the innermost (debug access to the modem's own processor core).
Fig. 1 — The four security assumptions map onto four distinct stages. Layered trust only works if every layer is individually sound; testing that requires attacking each one in turn.
2. The research posture: verify each stated guarantee, don't assume it
Without walking through the specific techniques, the shape of the investigation is instructive on its own and generalizes well beyond this chip:
- Start from the documented and marketed security claims, "BootROM only runs verified code," "the debug processor's ROM can't be dumped", and treat each as a hypothesis to test, not a fact to trust.
- Test the outermost, most reachable interface first. Chips like this expose a factory/service-mode download interface intended for legitimate reflashing and manufacturing use; it is also, by construction, code that runs very early with high privilege, making it a natural first target.
- Use whatever foothold one layer yields to examine the next. A weakness that only grants limited capability at one stage of boot can still be enough to observe or influence behavior at the following stage, this is why "boot chain" security has to be evaluated end-to-end, not layer by layer in isolation.
- Revisit every stated assumption at the end, checking off which of the original four security promises actually held once the full chain had been examined.
3. Why "needs physical access" doesn't mean "not a real risk"
A natural reaction to chip-level boot research is "this needs a chip on a bench, so it doesn't matter for my threat model." Two reasons that's incomplete for this class of device:
- Supply-chain and field-deployment exposure. Utility meters, trackers, and unattended terminals sit in physically accessible locations for years. A device an attacker can borrow, tamper with, and return (or one they can buy off a resale market and study at length) gives exactly the kind of extended physical access this research assumes.
- Debug access, once enabled, persists. Hardware debug interfaces are typically fused off in production devices specifically because, once available, they hand an attacker deep, low-level control, arbitrary memory read/write, execution control, register-level access, that is difficult or impossible to detect from software running on the device. A technique that re-enables such access converts a one-time physical compromise into a durable capability against that unit, and potentially against its firmware/key material in ways that could affect other units in the same fleet if secrets are shared or derivable.
The disclosed timeline shows the researchers reported the issue in early-to-mid 2025, with the CVE and public advisory following in 2026, the standard responsible-disclosure cadence for hardware-level silicon issues, which typically take longer to remediate than software bugs because fixes may require new silicon revisions or fused-off mitigations rather than a simple firmware patch.
4. What to actually do about it
- Inventory affected silicon. If your product or fleet uses MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, or SDX50-based modules (commonly OEM'd by module vendors like Telit, Quectel, and others), check with your module vendor for guidance and any available mitigations or revised parts.
- Apply available firmware/fuse mitigations. Where Qualcomm or the module vendor has published a fix, whether a firmware update, a fuse-configuration change, or a revised part, apply it before field deployment, and audit already-deployed units where feasible.
- Treat physical access as a real threat for field-deployed IoT. Devices in unattended locations should be designed assuming an attacker will eventually get hands-on time. Don't rely solely on "physical access required" as a reason to deprioritize a hardware finding for this device class.
- Minimize the blast radius of a single compromised unit. Avoid shared secrets or keys across a whole fleet where a single device's compromise (via a boot-chain or debug-access bypass) could be leveraged against the rest of the fleet.
- Physically harden or monitor debug interfaces on high-value deployed hardware where feasible, tamper-evident enclosures, tamper-detection circuitry, and epoxy-potted debug headers are standard mitigations for exactly this class of exposure.
Does this affect smartphones?
The affected chip family here (MDM9207 and related MDM9x07/9x45/9x65, MSM8909/8916/8952, SDX50 parts) is primarily IoT/M2M modem silicon, not the flagship application processors used in current smartphones. Check your specific device's chipset against the CVE-2026-25262 advisory if you need a definitive answer for a particular product.
Is this remotely exploitable?
No. The research describes a chain of bypasses that require direct physical and, in later stages, hardware debug-level access to the device. It is not a remote network attack. Its relevance is to physical device security, supply-chain integrity, and field-deployed hardware, not to a remotely reachable service.
Why does this take so long to fix compared to a software CVE?
Boot-ROM code is typically burned into silicon at manufacture and cannot be patched after the fact; the practical fixes are firmware updates to later boot stages, fuse-configuration changes on future production lots, or a revised silicon stepping. That's inherently slower than shipping a software patch, which is part of why hardware root-of-trust bugs get a longer disclosure timeline.
What's the single takeaway for someone building IoT hardware?
Don't assume a chip vendor's documented security boundaries have all been independently, adversarially verified end-to-end. Ask your silicon and module vendors directly whether their boot chain has had third-party security review, and design your product's threat model to include "an attacker eventually gets physical access to one unit."
Takeaways
- Qualcomm's MDM9207 (and related chips) ship four separate, layered boot-security guarantees, application-processor BootROM signing, TrustZone memory isolation, and two more for the separate modem communications-processor BootROM.
- The research (CVE-2026-25262) is organized around testing each stated guarantee in turn rather than trusting the architecture diagram, and found each successive layer's promise did not fully hold once the previous one was bypassed.
- This chip family is widely used in utility meters, retail/security, logistics, and networking equipment, devices that are frequently deployed with extended, unattended physical accessibility.
- "Requires physical access" is not the same as "not a real risk" for field-deployed IoT hardware, especially once a hardware debug interface can be durably re-enabled.
- Fixes for silicon-level boot issues are slower than software patches (firmware, fuse config, or new steppings), so inventorying affected parts and applying vendor guidance promptly matters.
- The general lesson generalizes past this chip: a layered trust architecture is only as strong as its least-verified boundary.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- CVE-2026-25262 — the tracked vulnerability across the affected Qualcomm chip family.
- Qualcomm Product Security Bulletins — vendor advisories and mitigation guidance for affected chipsets.
- Kaspersky Securelist — the research team's technical publications.