Highly regulated industries like automotive, aerospace and medical, have a common pressure: change is expensive.
These industries need to comply with regulations before their product is allowed to be sold. On top of designing, developing, testing, marketing and selling a product, meeting regulatory requirements takes massive amounts of resources.
Every market has different regulatory requirements, so products can’t be sold in a region until that regulator is satisfied.
Regulators typically take months, occasionally years, to receive a submission, process it and respond. While the regulator is busy, the company will move its efforts to the next product. This works against security efforts; while regulators are doing their thing, engineers have forgotten about the product or left the company. By the time you come back to produce an update, nobody will remember why or how the old device worked.
Should a regulator reject your submission, it will take a long time (weeks to months) before you can resubmit and try again. This delay kills startup companies.
Most of the time, firmware is an item that regulators want to control. You’ll need to prove that the firmware is safe and has been well tested. Sometimes there are mandatory design standards that must be met. This goes beyond just the firmware that your company writes: any software that is included in your product must meet some standard. This is a huge problem for any Linux-based system as you can’t realistically prove the safety of a large body of third-party code. You can test and submit it as a black box, sometimes.
Complexity is your enemy, moreso than usual. Simpler designs mean less parts and less external software. This means simpler and faster regulatory submissions. The tradeoff? Security, of course! It’s tough to justify doing additional work for a device which will disable functionality for a possible future event. You need to get this thing shipped now!
Regulators pay attention to cryptography. Some markets restrict its use, some limit its strength, and some outlaw it entirely. Regulators pay attention. If your product uses crytography, you’ve limited the markets that you can sell to and made your interactions with regulators slower.
Regulators are paying more attention to security, though there’s nothing concrete right now. Their concerns are mostly around user safety. DDoS from virus-infected pacemakers, not so much.
There’s a massive cost to changing the design. You’re going to choose an old CPU that is boring, trusted and well documented. It needs to be available for a long time in the future.
Despite tremendous advances in mobile CPUs, you probably can’t use them because they’ll only be manufactured for a small number of years. If your CPU becomes obsolete, you have to redo the hardware design and resubmit it to the regulators; that’s expensive.
You’re going to emphasise simplicity. Less hardware components means better reliability. They mean less documentation where you have to prove that they’re safe. Smaller firmware means less testing and less documentation. Less can go wrong.
You’re going to develop more in-house rather than buy solutions in. Because you’re manufacturing and supporting for decades, your toolchains and any third-party software need to be stable for a long time. Stability is a problem for security, though – a small security fix might need you to pull in newer, untested code. What works for web development (constant updates and change) works poorly for IoT.
You’re going to make as few changes to the design and the firmware as possible because changes might need to be approved by the regulators again. Even minor changes can have unexpected implications.
For many devices, the firmware that they receive at manufacture time is the most recent firmware they’ll ever receive. It needs to be solid! You probably can’t just patch it remotely later. If your simple bugfix has a surprise bug, that bug will be out there forever.
Sort of. Not really.
In this light, it is easy to understand the decisions made by pacemaker manufacturers:
