The FDA does not forbid the use of general purpose OS. However, they are strictly regulated. For every SOUP, software of unknown provenance/pedigree, that is every piece of software that was not developed specifically for a medical device, this is the responsibility of the manufacturer to provide performance requirements, test, risk analysis...

Moreover, the manufacturer have the obligation to assess every known bug of every SOUP and provide fixes if this can endanger the patient.

The issue is that to prove that a device is safe you have to execute costly tests. For a device I have been working on, we do endurance tests on multiple systems to simulate 10 years of use. Even with intensive scenario, on multiple systems it can take a few months. And if we encounter a single crash we reset the counter and start again. So in the end the product is safe but it is costly. This is why most of the time it is actually better to have the most simple stack possible on bare metal. But sometimes mistakes have been made, and you inherit a system full of SOUP and this is a nightmare to maintain.

I actually except some shitstorm on Monday morning, luckily I am working more on the embedded side so no Windows for me but some other divisions will be affected.

> In offense of these medical devices, they should never have been running Windows or any general purpose OS in the first place!

Except that people don't want to learn a new GUI for every machine...

Except that people want to be able to use a tablet for the interface...

Except that people want to control things from their phone...

Here's the reality: The end user doesn't give one iota of DAMN about security. People want to control their pacemaker or insulin pump from their PHONE. Ay yai yai.

Even worse: can your security get in the way when someone is trying to save a life? That's going to send you to court.

Most of these don't apply in context of medical devices. Sure, you can find some which will give you access to the usual OS desktop. But largely they're integrated and have a full-screen, completely customised interface

The devices itself should not run Windows. You should separate the two: one for the device, one for the user. The user machine (a full-blown windows if that's what you want), you can security-update all you want.

Of course, such devices can put their code in ROM, and so any malware would not survive a reboot.

Sure, but then, you also need strict W^X memory protections, without exceptions (kernel included), since malware in memory of a device that doesn't often reboot is dangerous enough. For example, the very best malware for network devices never writes itself to disk even if possible, in order to avoid showing up in forensics. This already precludes most general purpose OSes and is still technically vulnerable to some convoluted return-to-X attacks that just swap data structure pointers around and use existing code to construct the malicious behavior, so I'd still feel better with a minimal trusted base even then.