We have some equipment that is linked to PC's. These PC's acquire data from the equipment that they send to a server through an internal network. Furthermore these PC's are used to mediate instructions from network coupled PC's to the equipment. Therefore, they are named acquisition servers. The equipment has no standalone storage drive and only consists of PCBs (printed circuit boards).

There are flash chips present which stores the firmware. And yes, the equipment can write files on the PC containing data like serial number and so on. I actually do not know if it extends further. The equipment only has connection to the network through the acquisition server.

Every once in a while the equipment needs repair. In the past, the external technicians performing the repair just cut the connection to the acquisition servers and put the network cable from the equipment in their own PC's to be able to control the equipment locally.

Now, my local IT security says that we are not allowed to have external technicians coupling their own PC's directly to the equipment. They fear that a virus will infect the PCB's of the equipment and that the infection will be able to spread back to the acquisition server once it is coupled back again. All of the acquisition servers have state-of-the-art antivirus and firewall.

What do you think the risk is that an infection will go from PC to a print board and then back to a PC if any?

  • 2
    If a virus were to be transferred from the tech's computer to the flash memory on the PCB, and the virus were designed to live on that specific PCB and reach out to and infect a general PC, wouldn't the "state of the art" antivirus & firewall solutions protect the rest of the network? Isn't that the purpose of heuristic (and all the other fancy technology) virus detection? Also, how is it that the techs are now supposed to connect to the PCBs in question and repair/upgrade them?
    – FreeMan
    Jul 8, 2021 at 16:40
  • 3
    Theoretically, anything that can store information can store a virus. Jul 9, 2021 at 1:25
  • 14
    Depending on the equipment they're accessing, it has happened before. Read up on Stuxnet: en.wikipedia.org/wiki/Stuxnet. Some time around 2010 the US and/or Israeli intelligence agencies released a virus targetting Iranian nuclear reactors. However the virus has been discovered at powerplants of other countries including the US, Indonesia, India etc. They spread it via external contractors since they don't have direct access to Iranian nuclear reactors. That also explains the other non-intended victims.
    – slebetman
    Jul 9, 2021 at 2:59
  • 2
    What's the interface between the PC and the boards? USB, SPI, I2C, Ethernet...? What kind of chips do they have on them? MCUs? SoCs? Simple sensors?
    – jcaron
    Jul 9, 2021 at 9:58
  • 4
    What are those "PCBs"? SBCs, like Raspberry Pi? Simple microcontrollers (without a (complex) operating system)? Or something else? Can you update your question with some details? (But without "Edit:", "Update:", or similar - the question should appear as if it was written right now.) Jul 10, 2021 at 9:48

4 Answers 4


It's impractical for a PCB to be a vector for malware storage or attacks, but that's because PCBs don't do anything except route electrical signals between components. The components themselves... there's the rub. You say there's "no standalone storage drive" in the equipment, but presumably there's some storage (likely flash storage mounted on the board, or even integrated into one of the components - such as an SOC - mounted on the board) that does things like store firmware and/or configuration data? After all, presumably the technicians are changing something when they connect to the equipment, and those changes persist because it works again when you get it back. Unless the changes are purely physical (replacing, moving, or modifying hardware), there's got to be some editable data stored in the equipment.

Now, whether the risk of a maliciously modified (or unknowingly infected) board attacking your PCs is significant... that's a different question. Some of it depends on the extent to which your software trusts the equipment (can it execute code on the PC? Can it write arbitrary files to the PC storage? Has the software that interacts with this equipment been hardened at all? Is it in any way sandboxed?). Some of it depends on the way the equipment is attached to the network (does it also have Internet connectivity, even indirectly? Is the network it's attached to used for anything else, such as communicating between PCs on your LAN?). Some of it depends on what security is built into the equipment itself (does it require that its firmware be signed? Does it even contain a general-purpose processor, or something such as an FPGA that could be configured into one?). Some of it depends on how trustworthy the technicians are (are they employees of the equipment vendor? What security practices do they follow with their work computers? Would you notice if one of them was replaced with an impersonator wearing a copy of their uniform/badge?).

