Telnet will still work. So if you're developing an embedded device that will keep functioning after 20 years, it's best to not use any crypto at all. I'm half joking here.
If you have an embedded device that has to work for 20 years without update you better design it's networking part so that telnet isn't an issue in your threat model.
It would have to be on a small isolated LAN, e.g. within a machine or section of a plant.
Many buses used in industrial control equipment such as CAN bus and Modbus do not use encryption. I suppose there's more risk if you're using TCP/IP and connect laptops that have been online to the LAN, because it's such a common protocol.
But again sophisticated malware could just wait until you have your USB CAN dongle connected to the laptop, and still attack the CAN bus. Heck, CAN bus and Modbus don't even have any password protection at all.
CAN Bus is more like a layer 2 bus, so it should not really bother with encryption, just like Ethernet doesn't provide it. It all comes from the layers above it, and there has been proposal to add encryption or authentication to CAN. The big issue is that in normal CAN you only have 8 bytes to work with.
This is kind of a nitpick, but Ethernet _does_ bother with encryption, at least in recent versions of its standards. Obviously Ethernet has a long history and this is all optional, but it's pretty straightforward to set up 802.1X / MACsec (+MKA) on a LAN in such a way that all traffic is encrypted at L2.
I've never heard of this being used with really low-power embedded stuff, but if you stretch your definition of embedded to the point where you include things running stripped down Linux, this is a pretty viable setup if you have those devices distributed across a LAN with a managed switch in the middle.
