The default assumption in cybersecurity is that every flaw eventually gets a fix. A researcher finds a bug, a vendor ships a patch, everyone moves on. That assumption quietly falls apart the moment the vulnerable thing is a locked chip embedded in a plastic card, or a camera board bolted to a warehouse ceiling, or an ATM running software nobody has touched since the last hardware refresh. This week gave us three separate reminders that “can’t be patched” is not the same as “can’t be broken,” and that a lot of security teams still budget for one and ignore the other.

Start with the story that should worry anyone who thinks cold storage is a synonym for safe.

Physical Isolation Was Never a Cybersecurity Control

Ledger’s Donjon security team demonstrated that a precisely aimed laser pulse at the chip inside a Tangem crypto wallet card can reset the card’s password to whatever the attacker wants. No original password required. No backup card needed. Once the reset lands, whoever fired the laser owns the wallet and can move the funds out. There is no patch coming for cards already in people’s pockets, because the flaw lives in silicon, not firmware.

To be fair, this isn’t a remote attack a random scammer runs from a laptop in another country. It requires physical possession of the card, specialized lab equipment, and real skill. Most owners are not on anyone’s target list for that kind of effort. But that’s exactly the point worth sitting with: the marketing pitch for hardware wallets, air-gapped signing devices, and similar cold-storage products has always leaned on the idea that removing network exposure removes risk. It doesn’t. It just changes the threat model from remote and cheap to physical and expensive, and for anyone holding meaningful value, “expensive” is not the same as “impossible.”

The Cybersecurity Industry Bet on Patching. These Bugs Prove the Bet Was Incomplete

Cisco Talos disclosed three vulnerabilities in WolfSSL, fourteen in GeoVision surveillance products, and one in the VTK-DICOM medical imaging library this week. All of them got patched by their respective vendors, which is the system working the way it’s supposed to. WolfSSL is a widely embedded TLS library, and a fast vendor response there matters because so much downstream hardware inherits whatever WolfSSL ships.

GeoVision is the more instructive case. Fourteen vulnerabilities in one vendor’s camera and access-control line is not a rounding error, it’s a pattern. Embedded security cameras run real software stacks with real memory bugs, they just ship in a metal housing that makes people forget that fact. The devices sit on networks for years past their supported lifecycle, often with no realistic patch deployment process because nobody assigned ownership of “who updates the camera firmware” when the system was installed. Talos did its job disclosing responsibly under its third-party vulnerability policy. The open question is how many of the affected devices in the field will actually receive that fix, versus how many will just keep running the vulnerable version because updating a camera requires someone to physically show up.

Patch Cadence Assumes Someone Is Watching the Calendar

A patch existing and a patch getting installed are two different events, and the gap between them is where attackers live. That gap is worse for embedded and IoT-class hardware than for a laptop fleet with automatic updates, because nobody built the update pipeline with the same urgency. Security hardening for these device classes has to assume the patch will arrive late or never, and plan compensating controls accordingly rather than treating “vendor shipped a fix” as the end of the incident response story.

ATMs Have Been the Canary for This Problem Since Windows XP

Dark Reading’s coverage of fresh crypto bugs in ATM software points at holes in a Microsoft BitLocker security wrapper, the kind of flaw that could theoretically let someone bypass disk encryption protections on machines that dispense cash. ATMs have quietly been the industry’s longest-running case study in unpatchable-by-procurement hardware. Banks buy machines on long depreciation cycles, certify a specific software image against regulatory requirements, and then resist touching that image for years because recertification is expensive and disruptive. The result is a fleet of endpoints running old, sometimes cryptographically weak configurations, sitting in public lobbies, connected to financial networks.

None of this is new. What’s worth noticing is that it keeps happening in the same shape: a wrapper meant to add threat protection around sensitive data instead becomes the weak point, because the underlying assumption, that a certified, closed system doesn’t need active monitoring, turns out to be false every single time someone actually looks.

Building Defense in Depth When the Patch Isn’t Coming

None of this means unpatchable hardware should be pulled out of service or that cold storage is a bad idea. It means the security plan for these assets can’t stop at “wait for the vendor.” Here’s what actually holds up:

1. Inventory the unpatchable. You cannot defend what you haven’t listed. Build a specific register of embedded devices, cameras, ATMs, hardware wallets, and anything else where a firmware or silicon fix isn’t realistically going to land on your timeline.
2. Segment aggressively. Put these devices on isolated network segments with firewall rules that permit only the narrow traffic they actually need. A camera that only needs to talk to its recording server has no business reaching the internet directly.
3. Add compensating threat detection. If the device itself can’t be hardened further, put monitoring around it: anomaly detection on network flows, alerting on unexpected authentication attempts, and brute-force lockouts on any exposed management interface.
4. Control physical access like it’s a real attack surface. Cameras, ATMs, and hardware wallets all fail the same way once someone gets hands-on time with them. Treat physical access controls as part of your security program, not a facilities afterthought.
5. Bake end-of-life into procurement. Before buying the next batch of embedded devices, ask the vendor directly how firmware updates get delivered and for how long. Make patchability a purchasing requirement, not a surprise three years in.
6. Plan incident response assuming compromise, not prevention. For assets you know you can’t fully patch, write the response playbook around detection and containment speed, because prevention alone was never going to be the whole answer.

This is defense in depth in its most literal sense: when one layer can’t be updated, the layers around it have to do more work.

Frequently Asked Questions

Is the Tangem laser attack something everyday wallet owners need to worry about?

Not urgently. It requires physical possession of the card, precision lab equipment, and specialized skill, which puts it out of reach of typical opportunistic attackers. It matters more as a reminder that “unpatchable” hardware still has a threat model.

Why do embedded devices like cameras get patched so much slower than laptops or servers?

Most organizations never assign clear ownership for firmware updates on embedded hardware, and updating often requires physical access or a manual process, unlike automated OS patching on end-user machines.

What’s the single most useful step for securing devices that can’t be easily patched?

Network segmentation. Isolating unpatchable devices onto restricted segments with tight firewall rules limits what an attacker can reach even if the device itself stays vulnerable indefinitely.

Sources

• WolfSSL, GeoVision, VTK vulnerabilities
• Laser Attack Resets Tangem Wallet Passwords on Cards That Can’t Be Patched
• Fresh ATM Crypto Software Bugs: Jackpot or Bust?