--- title: Does Your New Camera Come with a Backdoor? description: We tested an off-the-shelf camera for vulnerabilities and saw how little it takes to plant a backdoor ourselves. image: https://avantguard.io/hubfs/Blog/Kamera_1/root_shell_backdoor.png --- [Skip to content](https://avantguard.io/en/blog/kommt-ihre-neue-kamera-mit-backdoor#main) [![avantguard cyber security](https://avantguard.io/hs-fs/hubfs/LogoInverted.png?width=128&height=61&name=LogoInverted.png)](https://avantguard.io/en/) - [Services](https://avantguard.io/en/services) - [About Us](https://avantguard.io/en/about-us) - [Experience](https://avantguard.io/en/experience) - [Career](https://avantguard.io/en/careers) - [Research](https://avantguard.io/en/blog) - [Contact](https://avantguard.io/en/contact) [DE](https://avantguard.io/blog/kommt-ihre-neue-kamera-mit-backdoor) EN [Request an offer](https://avantguard.io/en/request-an-offer) [DE](https://avantguard.io/blog/kommt-ihre-neue-kamera-mit-backdoor) EN [Request an offer](https://avantguard.io/en/request-an-offer) [← All posts](https://avantguard.io/en/blog) - [Offensive](https://avantguard.io/en/blog/tag/offensive) - [Research](https://avantguard.io/en/blog/tag/research) - [Review](https://avantguard.io/en/blog/tag/review) # Does Your New Camera Come with a Backdoor? [![](https://avantguard.io/hs-fs/hubfs/AboutUs/C93A8682_blog.png?width=40&height=40&name=C93A8682_blog.png) Timofey Shpakov](https://avantguard.io/en/blog/author/timofey-shpakov) October 29, 2026 17 min read ![](https://avantguard.io/hs-fs/hubfs/Blog/Kamera_1/root_shell_backdoor.png?width=1600&name=root_shell_backdoor.png) How do you know the camera you just unboxed is running exactly the software its manufacturer shipped? We compromised an off-the-shelf security camera. No soldering iron, no special equipment, no access to the hardware. The manufacturer's own update feature was all it took. It started with our own procurement. We needed new wireless cameras and tested them before deployment, just as we advise our clients to do. We were looking for attack surface and vulnerabilities, not backdoors. What stood out instead was how little it would take to plant one. We are not naming the manufacturer. The specific findings are going through coordinated disclosure, and we will publish technical details once the deadline has passed or a patch is available. **Why procurement is a security issue** We started with a threat model: What actually needs protecting here? Where do the trust boundaries run? And who could realistically get to the devices? In our case, the assets were the video stream, the archive on the receiver, and the receiver's credentials. The attack surface consisted of the radio link and the receiver's web interface. Neither the cameras nor the receiver have access to the corporate LAN or the internet. That left two realistic attacker models: physical access to a camera inside the building, and an attacker within radio range who never has to set foot inside. Many companies have a different setup, because they connect the receiver to the corporate network for monitoring or remote access. Figure 1 shows this variant as "optional." ![threat-model-topologie](https://avantguard.io/hs-fs/hubfs/Blog/Kamera_1/en/threat-model-topologie.png?width=758&height=481&name=threat-model-topologie.png) *Figure 1: In our setup, there is no uplink to the corporate LAN.* Where that uplink exists, the attack surface extends beyond the receiver room into the corporate network. At home, the same camera is set up differently: connected to the home Wi-Fi on its own, linked to a manufacturer cloud account, and controlled remotely through an app. The trust boundaries run differently than in a corporate setup. ![setup-zuhause](https://avantguard.io/hs-fs/hubfs/Blog/Kamera_1/en/setup-zuhause.png?width=758&height=364&name=setup-zuhause.png) *Figure 2: At home, the critical boundary lies between the router and the manufacturer cloud. Owners usually have no visibility into what crosses it.* Both models share a property that is routinely underestimated. Every one of these boundaries describes the device in operation, and operation begins at deployment. Whatever happened before that isn't part of any model. Security for connected devices is usually treated as an operational matter: segment the network, set passwords, install updates. That's right, but it can come too late, and some of it can't be fixed afterward. Whether a device cryptographically verifies its firmware is not something you can retrofit. If you don't make it a purchasing criterion, you buy the gap along with the device, and all you can do afterward is work around it. An assumption that isn't made explicit can't be verified. So we made ours explicit and put the device on the bench before deploying it. ## **Day zero: what happens before deployment** Between the factory and its final location, a device can change hands several times, depending on the procurement path: through distribution, retail, or returns processing. Each handover is an opportunity for tampering.  ![lieferkette-firmware](https://avantguard.io/hs-fs/hubfs/Blog/Kamera_1/en/lieferkette-firmware.png?width=758&height=372&name=lieferkette-firmware.png) *Figure 3: Possible points of tampering along the supply chain. The highlighted marker at the manufacturer stands for a backdoor installed at the factory.* ENISA, the EU's cybersecurity agency, breaks down these stages and the corresponding countermeasures in its [guidelines on IoT supply chain security](https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Report%20-%20Guidelines%20for%20Securing%20the%20Internet%20of%20Things.pdf), from product design and assembly through distribution and logistics to repair and recycling. For attackers, intercepting a single shipment is the less attractive option. It takes effort. Things get easier when attackers occupy one of these stages themselves, as a reseller, for example, and get entire batches into their hands. But the real draw is that a device bought through regular retail channels goes onto the network unchecked, because the retailer's name comes with built-in trust. A well-known electronics retailer seems more trustworthy as a source than any signature check that actually took place. This becomes especially clear with returns that go back on sale as "like new." Such a device was once entirely in someone else's hands, and afterward nobody compares its firmware against the original. ## **What we did to our camera** We followed the OWASP Firmware Security Testing Methodology. The assessment targeted the device's attack surface; we weren't searching for a backdoor. The finding corresponds to I4 of the OWASP IoT Top 10, *Lack of Secure Update Mechanism*, which covers missing firmware verification on the device itself. It took five steps. 1. **Get the official firmware.** The manufacturer offers firmware for its entire product line as a public download, with no customer account or serial number required. That's not a flaw in itself; it makes updates easier. But it also means analysis can start with zero effort. The process begins with an entirely legitimate artifact. 2. **Unpack the image.** The update comes in a vendor-specific container holding several file systems. Standard, freely available tools can take it apart. The real work lies in recording every parameter during unpacking. Without those values, you can't reassemble the image in a form the device will accept. 3. **Make the change.** In the unpacked file system, you can specify what runs at boot. For the proof of concept, a single additional service giving us remote access to the device was enough. Because the change is part of the boot process, it survives every reboot and every factory reset. 4. **Repack and recalculate the checksum.** The file systems are rebuilt with the recorded parameters and embedded again. What matters is what doesn't happen at this step. The image's integrity was protected only by a checksum, and a checksum can simply be recalculated after any change. What's missing isn't a stronger checksum, but a signature through which the manufacturer vouches for the image. 5. **Install it through the regular update feature.** The image is uploaded through the camera's web interface while logged in with administrative privileges. The device accepted the modified image, verified the checksum, found it valid, and booted from it. ![root\_shell\_backdoor](https://avantguard.io/hs-fs/hubfs/Blog/Kamera_1/root_shell_backdoor.png?width=828&height=483&name=root_shell_backdoor.png) *Figure 4: The proof of concept. Connecting to the configured port is all it takes to get a root shell.* The remarkable thing isn't any single step, but how little it took overall. This was a pure software attack. The case stayed closed. We needed no programming adapter, no serial console, no special equipment, and no unusual expertise, just the update path the manufacturer built in. There's one prerequisite we've left out so far: the update feature requires administrative privileges. In operation, that's an effective safeguard, since network access alone isn't enough to take over a camera this way. But if a device is intercepted before installation, the attacker is the administrator anyway. They install the backdoor and then perform a factory reset. The result is a camera in its out-of-the-box state, with the backdoor still running. ## **Why network segmentation alone isn't enough** One possible objection: the cameras sit on their own network with no route to the internet, so attackers couldn't communicate with the outside world. Segmentation is still sensible network hardening, and every setup like this belongs on its own VLAN. But it assumes the camera only uses the paths you configured for it. Many wireless models come with their own radio channel, which modified firmware can use. Segmentation controls the cable, not the air. ![exfiltration-rf](https://avantguard.io/hs-fs/hubfs/Blog/Kamera_1/en/exfiltration-rf.png?width=758&height=569&name=exfiltration-rf.png) *Figure 5: Both variants bypass the blocked uplink through the camera's radio interface.* In variant A, attackers only need to be within radio range, for example in a vehicle parked outside. During a physical break-in, that means a live view of the interior, while network segmentation remains fully intact. Variant B doesn't even require anyone nearby. The device scans for open networks in the area, such as a guest network or a neighbor's network, connects on its own, and uses that route to the outside. Neither is easy to spot on the device itself. How well it can be hidden depends on the layer where the modification sits. ## **How deep a backdoor can go** Our own backdoor was deliberately simple, and correspondingly conspicuous. It lived as an additional service in the file system and was loaded at boot. Anyone looking for it would find it without much effort. It doesn't have to be that way. The same functionality can be anchored much deeper, and with each layer, it gets harder to detect with software tools. The following overview is a classification, not an exhaustive list. | **Layer** | **What it enables** | **What's most likely to give it away** | | --- | --- | --- | | File system (our proof of concept) | An additional service that runs at boot | Process list, open port, comparison against the original image | | Kernel module | Can hide connections and interfaces from the usual tools, so the system looks clean while traffic flows | Practically only a file comparison against the original | | Built into the kernel | The same without a loadable module, independent of module signing and resistant to checks that only look at module directories | Most likely a comparison of the kernel image itself | | Wi-Fi chip firmware | Can transmit while the operating system considers the interface inactive | Over-the-air measurements, side effects such as power consumption | | Additional hardware | The modification doesn't show up in software at all | Usually only a physical inspection | The Wi-Fi chip deserves a note, because it's often overlooked. It has its own firmware and memory and operates below the operating system. Working at this level takes significant, chip-specific effort, but the layer is real and well documented. The Nexmon project has shown for years that the firmware of common Wi-Fi chipsets can be extended with custom functionality. The last row of the table marks the limit of our approach. No firmware comparison helps against added hardware. ## **Two real-world examples: Ledger and Trezor, October 2026** In October 2026, this played out with hardware wallets, devices whose sole purpose is keeping keys secure. The two largest manufacturers were affected, in two different ways. **Ledger: added hardware** Starting October 9, users reported funds draining from their wallets. A day later, Ledger confirmed an unauthorized implant in an affected device. All confirmed losses involved devices sold through CryptoBilis, an authorized reseller in Southeast Asia. The devices themselves were genuine. Somewhere on the way to the customer, they were opened, the battery was swapped for a smaller one, and an additional module was fitted into the freed-up space: a microcontroller with a cellular modem and an eSIM. During setup, the module captured the 24-word seed phrase from the display and sent it to the attackers over LTE. Depending on the source, damage estimates range from about $86 million to more than $100 million. Ledger itself hasn't confirmed a figure. What matters is what didn't happen. The firmware and the secure element were untouched, and the manufacturer's authenticity check passed. Segmentation wouldn't have helped either, because the implant brought its own uplink. It needed neither an open Wi-Fi network nor attackers within radio range. **Trezor: swapped chip with modified firmware** Shortly afterward, journalist Kim Zetter reported in her newsletter *Zero Day* that Trezor devices had been tampered with as well. Security researcher Joe Grand had examined two such devices, bought through Facebook Marketplace and a TikTok shop, and had alerted Trezor back in August. Here, the tampering also reached the firmware. The attackers replaced the microcontroller with their own chip running modified firmware. Trezor's code is open source. Instead of a random seed phrase, the device generated one of about a dozen predetermined phrases known to the attackers. For the integrity check, it presented a copy of the original firmware from an additional microSD card and only then switched to the modified code. The process essentially mirrors our own proof of concept: get the official firmware, modify it, and install it so the device accepts it. Here, too, freely available code was enough, and here, too, the tampering wasn't visible from the outside. The fact that the check was also fooled with the original mainly shows that a check is only as good as the source it relies on. **How retailers responded** MediaMarkt Saturn stopped selling Ledger devices after a customer in Germany reported a tampered unit. In Switzerland, Digitec Galaxus pulled all Ledger products from its range as a precaution on October 16, even though it had no indication of affected devices. Trezor announced it would end its reseller authorizations as of January 1, 2027. Even a large retailer can't easily verify the integrity of the goods it sells. In both cases, the device passed the very check its manufacturer had designed for that purpose. ## **The other case: when the backdoor comes from the factory** So far, we've looked at modifications made on the way to the final location. A different case is a backdoor shipped by the manufacturer itself, the highlighted marker in Figure 3. The distinction matters in practice, because the two cases leave different traces. A firmware modification made in transit deviates from the official image. It can be detected by comparing against a trusted reference, provided you read out the firmware yourself. A backdoor shipped from the factory, on the other hand, is part of the original. A reference comparison won't flag it, because there's nothing for it to deviate from. On top of that, such functionality is hard to distinguish from an ordinary implementation bug. The intent behind it is practically never provable. What remains in this case is looking at behavior: What services does the device offer? Where does it connect to? What functions does it have that it doesn't need for its purpose? ## **A real-world example: Slovakia, August 2026** In August 2026, Slovakia showed that this case isn't just theoretical. The country's National Security Authority (NBÚ) issued a formal warning about several types of traffic enforcement cameras after analyzing one of the devices. The authority lists four points: - unclear actual origin of the hardware and software - discrepancies between the documented and the actual configuration of the communication interfaces - preconfigured remote access and remote management mechanisms whose configuration isn't fully accessible to the operator - insufficiently secured software Media reports add technical details that aren't in the warning itself: access to the device that can be triggered by SMS from hardcoded phone numbers, no secure boot, and live streams accessible without authentication. The devices had been supplied through an intermediary company. The Ministry of the Interior ended its cooperation with the supplier and had the units in trial operation removed. For buyers, one detail is crucial. What had been checked was the paperwork, not the device. The functionality only came to light when someone put a device on the bench and looked at what it actually does. ## **Checklist for procurement and deployment** In practice, this means checking before deployment, not after. 1. **Verify firmware against a trusted reference before deployment**, rather than relying on the delivery path. Where possible, read out the firmware yourself instead of trusting what the device reports about itself. This covers tampering in transit. It doesn't help against functionality shipped from the factory, and it doesn't help against added hardware. 2. **Use behavior as a second layer of verification**, since it covers both cases. Record and document open services, connection targets, and radio behavior while the device is still new. That baseline becomes your benchmark later. 3. **Make signed firmware and secure boot a procurement criterion** that is verified, not just promised. Questions to ask: Is the signature checked on every boot, or only during updates? Is there rollback protection? Are the eFuses locked? For radio equipment on the EU market, these requirements have been mandatory since August 1, 2025, anyway. 4. **Treat returns, used devices, and goods from intermediaries separately.** A device that has been entirely in someone else's hands shouldn't go onto the network unchecked. With large quantities, full inspection is rarely practical. Spot checks will reveal systematic deviations, but not a single, deliberately prepared unit. Inspect devices for sensitive areas individually. 5. **Inspect devices physically, too.** Open a sample and compare components, battery, and weight against a reference device. Intact packaging is no proof, and neither is a passed manufacturer authenticity check. 6. **Segment, but don't forget the radio side.** A dedicated VLAN is still the right call. Add a baseline of expected radio behavior, including cellular, and watch for devices searching for networks they don't need. In sensitive zones, prefer devices without built-in radio interfaces, and where none are available, put the wired camera in a Faraday enclosure. 7. **Secure contractually what can't be enforced technically:** an SBOM (software bill of materials), a committed update period, a vulnerability disclosure process, and the right to analyze the firmware yourself. ## **No reason to panic, but every reason to check** None of this means every device is compromised. It means a device's integrity remains an assumption, not a fact, until someone verifies it. If you don't check, you're trusting the manufacturer, the retailer, and every stop along the way. Compared to the damage a compromised device can cause, the effort of checking is small. Our cameras have since been tested, segmented, and put into operation. If you'd like your own devices or a planned setup tested the same way, contact us at [research@avantguard.io](mailto:research@avantguard.io). --- ## **Sources and further reading** **On the Ledger and Trezor cases** - Ledger: [Update from Ledger Donjon on the CryptoBilis investigation](https://x.com/Ledger/status/2109896739985453358), X, October 13, 2026 - CoinDesk: [Ledger says 'spy' chip inside CryptoBilis Ledger devices transmitted wallet keys over mobile network](https://www.coindesk.com/tech/2026/10/13/ledger-says-spy-chip-inside-cryptobilis-ledger-devices-transmitted-wallet-keys-over-mobile-network), October 13, 2026 - BleepingComputer: [Ledger confirms spy chip implant behind wallet crypto thefts](https://www.bleepingcomputer.com/news/security/ledger-confirms-hardware-wallet-spy-implant-behind-crypto-thefts/), October 2026 - CryptoSlate: [Ledger wallet implant exposes a gap in its authenticity check](https://cryptoslate.com/ledger-confirms-hidden-implant-in-crypto-wallet-as-93-million-theft-investigation-widens/), October 2026 - Kim Zetter, Zero Day: [Trezor Wallets Also Compromised with Implants](https://www.zetter-zeroday.com/trezor-wallets-also-compromised-with-implants/), October 2026 - Hackaday: [This Week in Security: Record Patch Tuesday, PHP's Bad Time, The Oldest Vuln, AI Armies, And More](https://hackaday.com/2026/10/23/this-week-in-security-record-patch-tuesday-phps-bad-time-the-oldest-vuln-ai-armies-and-more/), October 23, 2026 - Yahoo Tech: [Trezor Cuts Its Resellers After Ledger Finds Spy Implant in Crypto Wallets](https://tech.yahoo.com/cybersecurity/articles/trezor-cuts-resellers-ledger-finds-161450621.html), October 2026 - Digitec Galaxus: [Galaxus removes Ledger wallets from its range as a precaution](https://www.digitec.ch/en/page/galaxus-removes-ledger-wallets-from-its-range-as-a-precaution-44116), October 16, 2026 **On the Slovakia case** - Národný bezpečnostný úrad (NBÚ): *Varovanie pred významnou kybernetickou hrozbou: cestné rýchlomery s kamerou.* Formal warning under the Slovak Cybersecurity Act (Act No. 69/2018 Coll.), August 14, 2026, nbu.gov.sk. Full text reproduced by, among others, [STVR](https://spravy.stvr.sk/2026/08/dopravne-radarove-kamery-predstavuju-vyznamnu-kyberneticku-hrozbu-uviedol-nbu) - Risky Business Media: [Risky Bulletin: Slovakia finds Russian backdoor in traffic speed cameras](https://news.risky.biz/risky-bulletin-slovakia-finds-russian-backdoor-in-traffic-speed-cameras/), August 2026 - TASR: [Rezort vnútra: Zisteniami NBÚ o dopravných kamerách sme sa zaoberali](https://www.teraz.sk/slovensko/rezort-vnutra-zisteniami-nbu-o-doprav/984986-clanok.html), August 14, 2026 **Standards and guidelines** - [ETSI EN 303 645: Cyber Security for Consumer Internet of Things, Baseline Requirements, V3.1.3 (2024-09)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf) - [ENISA: Guidelines for Securing the Internet of Things, Secure Supply Chain for IoT](https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Report%20-%20Guidelines%20for%20Securing%20the%20Internet%20of%20Things.pdf) - Commission Delegated Regulation (EU) 2022/30 supplementing Directive 2014/53/EU (Radio Equipment Directive), applicable since August 1, 2025, and specified by the harmonized standard series EN 18031-1/-2/-3. Full text available on EUR-Lex. **Methodology and research** - [OWASP Internet of Things Project](https://owasp.org/www-project-internet-of-things/) (Firmware Security Testing Methodology, FSTM) and [OWASP IoT Security Testing Guide (ISTG)](https://owasp.org/projects/iot-security-testing-guide) - M. Schulz, D. Wegemer, M. Hollick: [NexMon: The C-based Firmware Patching Framework for Broadcom/Cypress WiFi Chips](https://github.com/seemoo-lab/nexmon), Secure Mobile Networking Lab, TU Darmstadt. Foundational paper: [NexMon: A Cookbook for Firmware Modifications on Smartphones to Enable Monitor Mode](https://arxiv.org/abs/1601.07077), arXiv:1601.07077 Contents - [Offensive](https://avantguard.io/en/blog/tag/offensive) - [Research](https://avantguard.io/en/blog/tag/research) - [Review](https://avantguard.io/en/blog/tag/review) ![](https://avantguard.io/hs-fs/hubfs/AboutUs/C93A8682_blog.png?width=40&height=40&name=C93A8682_blog.png) Written by [Timofey Shpakov](https://avantguard.io/en/blog/author/timofey-shpakov) Research ## Related posts [![](https://avantguard.io/hs-fs/hubfs/Blog/BlueHammerRedSun/bluehammer-1.png?width=800&name=bluehammer-1.png)](https://avantguard.io/en/blog/bluehammer-und-redsun-analysiert) - [Offensive](https://avantguard.io/en/blog/tag/offensive) - [Red Team](https://avantguard.io/en/blog/tag/red-team) - [News](https://avantguard.io/en/blog/tag/news) ### [BlueHammer and RedSun analysed](https://avantguard.io/en/blog/bluehammer-und-redsun-analysiert) This article takes a closer look at two recent vulnerabilities, BlueHammer and RedSun, and explains why they have attracted so much attention. [Andrei Herasimau](https://avantguard.io/en/blog/author/andrei-herasimau) June 9, 2026 15 min read [![](https://avantguard.io/hs-fs/hubfs/Blog/Passwortsicherheit%20im%20Browser/title-small.png?width=800&name=title-small.png)](https://avantguard.io/en/blog/klartext-im-speicher-neubewertung-der-passwortsicherheit-im-browser) - [Offensive](https://avantguard.io/en/blog/tag/offensive) - [Research](https://avantguard.io/en/blog/tag/research) - [Cleartext Credentials](https://avantguard.io/en/blog/tag/cleartext-credentials) ### [Plaintext in Memory: Revisiting Browser Password Security](https://avantguard.io/en/blog/klartext-im-speicher-neubewertung-der-passwortsicherheit-im-browser) This blog post shows how browsers expose passwords in memory and how they can potentially be extracted. [Christian Bieg](https://avantguard.io/en/blog/author/christian-bieg) May 22, 2026 3 min read [![](https://avantguard.io/hs-fs/hubfs/image-3-png.png?width=800&name=image-3-png.png)](https://avantguard.io/en/blog/erfahrungsbericht-ki-gestützte-bof-entwicklung-im-red-team) - [Offensive](https://avantguard.io/en/blog/tag/offensive) - [AI](https://avantguard.io/en/blog/tag/ai) ### [Experience Report: AI-Assisted BOF Development in Red Teaming](https://avantguard.io/en/blog/erfahrungsbericht-ki-gestützte-bof-entwicklung-im-red-team) This blog post details my experience utilizing artificial intelligence in offensive cybersecurity to port a current LSASS dumping tool into a Beacon Object File (BOF) for use in a ... [Sandro Ackermann](https://avantguard.io/en/blog/author/sandro-ackermann) April 8, 2026 7 min read ## Wie sicher sind Ihre Systeme wirklich? Erzählen Sie uns von Ihrem Vorhaben. Sie erhalten ein unverbindliches Angebot. [Offerte anfragen](https://avantguard.io/offerte-anfragen) [+41 55 253 30 30](tel:+41552533030) [![avantguard cyber security](https://avantguard.io/hs-fs/hubfs/LogoInverted.png?width=140&height=66&name=LogoInverted.png)](https://avantguard.io/en/) avantguard cyber security AG Neue Jonastrasse 52 8640 Rapperswil-Jona, Switzerland [+41 55 253 30 30](tel:+41552533030) [info@avantguard.io](mailto:info@avantguard.io) ## Company - [Services](https://avantguard.io/en/services) - [About us](https://avantguard.io/en/about-us) - [Experience](https://avantguard.io/en/experience) - [AI at avantguard](https://avantguard.io/en/ai-at-avantguard) - [Careers](https://avantguard.io/en/careers) - [Research](https://avantguard.io/en/blog) - [Contact](https://avantguard.io/en/contact) ## Services - [Penetration Testing](https://avantguard.io/en/penetration-test) - [Red Teaming](https://avantguard.io/en/red-teaming) - [Attack Simulation](https://avantguard.io/en/attack-simulation) - [FINMA-regulated pentesting](https://avantguard.io/en/finma-regulated-pentesting) - [AD Security Improvement](https://avantguard.io/en/ad_improvement) - [mesher](https://avantguard.io/en/mesher) - [All services](https://avantguard.io/en/services) ## Research - [Does Your New Camera Come with a Backdoor?](https://avantguard.io/en/blog/kommt-ihre-neue-kamera-mit-backdoor) - [The Blind Spot Of 802.1X Network Access Control (NAC)](https://avantguard.io/en/blog/die-blinde-stelle-von-802.1x-network-access-control-nac) - [BlueHammer and RedSun analysed](https://avantguard.io/en/blog/bluehammer-und-redsun-analysiert) - [Plaintext in Memory: Revisiting Browser Password Security](https://avantguard.io/en/blog/klartext-im-speicher-neubewertung-der-passwortsicherheit-im-browser) - [All posts](https://avantguard.io/en/blog) © 2026 avantguard cyber security AG - [Privacy policy](https://avantguard.io/en/privacy-policy) - [Deutsch](https://avantguard.io/)