Ok we had this exact issue and I did a lot of investigation into this to allow us to disable users from the system (deleting users is another nightmare for another thread). First - Adobe recommend that users never be disabled if they have created workflows. They suggested changing the password to something large and complex and removing client access. This was too messy for me and the security audit guys just didn't buy it. Plus, if you have SSO users, you can't change their passwords as this option is disabled.
I went about it differently and hacked something together we are trialling. This might be completely bad practice but it seems to work for us. I haven't seen any better ways to do this, so happy to hear suggestions.
I found that there is a node in the workflow called [xtk:workflow]/process/@login which is the actual user login used to run the workflow. If this value is empty (ie never run) then this is set to the login value of the first operator to run it. So if you disable that user account, the workflow will no longer run. If you remove the user's rights - the workflow will no longer run.
My solution was to create a special workflow user that had enough rights to run the workflows we needed. You cant login to this user account using the client and the password is something ridiculously hard to guess.
Then you modify the process/login node to use the login for the workflow user. Once this is set, you dont need to change it again. You also have to stop the workflow, change the value then restart the workflow, otherwise the value will revert.
I am aware that this can allow users to have more workflow permissons than they might normally be allowed, but we have a dedicated team that do workflows, so its not usually an issue for us. It might be an issue if you have a more restrictive user permissioning system in place.
Happy to have a discussion on this because this is a major PITA with the user & security system in Campaign.