In early 2025, a security researcher reverse-engineered one of the license-plate-reader cameras you’ve probably driven past without noticing — the ones mounted on poles above roadways in thousands of American communities. He found flaws. The company acknowledged them but played down the severity, pointing out that exploiting them required physical access to the device, and adding a reassurance that’s now the most important sentence in this entire story: even someone who got into a camera, the company said, would still not be able to gain access to footage, because images stayed on the device only briefly before being sent to the cloud.

Last week, someone tested that claim. A group pulled one of the cameras down from a roadway, copied its storage, and handed the contents to journalists at 404 Media and WIRED. What the resulting joint investigation describes is roughly three weeks of retained data — around 50,000 vehicles and some 1.6 million images — unlocked by an encryption key that was sitting right there on the device, in a section of storage that wasn’t encrypted at all.

Set aside everything you think about surveillance cameras for a moment, because that last detail is a security lesson that has nothing to do with cameras and everything to do with your business. If the key that unlocks your encrypted data is stored alongside the data it protects, then the encryption is a formality. It’s a lock with the key taped to it. And a surprising number of small businesses are running exactly that arrangement right now without knowing it.

How we’re covering this

Two things need saying before we go further, because this story sits on top of a couple of genuinely contentious subjects.

First: the camera in this story was physically torn down and taken. The company states plainly that unauthorized removal and tampering with its cameras is illegal, and there’s been a wave of people destroying these devices around the country. We’re going to report what the research found, because the technical findings are legitimate news and genuinely instructive. We are not endorsing how the device was obtained. “The findings are interesting” and “the method was fine” are two different statements, and we’re only making the first one.

Second: automated license-plate readers are a contested policy question, and we’re a technology and security firm, not policy commentators. Worth noting for anyone who assumes this breaks along predictable lines — it doesn’t. Criticism and scrutiny of these systems has come from across the political spectrum, including a Democratic senator and congressman who have asked the Federal Trade Commission to investigate the company over its security practices, and a Republican governor whose state ordered these devices off state road rights-of-way. We hold no position on whether communities should deploy them. What we care about here is a specific, transferable engineering failure.

What the investigation actually found

Here’s the substance, as reported by 404 Media and WIRED, who examined the recovered data together:

• The key was on the device. The camera’s storage contained partitions that were not encrypted — and one of them held an encryption key that unlocked most of the media the camera had recorded. The researchers didn’t break the encryption. They found the key next to the lock.
• Three weeks of data was retained. Logs and images covered roughly 21 days, comprising around 50,000 vehicles and approximately 1.6 million images — an average of about 28 images per passing vehicle, with some vehicles generating more than 100.
• The software detects people, not only vehicles. The recovered code explicitly identifies people alongside vehicles, plates, and bicycles, recording where a person appears in the frame and assigning a confidence score to the detection.
• In practice, few people were captured here. When WIRED ran the camera’s own models against 27,321 short video clips stored on the device, people were detected in 11 of them — all motorcycle riders. Reporting attributed the small number to the camera’s position above a roadway, where pedestrians were unlikely to pass through its view.
• No facial recognition was found. Both outlets reported finding no evidence that the cameras perform facial recognition, and the company has said they do not. That’s a meaningful clarification and it deserves to be stated as plainly as the rest.

The company’s response, per the reporting, was that the removal was illegal and that it did not have enough detail to assess the claims. That’s a fair position for a company to take about data it hasn’t examined, and readers should weigh the findings knowing the company has not confirmed them.

But the gap that matters isn’t really about this company. It’s between a sentence that was said — someone who got into a camera would still not be able to gain access to footage — and what an examination of an actual device appears to show. That gap is the thing worth learning from, and it exists in a lot of places that have nothing to do with roadways.

The lesson: where does the key live?

Encryption is genuinely powerful, and we recommend it constantly. But it does exactly one thing: it makes data unreadable to someone who does not have the key. That’s the whole mechanism. Which means the entire value of encryption rests on a single question that almost nobody asks:

Where does the key live — and would someone who steals the data also get the key? If the answer is yes, the data isn’t protected. It’s inconvenienced. Encryption that travels with its own key is a locked door with the key hanging on a nail beside it: technically locked, functionally open. This is one of the oldest failures in security, it is not exotic or clever, and it keeps happening because “is it encrypted?” feels like a complete question when it’s really only half of one.

Now here’s the uncomfortable part. Once you know to look for this, you start seeing it everywhere in ordinary business setups. A few we run into regularly:

• The encrypted backup with the password stored beside it. The backup drive is encrypted — and the password is in a document on the same server, or on a label on the drive, or in the email that explains the backup procedure. Anyone who takes the backup takes the key with it.
• The password-protected spreadsheet, with the password in a file next to it. Usually named something helpful, like “passwords.”
• Credentials sitting in configuration files. Website and application config files routinely contain database passwords and service keys in plain text, and get uploaded and backed up right along with everything else. We wrote recently about finding exactly this during cleanups of poorly built websites — and it’s the same failure in a different costume.
• A password manager whose master password is written down where the laptop is. The tool is excellent. The implementation undoes it.
• Encrypted devices that unlock themselves. A laptop or a camera or a drive that boots and decrypts without anyone entering anything has, by definition, stored the means to decrypt itself somewhere the attacker can also reach.

In every one of those cases, somebody can honestly say “our data is encrypted,” and be technically correct, and still be completely exposed. That’s what makes this failure so durable — it survives the audit question, because the audit question is usually the wrong one.

“Encrypted” is a marketing word until someone checks

There’s a second lesson stacked on top of the first, and it’s one we’ve been circling in a few different stories lately: a vendor’s security claim is a statement of intent until someone independently verifies it.

We’re not suggesting the company in this story was being dishonest — it’s entirely possible the statement was accurate as understood at the time, that the design changed, or that the picture is more complicated than either side has described publicly. Investigations are ongoing and we’re not in a position to adjudicate it. But the broader pattern holds regardless: “encrypted,” “secure,” “protected,” and “private” are not specifications. They’re adjectives. And adjectives are what appear on a website, while the actual security lives in details no customer ever sees.

This matters to your business in two directions. You’re a customer of vendors who make these claims about your data and your customers’ data. And if you handle customer information, you’re likely making some version of these claims yourself — which means you should be able to back them up. Here’s what to actually ask, of your vendors and of yourself:

• What exactly is encrypted — data sitting in storage, data moving across the network, or both? These are different protections and “it’s encrypted” often means only one of them.
• Where are the keys kept, and who controls them? The single most revealing question on this list. A good answer is specific. A vague one is an answer.
• What happens if someone gets physical possession of the device? Laptop, backup drive, camera, server, phone — if the honest answer is “they’d have everything,” that’s worth knowing before it happens.
• Has anyone outside your organization ever tested this? Internal confidence is not verification. Third-party testing is.
• How long is data actually retained, and where? Which brings us to the next point.

Two more things this device quietly illustrates

Data stays longer than anyone thinks. The stated understanding was that images lived on the device only briefly. The recovered data reportedly covered around 21 days. Whatever the explanation, the pattern is one we’ve written about repeatedly: retention quietly outlives the policy. Logs pile up, caches persist, a buffer fills, a cleanup job fails silently, and months later there’s far more sitting on a system than anybody intended. This is the argument for actually checking what your systems are holding rather than trusting the design document — because data you didn’t know you still had is data you can still lose.

Devices collect more than their name suggests. The thing is called a license plate reader. Its software also detects people and bicycles, records where they appear, and scores its confidence. That’s not a scandal on its own — detecting objects is how these systems work, and no facial recognition was found — but it’s a useful reminder for any business deploying technology it didn’t build. The camera system you installed for parking-lot safety, the analytics on your website, the sensor in your lobby, the app your staff uses: each collects what it collects, not what its product name implies. And you inherit responsibility for all of it, including the parts you never knew were being recorded.

Worth asking about your own business: If someone walked off with your backup drive, your laptop, or the recorder for your camera system tonight, would they be able to read what’s on it — or would they also be holding whatever unlocks it? * For anything you’d describe as “encrypted,” can you say where the key is kept? * How long is data actually being retained on your systems, as opposed to how long it’s supposed to be? * And what are the devices in your business collecting that you’ve never actually checked?

Physical access is real access

One last thread, because it’s the assumption that made the original reassurance sound reasonable. The idea was: you’d need physical access, so it’s not a realistic threat.

Physical access is a much lower bar than people imagine. A device mounted on a pole beside a public road is reachable by anyone with a ladder and some nerve. And the small-business version is even easier: the network switch in an unlocked closet, the camera recorder in the back room where deliveries come through, the router mounted in a hallway, the laptop in a car, the old computer you put on the curb. “They’d need physical access” is a real mitigation in a data center with badge readers and cameras. In a small office with a propped-open back door, it’s barely a speed bump.

So the practical rule is simple: for any device that holds data you’d hate to lose, assume someone could eventually get their hands on it, and make sure that wouldn’t be the end of the story. That means full-disk encryption where the key isn’t just sitting on the device, physical locks on the equipment that matters, and knowing which devices in your business hold data at all — a list most owners have never made.

The takeaway

Whatever you think about cameras on poles, the engineering lesson here is clean and it belongs to everyone. Encryption only protects data from someone who doesn’t have the key, so the only question that matters is where the key lives. A claim that data is encrypted is the beginning of a conversation, not the end of one. Retention outlives policy. Devices collect more than their names suggest. And “they’d need physical access” is not the reassurance it sounds like.

None of that requires you to become a cryptographer. It requires somebody to actually look — at where your keys are stored, at what your backups would give away if they walked out the door, at how long your systems are really holding data, and at which devices in your business are quietly collecting things nobody has reviewed. That’s precisely what our environment review does: we find the data you’re holding, check whether what’s protecting it would survive contact with an actual attacker, and tell you plainly where the keys are hanging on nails beside the locks they’re supposed to protect.

A camera company said footage couldn’t be reached. Someone checked. The most valuable thing a business can do with a story like that is spend an afternoon making sure nobody could tell a similar story about them.

Sources: Joint investigation by 404 Media and WIRED, September 2026; earlier reverse-engineering research by security researcher Jon “GainSec” Gaines (2025); additional reporting from Straight Arrow News and other outlets, September 2026. The device examined was removed from a roadway without authorization; the manufacturer states that such removal and tampering is illegal and said it lacked sufficient detail to assess the researchers’ claims, which it has not confirmed. Both outlets reported finding no evidence of facial recognition. This article takes no position on the policy question of automated license-plate readers and is concerned solely with the transferable security lessons.