The Camera Was the Sensor: Hybrid Supply Chains and the New Espionage Surface
Every system you have ever shipped sits inside a larger system you did not design.
Your application depends on libraries. Your library depends on a maintainer account. Your office suite depends on an upstream codebase. Your password manager depends on an update channel. Your loading dock depends on a camera pointed at the road because someone, years ago, wanted to see whether the truck had arrived.
That last one is the part too many security programs still miss.
We built a mental model where “supply chain security” means dependency scanners, SBOMs, package signatures, and maybe a nervous glance at CI/CD permissions. All of that matters. But the battlefield has widened. In modern hybrid warfare, the supply chain is not just the path by which code reaches production. It is the path by which trust, visibility, credentials, firmware, and physical access reach an adversary.
The compromised package steals your token. The compromised password manager waits in your admin network. The compromised office suite carries someone else’s update gravity. The compromised street camera watches the tanks roll past.
Same shape. Different surface.
In July 2026, the Dutch intelligence services AIVD and MIVD warned that Russian state actors were systematically compromising internet-connected IP cameras across the Netherlands, other EU and NATO member states, and Ukraine. The goal was not ransomware. It was military intelligence: transport routes, weapons shipments, Ukrainian troop locations, and the quiet physical rhythm of European support for Kyiv.
This is what supply chain compromise looks like when it stops living entirely inside GitHub.
The Camera Became Part of the Kill Chain
The useful thing about a satellite is that it sees from above. The useful thing about a cheap roadside camera is that it sees from where people actually move.
Space-based reconnaissance has limits: orbital timing, weather, concealment, jamming, cost, and resolution. A publicly reachable IP camera on a business facade has a different weakness profile. It is boring. It is always there. It watches the same road every day. It sees license plates, cargo markings, convoy spacing, escort vehicles, rail sidings, warehouse gates, and the exact moment a shipment leaves a port.
According to the Dutch advisory, Russian operators scan the public internet, identify camera brands and models, and take over devices that still have default passwords, obsolete firmware, exposed admin panels, public video streams, or careless port-forwarding. No magic is required. The enemy does not need a zero-day when the camera is still effectively configured like a demo unit.
Censys’ follow-up analysis put numbers around the exposed surface. In the Netherlands alone, it found 45,386 internet-accessible cameras. Almost 2,000 hosts running those cameras appeared to expose a service matching a known-exploited vulnerability, and 541 matched known-exploited vulnerabilities in camera software itself. Across EU and NATO members plus Ukraine, Censys counted more than 87,000 internet-connected cameras running services with known-exploited vulnerability matches, including more than 4,000 in Ukraine.
Those numbers need a caveat. A service banner is not proof of compromise, and Censys itself is careful about that. But the caveat does not save us. It only tells us the lower bound is messy. The strategic reality is cleaner: Europe has placed a large, searchable, often neglected sensor network along exactly the roads, ports, bridges, depots, and rail lines a military intelligence service cares about.
Inside NATO and EU states, the Dutch services describe the access as espionage: monitoring routes and weapons flows, building military situational awareness, pre-positioning visibility. Inside Ukraine, the line has already crossed into the kinetic loop. The advisory says camera access has been used in attempts to neutralize Ukrainian military personnel and destroy equipment.
That pattern was visible before the 2026 advisory. On January 2, 2024, Ukraine’s SBU said it blocked two hacked Kyiv webcams that Russian special services had used during a missile attack. One was a balcony camera; another watched a residential parking lot. The attackers changed viewing angles, streamed one feed to YouTube, and collected visual information on air defense activity and critical infrastructure. The SBU said it had blocked about 10,000 IP cameras since the start of the full-scale invasion that Russia could have used to correct missile attacks.
And the pattern cuts both ways. In December 2025, Ukraine’s SBU released footage of what it described as an underwater drone strike against a Russian Kilo-class submarine at Novorossiysk. Naval News and Military Times both noted that the footage appeared to come from harbor cameras, suggesting Ukrainian intelligence may have compromised local camera networks to observe the naval base. Russia disputed the damage, and independent verification remained limited, but the operational lesson is still visible: whoever owns the camera owns a slice of the battlespace.
This is the uncomfortable part. A camera is not just an IoT risk. It is a physical-world API.
The Password Manager Was the Supply Chain
If the camera case is about visibility, the Passwork case is about trust branding.
In July 2026, OCCRP and partner outlets reported that Passwork Europe S.L., a Spain-registered password manager marketed as a European product, shared significant technical and historical ties with a Russian counterpart. Passwork advertised itself with “Made in EU” positioning and claimed no affiliation with non-European entities. OCCRP found a more complicated story: Russian co-founders, an original codebase born in Arkhangelsk, similar Russian and European domains registered one day apart, synchronized update timelines, near-identical documentation, a UAE update intermediary, and a Russian Passwork LLC certified by FSTEC and the FSB.
Passwork’s CEO denied any operational relationship between the Spanish company and the Russian counterpart. OCCRP also reported that it found no evidence that the European software contained malicious code, no evidence that data had been compromised, and no proof of illegality. That matters. The correct claim is not “Passwork is malware.” The correct claim is more precise and, for a password manager, almost as serious:
Trust in a password manager is not just cryptography. It is provenance, governance, update control, code review jurisdiction, customer transparency, and the ability to know who can change the thing that holds your keys.
The Russian Passwork product advertises certifications from FSTEC, an agency under Russia’s Ministry of Defense, and the FSB. OCCRP’s experts said such certification can require detailed source-code review by state-accredited labs, including review for vulnerabilities or undeclared capabilities. That does not prove a backdoor. It does mean the state may gain deep knowledge of the software’s internals. If a European product shares a codebase origin and receives similar updates through an opaque intermediary, that knowledge becomes a procurement risk even without a smoking gun.
The zero-knowledge argument does not fully resolve this. Client-side encryption is valuable, but it protects stored vault contents only while the client software remains honest. A hostile update does not need to break AES. It can wait until the user decrypts the vault and steal the plaintext or master key at the endpoint.
That is why update channels are sacred ground. SolarWinds taught this lesson at infrastructure scale. Passwork is the same class of question at identity scale: who is allowed to ship new code into the place where all your secrets become readable?
”Sovereign” Software Is Not a Sticker
The Euro-Office story is the same trust problem wearing a different suit.
Euro-Office launched as a European alternative to Microsoft Office and Google Docs, backed by European companies and positioned around digital sovereignty. It was also a fork of OnlyOffice, a Russia-linked open-source office suite. That fact was not hidden. The problem, according to Cybernews’ June 2026 analysis, is how much gravity the old codebase still exerted.
Cybernews analyzed roughly 15,600 changes in the OnlyOffice codebase and found that about 90% were made on Moscow time; when other Russian time zones were included, the figure rose to 99.5%. For Euro-Office itself, the analysis suggested that 98.6% of the document engine and 99.2% of the live service component originated from developers using Russian time zones, while European-authored contributions accounted for roughly 0.5%. Cybernews also reported that after the fork, Euro-Office continued importing selected OnlyOffice changes into server-side collaboration components.
Timezone analysis is not nationality analysis. It is a technical signal, not a passport. OnlyOffice said its team is international and warned against judging software by developer nationality rather than quality, security, and compliance. Nextcloud told Cybernews the codebase had been developed almost entirely behind closed doors in Russia and said the Euro-Office team was reviewing and cleaning it.
That is the fair version of the claim.
But it still leaves a hard engineering question: when a product is marketed as sovereign, what exactly became sovereign? The trademark? The hosting jurisdiction? The consortium? The default document format? The update process? The code review process? The ability to remove upstream influence quickly if geopolitics turns ugly?
If the answer is mostly branding, then sovereignty is cosmetic. And cosmetic sovereignty is dangerous because it makes procurement teams relax before the hard questions have been answered.
This is where Europe’s policy language needs to meet engineering reality. Sovereignty is not where the sales page was translated. Sovereignty is the ability to inspect, build, update, replace, and legally govern the systems you depend on.
The Other Branch: When the Supply Chain Explodes
Not every supply chain attack wants to remain silent.
On September 17 and 18, 2024, pagers and walkie-talkies used by Hezbollah members exploded across Lebanon and Syria. The operation was widely attributed to Israeli intelligence, though Israel did not publicly take responsibility at the time. The devices included pager models associated with Taiwan’s Gold Apollo brand; Gold Apollo said the devices were handled under a licensing arrangement with Hungary-based BAC Consulting. Reporting from outlets including The Guardian, The Washington Post, and Amnesty International described a likely physical supply chain compromise: devices modified or manufactured with small explosive charges and remote detonation capability.
This is the loud branch of the same tree.
The Passwork-style branch wants persistence. The camera branch wants visibility. The Euro-Office branch wants dependency gravity. The pager branch wants shock, casualties, and immediate operational collapse. One hides inside an update channel. One hides inside a CCTV feed. One hides inside a sovereignty claim. One hides inside hardware that the target believes is safer than a smartphone.
Different payloads. Same dependency on trust.
The mistake is treating these as separate categories: cyber espionage over here, software supply chain over there, hardware sabotage somewhere else. Operationally, an adversary does not care about our org chart. They care about which dependency gets them closest to the effect they want.
If the desired effect is surveillance, compromise the camera.
If the desired effect is administrative access, compromise the vault.
If the desired effect is influence over public-sector procurement, compromise the trust story.
If the desired effect is physical destruction, compromise the device before delivery.
Defensive Work That Actually Matters
The Dutch Cybercheck framework gets one important thing right: supply chain risk is layered. It asks organizations to evaluate software, operating systems, firmware, and physical hardware when procuring products from countries with offensive cyber programs. That framing matters because it breaks the spell that “vendor risk” is a questionnaire and “cybersecurity” is a scanner.
For critical environments, I would turn that into a practical review with four uncomfortable questions:
1. What can see us?
Inventory cameras, NVRs, smart doorbells, traffic monitors, parking systems, and vendor-managed sensors. Then ask what they can see: gates, roads, loading docks, server rooms, substations, executive parking, badge queues, rail sidings. A camera pointed at a shipping lane is not a facilities detail. It is intelligence infrastructure.
2. Who can update the thing that holds our secrets?
Password managers, endpoint agents, VPN clients, MDM tools, CI runners, browser extensions, and backup systems deserve special treatment. If compromise of the update channel gives code execution near credentials, the vendor’s ownership, jurisdiction, build pipeline, signing controls, and transparency are not paperwork. They are core security controls.
3. Is our sovereignty operational or theatrical?
For “sovereign” software, require evidence: build reproducibility, code provenance, maintainer governance, dependency origin, security review process, release signing, support jurisdiction, incident disclosure, exit paths, and data portability. A European office address is not a security architecture.
4. What is directly reachable from the internet because nobody remembered it existed?
This is the least glamorous control and still one of the highest leverage. Disable public livestreams. Remove direct internet access to cameras. Kill UPnP. Remove port-forwarding. Put cameras and NVRs on isolated VLANs. Require VPN and MFA for remote access. Patch firmware. Replace end-of-life devices. Use privacy masks or physical lens changes so cameras do not capture public roads, ports, military-adjacent routes, or sensitive loading areas.
The EU Cyber Resilience Act will push some of this into law. Reporting obligations for actively exploited vulnerabilities and severe incidents begin on September 11, 2026, and the wider framework becomes fully applicable on December 11, 2027. Manufacturers will need to design products with cybersecurity requirements in mind, declare support periods, handle vulnerabilities, and report exploited flaws. That is progress.
But compliance will not save the camera already streaming a logistics hub today.
The Takeaway
The old supply chain question was: “Can I trust this dependency?”
The new one is harsher: “What real-world capability does this dependency give someone if I am wrong?”
A package gives code execution. A password manager gives keys. An office suite gives document gravity. A camera gives sight. A pager gives proximity. A firmware updater gives persistence. A vendor shell gives plausible deniability.
Supply chain security is no longer just about proving that the artifact was built correctly. It is about understanding what the artifact can observe, modify, authenticate, update, unlock, or destroy once it is trusted.
The camera on the wall was never just a camera.
It was a sensor in somebody else’s system.