As an embedded medical devices engineer, I know you are exactly right. For safety-critical devices, control of the supply chain is beyond good practice, it's required by federal law, precisely so bad actors can't interfere with peoples' lives. The long list of requirements around approving a vendor are tiring and result in epic stories like the $500 toilet seat, etc., but they prevent stuff like this FTDI debacle from happening. You know it's going to be a toilet seat when the box arrives.

The medical device industry is a massive cultural shift from the majority of the HN crowd (e.g. startups and cloud services). In the world of PCs and servers, disruption is, literally, the name of the game. In IEC62304 land though, everything has to be on the straight, narrow and predictable path. This is why medical devices are expensive, laggy and not very startup-compatible. The FDA's system is actually more secure than Europe's. Take that, socialized medicine!

So it's not always wild and fun here in medical-land. It's like being a cop vs. a cowboy. You're not paid to sling your guns, but to de-escalate. But thank the conservative practices next time your elderly or congenitally defective family members found themselves in the hospital!

We already have fitness devices that can communicate with a PC. Is it really unthinkable that the next batch of medical devices will do something similar? For example, a wearable sensor to continuously measure your insulin levels?

Will you be using an FTDI chip in such consumer devices?

Yes, exactly.

I used to work at a sub-contractor for a large manufacturer of medical equipment, and all the systems we dealt with were like that. The device would run a very small embedded OS but would have a serial port for talking to a PC for firmware development, firmware updates, logging, diagnostics, etc. Their older stuff used real hardware serial ports, but their newer systems (~6-7 years ago now) were moving to virtual USB/FTDI serial ports, with an FTDI chip included in the embedded system.

These tricky FTDI drivers would absolutely have the potential to brick and/or alter the operation of such a device; it's not far-fetched or a flight of fancy at all.

I have a special interest in this thread/issue because I have recently been contacted by that manufacturer regarding one of these FTDI-using systems which has recently begun to exhibit new problems. I haven't started looking into that yet, and I don't know where it will lead, but I'll have to bear in mind the possibility of deliberate driver-based monkey-business now.