Supply Chain Penetration Testing: What Slovakia’s Backdoored Cameras Reveal

Why supply chain penetration testing just stopped being optional

Here is the story that should end every debate about whether supply chain penetration testing is worth the budget line. In August 2026, Slovakia’s National Security Authority — the NBÚ — reported that 279 traffic-enforcement cameras, freshly installed on the country’s public roads, had shipped with a backdoor.

Not a bug. A backdoor. According to the NBÚ findings, as reported by outlets including Tom’s Hardware, Risky Business and Cybernews, the cameras would hand remote shell access to anyone who sent them a text message from a set of hardcoded Russian phone numbers.

Sit with that. A device bought to enforce the law, sitting on a public road, that a foreign operator could open with an SMS. The paperwork was in order. The certification was on file. And the device was, by the security authority’s account, remotely controllable by design.

This is the exact scenario supply-chain security exists to prevent, and the exact scenario a procurement checklist cannot catch.

Nobody reads firmware in a purchase order. The only discipline that finds a thing like this is the one that treats the device as hostile and tries to break it before deployment — which is what supply chain penetration testing is.

We want to be precise about our footing here. SelfHack AI was not involved in the Slovak assessment. What follows is analysis of a public incident, and a walk through how autonomous testing surfaces this exact class of finding. The lesson is not “trust us.” The lesson is “test the hardware you trust.”

Anatomy of the backdoor: an SMS, a disabled SecureBoot, an open stream

The reported technical findings read like a worst-case exam question. Three of them matter most, and each one is independently damning.

The SMS shell. The cameras reportedly contained an undocumented module that granted shell and network access when it received a text from one of a list of hardcoded Russian phone numbers — twelve of them, according to several outlets. That is not an exploit an attacker had to find. It is a control channel that shipped in the box.

SecureBoot switched off. The NBÚ report describes SecureBoot as disabled, meaning the firmware’s origin was never enforced. In plain terms: the device would run whatever firmware it was given, with no cryptographic check that the code came from someone trustworthy. Every other protection sits on top of that missing foundation.

Passwordless live video. The cameras reportedly exposed their live streams to anyone who knew the broadcasting IP address — no password, no authentication. A surveillance device that surveils for whoever asks.

Add the multiple reported vulnerabilities in the web management portal, and you do not have one flaw.

You have a device where the security model was never really there. This is the difference between a vulnerability and a backdoor, and it is exactly what supply chain penetration testing is built to tell apart.

The rebrand-and-shell-company playbook

The most instructive part of this case is not the firmware. It is how the firmware got onto a public road with a stamp of approval.

According to the reporting, the NERO R-ONE cameras were rebranded versions of a Russian device — the CORDON PRO.M, made by a St. Petersburg firm named Semicon. The rebrand put a neutral-sounding name on a device with a very specific origin. The procurement then ran through a Cyprus-based shell company that, per the reports, presented fake certifications. And the whole thing was funded through a roughly €30 million EU-backed modernization program.

Read that chain again, because it is the template.

A sensitive-origin manufacturer, a rebrand to launder the name, a shell company to launder the paperwork, and a legitimate public fund to pay for it.

Every layer was designed to make the device look like a normal purchase. On paper it was. That is the entire point of the technique.

This is why supply-chain risk is not a documentation problem. You cannot audit your way out of it with better forms, because the forms are the attack surface. The reporting even suggests similar devices were installed in Croatia and possibly elsewhere in Eastern Europe — one laundered supply chain, many buyers. A paperwork check scales the problem. Only testing the physical device breaks the chain.

That is the one thing supply chain penetration testing does that no audit can: it checks the silicon in your hand, which is the single link in the laundered chain that cannot be forged.

A certificate proves compliance, not security

Let’s say the uncomfortable thing directly. A certification tells you a device passed a defined set of checks at a defined moment, usually against paperwork the vendor supplied. It does not tell you the device is safe, and in this case the certifications were reportedly fake anyway.

Compliance and security are not the same discipline, and the gap between them is where this backdoor lived.

Compliance asks “does the documentation say the right things?” Security asks “what happens when I treat this device as an adversary would?” The first question was answered yes. The second was never asked until the NBÚ asked it.

Supply chain penetration testing is just the discipline of asking that second question — on every device, before it ships, not after it fails.

This is the same lesson our avionics penetration testing research reached from the opposite end of the risk spectrum: a certification cycle measured in years cannot bound a threat that ships inside the product. Whether it is a fighter jet or a roadside camera, the paperwork is not the proof. The test is the proof.

