You are indeed vulnerable to that kind of accusation. However, this is partly a mess of your own making, because you have not used good security practices so far. You know that, and I won't belabor it.
Generally there are three types of security model for a service-oriented web site.
- One login (account/password) for the corporate account. All the users at the company are expected to share the password, and any one of them can cause mayhem. MailChimp is like this, for instance.
- A master account/password for the corporate account. It's possible to just share that password, but they also provide the ability to create individual sub-accounts - a login/password for each employee. Every activity is journaled to its sub-account PayPal works like this: my logins for ABC Company are ABCCo-Harper and ABCCo-HarperAdmin. (The first is only priv'd for point-of-sale).
- The site allows real-human accounts only, then associates companies with the humans. Examples are a Facebook business "Page", where any number of humans are admins, contributors or advertisers.
Servers on your own premises surely accept the "sub-account" model; stop sharing root and set up admin accounts with sudo.
Untangling this twisted web
It's too late to do the most important thing: swerve way out of your way to select providers with robust password architectures. When setting up our business systems, I was very selective about this; however still, half our accounts are the shared-password kind because so few vendors support sub/real accounts.
On "real-human accounts only" sites, the site has already forced you into a competent security model. Right now: make sure the correct humans at your company have an account, and promote them appropriately; at least one must be the highest rank. On your last day: tell the system to dissociate your account with the company's asset. Easy peasy.
On sites capable of individual sub-accounts, right now: set up sub-accounts for the correct humans at your company including yourself, issue them passwords, and forget the passwords you issued them. Make sure appropriate staff have the master password, and ask them to change it immediately. On your last day: Walk away and don't log back into your sub-account. They should delete it, but if they don't, who cares? The system's journaling will prove you did nothing.
On all other sites, first: make sure the relevant people have the correct passwords.
You have a variety of passwords which have not changed for far too long. Change them. That also applies to any password that you have stored in a way you know is stupid. Presume it to be compromised and change it NOW and give them the new password. You need to do this now, while there is still a month of recovery time. Doing this in your last week is much too late.
And clean up behind yourself; once you have reset them, delete all the passwords from places they should not be, like emails (!), Google docs, and the like. Not sure how I feel about password managers; they're far from the worst and not far from the least bad way to deal with it.
And don't make any new messes; if someone asks for a password, don't email/tweet/Facebook messenger it. Stop doing that. Write it down on paper, seal it in an envelope and hand it to them. Physical security is their problem. Or call them on the phone and read it to them.
Distributing new passwords
I am dealing with technophobe pointy-hairs, so I do passwords on paper. I make an MS-Word document listing every account, and A B C D E F G where the passwords would go. That can be distributed electronically. Then I have another sheet which says simply A B C D E F G with a space for a password for each one, and that I hand deliver. For pointy-haired managers who are unlikely to use them, I put the master passwords in an envelope saying "Master Passwords! Do not open except in emergency".
As far as generating passwords, I finally ran out of AOL disks :) So I use a scrap of perl and /usr/lib/dict/words to generate a CorrectHorseBatteryStaple-type password tuned to work on most sites and be mobile-friendly (i.e you're not typing shifts more than characters).
Getting them to reset behind you
When distributing new passwords to them, send a separate email professionally advising them that you have changed passwords, the list of accounts you have changed passwords for, and state that you provided the password list on paper (or however). CC this to your personal, offsite email address, and BCC it to your lawyer. It goes without saying this email should NOT contain any passwords.
Then, on quit, send them another email the same way reminding them that you are leaving the compay as of date/time and please change the shared passwords behind you. Again, CC to your personal and BCC to your lawyer.
Really, at this point, you've done all you can do. If they have problems, you and your lawyer wave those documents around in court, showing it was their responsbility to change the passwords behind you, and you told them that. (Of course you also deny doing anything; but by showing their negligence, you undercut any claim of damages.)
Hopefully, if you do as I say, you have "warmed them up" to the idea of changing their passwords from time to time. They, too, know they need to do it; you just did the heavy lifting for them.
Now, enroll an ally at the company at resetting the passwords behind you.
DO NOT under any circumstance log into an account "to see if they changed the password". No matter how curious you are! You shouldn't even possess any more passwords; you should have deleted them from wherever you keep passwords. Be thorough. Certainly if there is litigation, they will subpoena your laptop, and a list of accounts from 1password, etc.. If they show you kept passwords, that will undercut your defense that it wasn't you.