On September 8, Iran's Revolutionary Guard recovered a U.S. Navy unmanned underwater vehicle near the entrance to the Strait of Hormuz. U.S. Central Command said the vehicle had malfunctioned, and that it was an older model that neither collected sensitive data nor carried classified sonar or radar equipment.
Most of the coverage since has argued about what Iran can rebuild from it. There is history behind that reflex: Iran recovered an RQ-170 Sentinel in 2011 and later displayed domestically produced aircraft it said were reverse-engineered from it, though how much of that was real was never fully settled. Set the rebuild argument aside anyway. The more useful exercise is what a program office can say about its own fleet the morning after something like this. The honest answer has two halves, and only one of them has ever had an owner. The other is a firmware anti-tamper problem.
The distinction the analysts drew
Reporting on the recovery converged quickly on a split. The mechanical systems, the hull form, the propulsion, the power management, are readable by anyone who holds the vehicle long enough. Analysts quoted in the Reuters report carried by Military Times were direct about that.
The other half is different. Mission software and anything a vehicle collected are meant to be protected by encryption, by zeroization routines that wipe key material on tamper, and by anti-tamper measures in the hardware itself. Those are what stand between physical possession and actual intelligence. It is a real distinction and it is the right one.
It also has a seam in it that nobody stated out loud.
Our Take: one half is somebody's job, the other is nobody's
Here is where most commentary on a loss like this goes wrong, and we would rather not repeat it.
The encryption keys aboard a military platform are accounted for. A named person is responsible for them. They are inventoried on a schedule, checked in between, and there is a written procedure for replacing them the moment anyone suspects they are compromised. A program office can tell you which keyed equipment was on that hull and start replacing what needs replacing. The system is old, unglamorous and good at its job, and every regulated industry has its own version of it.
So if you are writing the version of this story where nobody knows what was on board, you are writing about the wrong half.
The half worth worrying about is the software. Firmware. The compiled code. The keys and secrets sitting in memory because that is where they have to sit for the thing to boot. Nobody signs for any of it, and more to the point, none of it can be recalled. You cannot reissue a firmware image that is already in someone else's hands. On most fielded equipment you cannot even update it, because the equipment is never coming back.
That asymmetry is the whole problem. Key management was designed around the assumption that material comes back, gets replaced or gets destroyed. Firmware was designed around the assumption that nobody would ever be holding the board.
What "cannot be recalled" actually means
A modern platform is mostly software, and that software has a longer service life than almost anyone planning it expects.
The library compiled in during integration six years ago is still running. The cryptographic choices made when the program was scoped are still the cryptographic choices, because changing them means a re-flash, and a re-flash means the asset comes home. Long-lived field equipment routinely outlives the cryptographic standards it shipped under, which should worry anyone reading it in a year with three deadlines in it: federal migration plans due to OMB on October 22, the EO 14412 deliverables on December 19, and CNSA 2.0 applying to new National Security System acquisitions from January 1.
The set of things in this category is much bigger than drones. A weapon platform that cannot be re-flashed. A meter in a substation. A sensor on a pole. Anything with an embedded controller that was installed once and is expected to run for fifteen years. All of them have object code sitting in non-volatile memory, and all of them are one physical-access event away from that object code being someone else's to read at leisure.
You have probably met this gap already, in whatever framework you answer to.
If you run a federal authorization package, SC-28 covers protection of information at rest, and yours almost certainly answers it in terms of data on servers and disks. Whether the firmware on a fielded platform counts as information at rest is a scoping question most packages never get asked, and the honest answer is usually that nobody checked.
If you run payments, PCI DSS 4.0 already requires a documented inventory of every cipher suite and protocol in use, reviewed at least annually. Firmware you cannot re-flash is precisely the line on that inventory you cannot close. The terminal in the branch is the same problem as the vehicle in the strait, with a shorter news cycle.
The question worth asking
Not about that vehicle. About yours.
If the equipment Iran recovered had been yours, what would somebody have gotten off it? Not the mission data, which is encrypted, and not the keys, which somebody signs for. The code itself. The logic, the algorithms, the key derivation, the parts that tell a reader how the system thinks.
For most fielded assets the honest answer is: all of it, eventually, to anyone patient with a debugger. That is not a failure of any particular program. It is the default state of embedded software, and it has been for as long as embedded software has existed.
What firmware anti-tamper buys you
QuantaCrypt Vault is the product we built for that default.
It provides software-only anti-tamper protection for firmware, keys, secrets and the memory they sit in, on long-lived field equipment, from desktop and server platforms down to embedded ARM32-class microcontrollers. Protected code and firmware images are statistically indistinguishable from random noise, which is a statement about the stored image and not a claim about every attack against a device. Algorithm rotation happens by policy and license validation works offline, which matters when the equipment never comes home and never sees your network again.
Software-only is the part that makes it deployable on equipment already in the field, rather than only on the next program. That distinction is most of the practical value, because the assets that worry you are the ones you cannot get back to.
The claim that matters, though, is the adversarial one, because anti-tamper is easy to assert and hard to demonstrate. QuantaCrypt Vault has been independently penetration tested, and evaluators holding full specifications could not reconstitute protected data. Full specifications is the important phrase. That is not a black-box test against someone guessing at the format; it is a test against someone who knows exactly how the thing works.
It also runs where the stakes are real: QuantaCrypt Vault provides anti-tamper security for a frontline weapon system under a multi-year U.S. military contract.
The part worth keeping
A captured vehicle is a bad day. How bad depends almost entirely on decisions made years earlier, by people scoping a program, about whether the software on board would be readable by whoever ended up holding it.
Key management answered that question decades ago for the material it covers. The rest of the software on fielded equipment is still, in most organizations, answered by hope.
If you want to run that exercise properly on your own estate, we will give you twenty minutes and no pitch. You will know by the end whether it is a real gap for you. Request a briefing and we will come to you.