At the end of the day, if you don't trust the equipment vendor, it's probably not possible to service it at all in a trustworthy way (you'd have to analyze the security implication every step they tell you to take, reverse engineer every firmware blob they have you upload, physically uncap and inspect every chip they have you install with an electron microscope, etc.) although "trust" isn't a binary state and perhaps you trust them enough that you can figure they probably aren't sending you deliberately malicious code, in which case it more comes down to "how good is their security?". If you don't trust the technicians, you might be able to replace them with your own people (or with the vendor's people), but remote troubleshooting is hard and the technicians probably have software and definitely have training that your people lack.

I'd worry far, far more about things like network segmentation (keeping the potentially-vulnerable-or-malicious equipment separate from the Internet and from any other machines), physical security (making sure nobody untrusted gets access to your PCs, network switches, or similar), and employee security (making sure that your people can recognize phishing and other social engineering, using multi-factor authentication for all sensitive accounts, and running background checks + watching for disaffected employees) than about the quality of antivirus on your work PCs... though if they're connected to the Internet, or load third-party code through any other means, endpoint protection is helpful too.

  • 1
    HI, Thank you so much for your fast and thorough reply! yes, there are flash chips present which stores the firmware. And yes, the equipment can write files on the PC containing data like serial no and so on. I actually do not know if it extends further. The equipment only has connection to the network through the acquisition server.
    – Martin
    Jul 8, 2021 at 9:38
  • 3
    The ability to write arbitrary files is easy to turn into arbitrary code execution (a few simple ways: cron files, profile scripts, SSH authorized keys), but if the app is just reading a serial number and writing it to a known location, that would be hard to directly exploit. However, if the code that does this isn't hardened against malicious input, it could have vulnerabilities the developer didn't care about because the equipment is assumed trustworthy.
    – CBHacking
    Jul 9, 2021 at 12:36
  • 1
    @CBHacking depending on what level of control the hardware has, there's also other attack surfaces. I think one iteration of the PS3 was jailbroken by sending malformed USB messages, that exploited the kernel driver (or something like that...). So "just writing a fixed file" can easily turn into something much different, if the hardware is configurable enough.
    – mbrig
    Jul 9, 2021 at 19:01
  • Sure, @mbrig, that's literally exactly the broad class of vulnerabilities I was alluding to with "not hardened against malicious input". Ethernet drivers are well-known attack surface and hopefully not directly vulnerable on a PC, but any complex software that reads the network traffic is pretty likely to have some exploitable flaws even if written in a memory-safe language by a security-conscious development team, and all-but-guaranteed to be exploitable for arbitrary code execution if written in native code by a team who didn't have security on the mind.
    – CBHacking
    Jul 11, 2021 at 0:55

That depends on the specifics of your PCBs, but in the absence of more information, I would follow your IT security team: they know more about them than us on this Q&A website.

It is in theory possible for a targeted attack from a skilled and resourceful attacker to compromise equipment, like your PCB, to infect connected computers. Against such targeted attacks, anti-virus and firewall are mostly useless. The best thing you can do is to enforce a strict air-gap between devices. That's what your IT security team is trying to enforce.

However, this can prevent your external technicians to perform their repairs efficiently. We cannot tell you whether this protection is overkill or justified. To get this answer, your company have to perform threat modelling and a risk assessment of your company and environment (not limited to the IT architecture). Your IT security team might have performed one, justifying their new requirements.

  • Upvote here; as annoying as it can be, there are good reasons to listen to your IT guys (including culpability if you are not following their directives or company policy). And while in general, attacks vs hardware need to be more targeted than attacks against, say, Windows, even custom-built hardware often uses common hardware & software libraries. If your PCB is using a well-known networking library or a popular bootloader that has a vulnerability, then a lot of an attacker's work is done without needing to know the specifics of your PCB. IMHO the risk is low, but "choose your battles"
    – A C
    Jul 8, 2021 at 18:27
  • 4
    I would question that the IT security team would know more (generically) than this community; I'm pretty sure we have some very knowledgeable experts floating around here (next to a bunch of amateurs of course). They will of course know more about your company's specific needs. In any case, I totally second this recommendation. When it comes to targeted attacks, anything is possible. And by anything, I really mean practically anything. If you check some "proof-of-concepts" out there, you'll see how creative people can get, and how they manage to do the impossible. Better safe than sorry.
    – msb
    Jul 8, 2021 at 21:06
  • 2
    As a concrete example of a targeted attack in your situation, a sufficiently motivated attacker could infect your tech's PCs with custom code that rewrites the firmware of your PCBs with targetted attack software so that when you plug it back into your networks it goes about attacking everything it finds with whatever zero-days are in play today. This would require someone to specifically go after YOU though, and invest a ton of time in replicating your specific networks to develop/test the attack. How valuable are you as a target? Do a risk analysis!
    – throx
    Jul 8, 2021 at 21:58
  • If the boards involved are common enough, it doesn't need to be targeted that much, hackers could just spread that attack vector as much as possible hoping it will get to one of those boards eventually. Or, a bit more specifically, they could target all companies selling/installing/maintaining those boards, so it doesn't need to be targeted explicitly at OP's company, but anyone using the same boards.
    – jcaron
    Jul 9, 2021 at 13:29
  • 1
    The IT team may have good reasons for their concern, but at some point, management needs to make a decision. What is the risk of NOT allowing the techs to connect to the equipment? Is there an alternate way to handle it? Would it require giving the repair tech access to a system they otherwise wouldn't have? Can the board be replaced? If so, for how much? And how much do you trust the supplier of the board? Simple black-and-white policies just don't work. At some point there needs to be some human judgement applied.
    – barbecue
    Jul 9, 2021 at 13:57

It really depends a lot on what is on those boards, and probably more importantly what type of interface is used.

If they are connected via USB, then nearly anything is possible. One could potentially modify the device to act like storage, or like a keyboard, or both (this depends on the capabilities of the device). When you plug it into your server, the device would then mount a drive (as its acting like storage) and start executing things on that drive (by simulating keyboard input).

There are even hacked USB cables out there which will do this...

If you are using Ethernet then the usual network security issues apply.

If you are using "simpler" interfaces like a serial port (UART), SPI, I2C or similar stuff, then the risk is much lower, but really depends on what on the host PC is talking to that interface, possibly who is the master, and the handling of the usual issues like buffer overflows, out of bounds values, etc.

You are much less likely to have issues with, say, a temperature sensor reporting via SPI or I2C, than with an SBC containing a full SoC and interfaced via USB for instance.

To understand the risks, you need to know a lot more about what those boards do and how they are interfaced.

Note that you state the boards don't have any storage, but that's highly unlikely. If people connect to those boards to update or configure them, then there is necessarily some storage. It may be flash on the board, or even flash inside a chip (SoC).

There are chips smaller than a fingernail which include multiple CPU cores, RAM, megabytes of flash memory, and USB interfaces...


No technology is free of an attack vector. However, I do not consider the exploitability of effects occurring on printed circuit boards to be obviously exploitable without further ado, unless you dimension the corresponding electronics accordingly.

On the level of a pure printed circuit board, there are tracks on it and a carrier material.

By their very nature, conductive tracks always have an inductance. There is also always a capacitance between the conductors. Both are not exactly large, but they are present.

Due to the said inductivity as well as capacitance which is inherent to a printed circuit board, mechanical (e.g. acoustic) as well as electromagnetic oscillations could be sent as well as received.

But as I said, without corresponding specially dimensioned electronics on the printed circuit board or in connection with it, this seems to me to be impossible.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .