I recently had a security assessment / internal pentest project, and one of the findings was "I found an AS/400 running telnet services" (actually unencrypted tn5250, but it comes to the same thing)
The client's response was that this host was up for history purposes only, it was not longer production system.  So it was only used occassionally when they needed transaction history from before their migration to the current system.  Which doesn't really address risk around their client's information on that host.

We've all been there.  We've found a telnet service that should be migrated to SSH, but the affected device either doesn't support SSH, or the client for one reason or another can't put resources into enabling encrypted services.  In the case of the AS400 above, they'd need to do an OS update, which would require an application update to an app they had retired, on a system that isn't production anymore.

We see this in legacy systems, but in Industrial Control Systems (ICS) that control factories, water or hydro utilities we see this all the time in production - and the answer there is "the gear doesn't support ssh, and in some cases doesn't support credentials".  In ICS systems in particular, gear like this is often on the same 5,7 or 10 year depreciation cycle as might be seen on an industrial press or other manufacturing equipment, so upgrades are really a long-term thing, there are no quick fixes.  Even finding where all the vulnerable gear is (physically, not on the network) can be a challenge

So what to do?

In some cases, I've front-ended the problem child gear with a cheap SSH gateway.  A Raspberry Pi does  a decent job here for less than $100 per node. The Pi runs "real" linux, so you can secure it.  The solution looks like this:

Physically, it looks like this - often we'll just velcro the Pi to the host it's protecting, the "Unencrypted DMZ" ends up being a 1 ft ethernet cable: