Correct, number 2 in your example is not a problem at all, and we have those as well. But not all services actually support this properly IME. Our policy is t

Correct, number 2 in your example is not a problem at all, and we have those as well. But not all services actually support this properly IME. Our policy is to create accounts that are generic with strict permissions around a specific automation or service of our own. This happens more in devops than in everyday usage of say a report tool where shutting off a user doesn't matter. Essentially my example is the same you pointed out though, for the generic admin account you created you will need to use it to administrate the other users etc. What we do is store that admin account in 1Password with 2fa turned on for it and that way it is never locked to a user with 2fa on their personal device. For a little more detail too, we will setup sub account for automated systems which have restricted permission (and likely use ssh/key pairs to login for automation). However, when you need to update something about these accounts many times you have to login as them and make a change, so in that case again we store the password and 2fa in 1Password so the team can handle that quickly and isn't stuck because one person left. I am always open to other ideas though if you think I am missing other options.