No. You have to assume that the employee copied the password to a place that you have no control over - for example a browser-based password manager attached to a private sync account, possibly enrolled a second token that you have no control over. You don’t even have to assume malice for that to happen.

Using hardware based keys for accounts that require shared access is a pain, sometimes even effectively impossible (AWS allows a single U2F token on its root account, effectively making it impossible to grant 2 or more people access to it, if using a hardware token)

And then, not all services provide 2fa, less with a physical key and for some, 2fa is comparatively easy to circumvent. But all of that holds true for every password management solution that manages long-term credentials (that is: including api tokens, access keys, certificates, …)

The only thing that saves you is personalized accounts that you can deprovision - from a management perspective I love SCIM and SAML, even with all their technical flaws.

Most services don't have a good way to restrict 2fa to certain keys which would be required for that.

Also that would still mean rotating any tokens/m2m keys that have been issued.

The "proper way" would be to try to minimize how many tokens/keys are readable by employees (they should probably be only read by deployment jobs etc.) and use SSO for interactive logins. When offboarding a user it should be enough to remove the user from the SSO provider and rotate any tokens/m2m keys that the employee actually had access to (as long as the employee did not get access to issue new tokens).

Unfortunately a lot of services treat SSO as a "premium" feature and require "call us" enterprise plans for it.