What supply chain penetration testing actually checks

So what would have caught this? Not a form. A real supply chain penetration testing engagement treats a procured device as untrusted hardware and interrogates it across the layers where a backdoor can hide. Done well, supply chain penetration testing is less an audit than a controlled break-in against your own purchase. Five layers matter here.

• Firmware provenance and boot integrity — is SecureBoot actually enforced? Is the firmware signed, and does the device refuse unsigned code? A disabled SecureBoot is a finding on its own.
• Hidden control channels — enumerate every interface, including cellular and SMS-capable modems, and test for undocumented command paths. The SMS shell lives here.
• Exposed services and default credentials — scan for unauthenticated streams, open management portals, and passwordless access. The open video feed lives here.
• Web and API surface — the management portal, tested the way an attacker meets it, not the way the manual describes it.
• Provenance and attestation — can the device prove what it is and what it is running, or are you trusting a sticker? Rebrands defeat stickers, not attestation.

None of these is exotic. Each one, run against these cameras, points straight at a reported finding. That is the uncomfortable takeaway: this was findable. It simply was not looked for, because the process trusted the paperwork instead of the device.

Deep dive: how SelfHack AI would have surfaced every finding

This is the part worth slowing down on, because “run a pentest” is too vague to be useful. Here is concretely how an autonomous system like SelfHack AI works a device like this, mapped to what the NBÚ actually reported. We are describing capability and method, not claiming we tested these specific units.

Supply chain penetration testing maps the whole device, not the documented parts. The agent enumerates every interface the hardware exposes — network, web, and crucially the radio and cellular side. A documented camera has an IP port. This device also had an SMS-reachable modem. An autonomous surface map does not care what the datasheet lists; it catalogs what the silicon actually answers on. That is the step that surfaces an undocumented SMS control channel in the first place.

It hypothesizes hostile behavior and tests it. Given a cellular modem on a camera, the agent asks the obvious adversarial question — can this device be commanded out-of-band? — and builds a safe test for it. It sends controlled probes and watches for a response no honest camera should give. A shell that answers a text message is exactly the kind of hypothesis a reasoning agent generates and a checklist never contains.

It verifies the foundation before the features. The agent checks boot integrity first: is SecureBoot enforced, is firmware signed, does the device reject unsigned code? A disabled SecureBoot is flagged immediately, because everything above it is untrustworthy without it. This is the same trust-boundary logic behind our confidential computing research — attestation is not a feature, it is the floor.

Boot integrity is where supply chain penetration testing starts for exactly this reason — a device that will run any firmware has no security worth testing above it.

It meets services the way an attacker does. The agent connects to the video stream and the management portal with no credentials and simply asks what it can reach. A passwordless live feed answers. An open portal answers. These are not subtle findings once something actually knocks on the door without a key.

It chains the findings into an impact story. Individually, each flaw is a bullet point. Chained, they are a controlled remote takeover: SMS in, shell obtained, firmware replaceable because SecureBoot is off, video exfiltrated because the stream is open. A good supply chain penetration testing report does not hand you ten findings; it hands you the one operation those findings enable.

Continuous testing: the reason you would not have been late

Here is the argument that matters most, and it is not about any single check. It is about timing.

The Slovak cameras were, by all accounts, tested once — at certification — and then trusted. That is the model almost everyone runs: assess at procurement, sign off, deploy, move on. It fails for a simple reason. A device’s security is not a fact you establish once; it is a state that changes with every firmware update, every configuration drift, every supplier you cannot see behind.

Continuous supply chain penetration testing flips that. Instead of one certificate at the gate, the device is re-interrogated on ingest, on every firmware change, and on a standing schedule after deployment. The SMS backdoor that a one-time cert waved through gets caught the first time an autonomous system actually knocks on the cellular interface — and every time after that, too.

This is the same structural point we made in what manual pentests miss: a point-in-time human assessment cannot keep pace with a surface that changes faster than the test cycle.

A backdoored supply chain is that problem in its purest form. If you had been testing these devices continuously, you would not have been reading the finding in a news bulletin a year after installation. You would have found it on day one, on your own terms, before the concrete was poured around the pole.

How SelfHack AI runs supply chain penetration testing

Everything above is why SelfHack AI is built as an autonomous system rather than a faster checklist. A single device has a network surface, a web surface, a radio surface, a firmware surface, and a provenance question — and a modern estate has thousands of such devices. No human team re-tests all of that on every update. Nothing human-paced can — which is the whole case for autonomous supply chain penetration testing.

SelfHack AI treats each device the way this analysis treats the cameras: as untrusted hardware to be interrogated, not documentation to be filed. It maps the real surface, generates adversarial hypotheses about how trust could be misplaced, tests them in isolation, corrects itself when the evidence disagrees, and chains what it confirms into a real impact story. Then it does it again on the next change, because that is what continuous means.

In practice, that is what makes supply chain penetration testing a control rather than an event: it runs at the speed the supply chain actually changes.

The reach is the point. The same engine tests a roadside camera, a fleet of connected vehicles, and an external attack surface full of exposed devices with the same question underneath: what does this thing trust, and what happens when that trust is misplaced? A laundered supply chain is just that question wearing a fake certificate.

How to scope a supply chain penetration testing engagement

If you buy hardware — cameras, sensors, controllers, network gear, anything with firmware — a real supply chain penetration testing engagement starts with three honest questions.

First, are you testing the device or reviewing its documents? If the answer involves a certificate rather than a lab bench, you are doing compliance, not security. Second, does the test cover the whole device — network, web, radio, firmware, boot — or just the network port that is easy to reach? The Slovakia backdoor lived on the interface nobody thought to check. Third, is it once or continuous? A device trusted at procurement and never re-tested is a device you are trusting on faith after its first update.

None of this is unique to traffic cameras or to Slovakia. It is the shape of every hardware supply chain, and supply chain penetration testing is the same discipline whether the device is a building access controller, a medical device, or national infrastructure. The platform changes; the question does not. If you want to see what an autonomous assessment surfaces on the devices you have already deployed, talk to our team.

FAQ

What is supply chain penetration testing?

It is the practice of treating a procured product — hardware, firmware, or software — as untrusted and testing it the way an adversary would, to find backdoors, hidden control channels, and hidden weaknesses before you deploy it. Unlike a certification review, which checks documentation at a point in time, it interrogates the actual device across every layer where a compromise can hide.

Did SelfHack AI discover the Slovakia camera backdoor?

No. The backdoor was reported by Slovakia’s National Security Authority (NBÚ) and covered by security outlets. This article is analysis of that public incident and an explanation of how autonomous testing surfaces this class of finding. We are careful about that line: the lesson here is the method, not a claim of credit.

How could a certified device have a backdoor?

Because certification checks compliance against documentation, not security against an attacker — and in this case the certifications were reportedly fake. A rebranded device from a sensitive-origin manufacturer, routed through a shell company with forged paperwork, can look completely normal on a purchase order. The only thing that catches it is testing the physical device, not the file about it.

Would continuous testing really have caught this?

An SMS-triggered shell, a disabled SecureBoot, and a passwordless video stream are exactly the findings an autonomous assessment is built to surface — they are not subtle once something actually probes the device instead of trusting it. The larger point is timing: continuous testing re-checks on every firmware change and on a schedule, so a backdoor is caught on ingest rather than a year into deployment.

Does this only matter for governments and critical infrastructure?

No. Any organization that buys hardware with firmware — access control, cameras, sensors, network equipment — inherits the same supply-chain risk. The Slovakia case is vivid because it is public infrastructure, but the rebrand-and-shell-company technique works against any buyer who trusts the paperwork instead of testing the device.

The verdict: hack yourself first

The Slovakia cameras are not really a story about Russia, or about cameras. They are a story about trust — specifically, about what happens when you outsource trust to a certificate instead of earning it with a test. A hostile supplier does not need to breach your network if you install their device on your road yourself.

That is the shape of the current threat, and it scales all the way up. Europe’s own security agencies have spent the last two years describing a campaign of grey-zone sabotage against critical infrastructure, and hardware is one of its cleanest vectors, because it arrives through the front door with an invoice attached. For infrastructure that has to survive a hostile supplier — the alliance-grade, keep-the-lights-on kind — a certificate at purchase is not a security model. It is a hope.

The only sustainable model is the one SelfHack is named for: hack yourself, continuously, before someone else does. Assume the device is hostile. Test it like an adversary. Re-test it on every change. The organizations that make that their default will find their backdoors on a lab bench.

The ones that trust the paperwork will keep finding them in the news. If you would rather be the first kind, let’s test what you’ve deployed.

Sources & further reading: reporting on the Slovak NBÚ findings by Tom’s Hardware, Risky Business and Cybernews. Supply-chain testing guidance: NIST SP 800-161 (C-SCRM) and the MITRE ATT&CK framework. Analysis of a public incident; SelfHack AI was not involved in the Slovak assessment.