So the vendor who is thinking about it, would have told me about their public key system which is used in the initial transfer to protect the secrets. Then they would have described how they can upgrade and change keys over time as attackers gain the upper hand on various bit lengths, and how the elements of their system that depend on randomness, do so without being susceptible to a birthday attack or an algorithm attack on their PRNG.
When they do that, I know they've been thinking seriously about how such systems are built and deployed and there is some hope that doing the do diligence "deep dive" will show me a solid system.
Without authentication asymmetric encryption is still useless, because someone could man-in-the-middle your key exchange, swap out the public key that is sent both ways and make either side think they now have a secure channel with each other while in reality they have a secure channel with the man in the middle.
So the challenge is that they'll need some equivalent of what in the HTTPS world would be a Certificate Authority. For which you'll have the same kind of update/upgrade path questions that you very rightfully ask for the key lengths.
Of course not all situations need that, but understanding what the endpoints are trying to achieve and how that objective could be compromised by an attacker will inform on which identities must be established, and to whom, in order to achieve that objective.