What happens to your passwords when an employee leaves

Someone gives notice on a Tuesday. HR runs the checklist, IT disables the Microsoft 365 account on their last day, the laptop comes back, and the offboarding is marked complete. It looks clean.

It usually is not. Disabling an account closes one door. It does not touch the dozens of credentials that person accumulated over three years: the passwords saved in a browser profile synced to their personal Google account, the vendor portal they signed up for with a company card, the API key they generated for an integration nobody else understands, the MFA recovery number that is still their cell phone, and the shared logins they have known since their first week. None of that disappears when the account is disabled. Most of it keeps working.

This article covers the credential surface a departing employee actually leaves behind, what happens to each part of it by default, the order to work through it in the first 72 hours, and what to do right now if someone just left and you do not have a password manager. If you are looking for the broader process, the Microsoft 365 offboarding checklist and the remote employee IT offboarding checklist cover the account and device side. This one is about the passwords.

Short answer: disabling someone’s primary account only revokes the credentials that account controls. Everything they authenticated to outside of it keeps working: browser-saved and personally vaulted passwords, accounts they created themselves, shared logins, service accounts, API keys, and any account whose password reset flow points back at their phone or personal email. A business password manager with an admin console collapses most of this into a single revoke-and-report action. Without one, you are running an inventory and a rotation by hand, and the accounts you forget are the ones you find out about later.

Where credentials live	What happens when you disable their account	What you actually have to do
Apps behind SSO or your identity provider	Access stops immediately	Nothing further, this is the part that works
Passwords saved in their browser profile	Nothing, the profile syncs to their personal account	Rotate anything that was in it, and disable browser saving going forward
Their personal password manager vault	Nothing, you have no visibility and no reach	Rotate every business credential you believe was in it
Accounts they created themselves	Nothing, you may not know the accounts exist	Find them through card statements, email, and DNS records, then take ownership
Shared logins	Nothing, the password still works for everyone who knows it	Rotate on a priority order, and move to a shared vault
Service accounts, API keys, integrations	Nothing, and rotating carelessly breaks production	Inventory first, then rotate on a planned schedule
Recovery email, phone, and MFA devices	Nothing, they can still reset passwords back to themselves	Change the recovery path before you change the password
Company password manager vault	Access is revoked centrally, credentials stay intact	One action, plus rotate anything they could read in plain text

The account you disabled is not the credential surface

The mental model most small businesses run on is that the Microsoft 365 or Google Workspace account is the master key, so revoking it revokes everything. That is true only for the applications actually federated to it, and in a typical 20 to 50 person business, that is a minority of the tools in use.

Everything else was set up the way things get set up in a growing business. Someone needed a tool, they signed up with their work email, they chose a password, and they saved it in whatever was convenient. That credential has no relationship to your identity provider. It is an independent username and password pair sitting on a vendor’s server, and its only tie to your business is an email address that you have now disabled, which means you cannot even use the password reset flow to take it back. Disabling the mailbox can make an orphaned account harder to recover, not easier.

This is why single sign-on matters more than it looks like it should and why credential offboarding is a separate stage of the process rather than a line item inside the account stage. The question is not “did we disable their account.” It is “which credentials did this person hold, and where are they now.”

Where their credentials actually are

Their browser. This is the biggest one and the least examined. If they were signed into Chrome or Edge with a personal profile, every password they saved for work went into that personal account, and it followed them out the door onto their home computer and their phone. Nothing about returning the laptop reverses that. You do not need to imagine malice here. The passwords are simply there, on a personal device, and they will autofill for years until something changes. This is why browser-saved passwords are a business risk rather than a convenience, and why the disable-saving policy belongs in your rollout, not on a wish list.

Their personal password manager. Plenty of employees do the responsible-looking thing and use a personal password manager for work credentials. It is better than a notebook and it is still a problem, because a personal vault is invisible to you, unreachable by you, and portable. You cannot revoke it, audit it, or ask it what was inside. When the person leaves, you are left guessing at the contents.

Accounts they created that nobody else knows about. The SaaS trial that became a production dependency. The vendor portal opened under their name. The domain registered for a campaign microsite. The analytics or advertising account with the billing attached to a company card. In most businesses this category is larger than anyone expects, and it is the one that surfaces months later, when a renewal fails or a certificate expires and the only administrator is a person who no longer works there. Shadow IT is not a hypothetical governance concern here, it is the reason a real system stops working on a Thursday.

Shared credentials. The social accounts, the info@ mailbox, the ordering portal, the credentials several people use. These are their own problem with their own fix, covered in depth in the problem with shared passwords. For offboarding, the important property is simple. A password that several people know cannot be revoked, only changed, and changing it is work that people avoid, which is why so many departing employees still hold a working password to something.

Service accounts, API keys, and integrations. The credential the backup job runs under. The API key for the payment integration. The token the reporting script uses. The account that lets the copier email scans. These are frequently created by one technical person and documented nowhere, and they are the credentials most likely to still be valid years later, because rotating them without understanding them breaks something in production. They deserve a plan rather than a panic, and they are worth handling as a standing practice rather than a departure scramble.

Recovery paths pointing at a person, not the business. This is the quiet one. An account’s recovery email is their personal Gmail. The MFA code goes to their cell phone. The authenticator app lives on a device you never had. Change the password all you like. If the reset flow leads back to them, they can take the account back at any time, and you will not learn about it until they do. Recovery paths are the step that most offboarding checklists skip, and they are the step that actually decides who controls the account.

Live sessions and OAuth grants. Passwords are not the only way back in. An authenticated session on a personal phone can survive a password change, and a third-party app they authorized still holds a token that keeps working on its own terms. This is why the M365 offboarding checklist revokes sessions and app permissions as distinct steps rather than assuming a password reset covers it.

The first 72 hours, in order

You will not do everything at once, and trying to will mean the important items wait behind the unimportant ones. Work in this order. The sequencing is more valuable than the speed.

When	What you do	Why it belongs here
Before the conversation	Revoke password manager vault access, pull the vault access report	One action covers every managed credential, and the report is your work list
Hour 0 to 4	Disable the primary account, revoke active sessions, remove their MFA methods, revoke OAuth app grants	Closes the federated door and the session side door together
Hour 4 to 24	Change recovery emails, phone numbers, and MFA devices on every high-value account that points at them	Until this is done, rotating passwords accomplishes nothing
Day 1	Rotate banking, payroll, payment processing, the domain registrar, and email admin	Direct financial loss and account-takeover potential, in that order
Day 2 to 3	Rotate remote access, VPN, systems they used daily, and the admin accounts on your own infrastructure	Highest familiarity means highest chance of casual re-entry
Week 1	Rotate social media, vendor portals, marketing tools, the CMS	Reputational and operational damage, lower financial exposure
Week 2 to 4	Inventory and rotate service accounts, API keys, and licenses on a planned schedule	Rotating these without understanding them breaks production, so plan rather than rush
Month 1	Find and take ownership of accounts they created, then close the ones you do not need	Slower work, but this is the category that bites you in six months

Two notes on this table. The recovery-path row comes before the rotation rows on purpose. If you rotate a password on Monday and the recovery email is still their personal address, you have not secured the account, you have just annoyed them. And the vault revocation row sits before the exit conversation, not after it, which is the single largest practical benefit of running a password manager at all.

What a business password manager actually removes from this list

Most of the work above exists because the credentials are scattered. A business password manager does not make offboarding unnecessary. It makes most of it a report rather than an investigation.

Revocation becomes one action. Suspend the user in the admin console and every credential in every vault they had access to is out of reach immediately. No hunting, no per-app cleanup, no negotiation about what they might still have.

You get an actual list. The admin console tells you which vaults and which items the person could reach and when they last accessed them. That list is the rotation work order. Without it, the same list is an interview, a guess, and whatever you find in their sent mail.

Most credentials were never theirs to keep. When a shared credential is used through the vault with autofill and view permission withheld, the person genuinely never learned the password. There is nothing in their head, their browser, or their notes to worry about, so most of your rotation list collapses to the small set of credentials they could actually read.

Ownership transfers instead of evaporating. Items in a company vault belong to the business. When someone leaves, their vault contents can be reassigned to a manager or a successor rather than disappearing with the account. This is the difference between a departure and an outage.

The credentials they created land in the vault by default. The reason nobody knew about that SaaS account is that there was nowhere obvious to put it. Once there is, the shadow-IT category shrinks by itself, because saving it in the vault is now the path of least resistance rather than an extra step.

Recovery does not depend on one person. Business plans have break-glass and account recovery paths held by the organization, so a departing administrator does not take your access with them.

What it does not fix

Two limits worth being honest about, because assuming otherwise is how businesses get surprised.

A password manager does nothing about credentials that were never in it. Anything the person saved in their browser or their personal vault before your rollout is still out there, and this is exactly why migration is only real if you rotate credentials as you move them in. A vault full of passwords that are also sitting in someone’s Chrome profile is a filing improvement, not a security control.

And it does not revoke sessions or tokens on the vendor’s side. Rotating a password in the vault does not necessarily sign out a device that is already authenticated, and it does not touch an OAuth grant. For the accounts that matter, sign out all sessions in the application itself, and review connected apps. The vault manages the credential, not the vendor’s session state.

If someone just left and you do not have a password manager

Do not wait for a rollout. Do this now, in this order, and start the rollout afterwards so that the next departure is a five-minute task.

1. Write down every system the person touched. Ask them, if the departure is amicable and they are still reachable. Ask their manager and their closest colleagues, because everyone remembers a different set. Then check three sources people forget: the company card statement for subscriptions, their mailbox for signup and receipt emails, and your DNS records for services pointed at domains you own.

2. Fix the recovery paths first. For every high-value account, change the recovery email and phone number to a business-controlled address before you change any password. This is the step that decides whether your rotation actually holds.

3. Rotate on the priority order in the table above. Money first, access second, reputation third, housekeeping last. Do not rotate alphabetically and do not rotate everything at once.

4. Turn on MFA wherever it is not on, using a business-controlled factor. A departure is the moment when the gap between “we should” and “we have” becomes expensive. MFA is not a complete answer, but on an account whose password may be in a former employee’s browser, it is the control that holds the line while you work through the list.

5. Check for signs the credentials were already used. Look at sign-in logs, mail forwarding rules, and inbox rules on the accounts that matter. A forwarding rule quietly copying mail to a personal address is one of the most common signs of a compromise, and it survives a password change if you do not remove it.

6. Write down what you rotated and when. In six months, when an insurer, an auditor, or your own incident review asks what you did, this record is the difference between an answer and a shrug.

7. Then start the rollout. The reason this week is painful is structural, and it will be exactly this painful next time unless the structure changes. Deploying a password manager is the fix, and a fresh departure is the easiest business case you will ever have to make.

The departure that is worse than a resignation

Two situations deserve their own handling.

The involuntary exit. When someone is being let go, the sequence changes: revocation happens during or immediately before the conversation, not on their last day. The vault access, the account, the sessions, and the remote access all close first, because the window between “they know” and “you have revoked” is the only window that has ever mattered. If they work remotely and the device is theirs to return, the same logic applies as with a lost or stolen laptop, and device management is what makes it enforceable rather than a request.

The person who held everything. The office manager who set up every account. The technical founder who built the integrations. When they leave, the credential surface is not a list, it is the business. This is the scenario that makes the case for two administrators on every critical account, break-glass credentials held by the business, and a documented recovery path, all of which are cheap to set up in advance and nearly impossible to arrange retroactively. If this describes someone currently on your payroll, that is the risk to fix this quarter, regardless of whether they have any plans to leave.

Common mistakes

Disabling the account and calling the credentials handled. The account and the credential surface are different things, and the second one is bigger.

Rotating the password but not the recovery email, phone, or MFA device. A former employee who controls the reset path controls the account, whatever the password says.

Skipping it because the person left on good terms. Nearly all post-departure credential incidents are accidental. A saved login on a personal laptop that gets sold, a phone that is not wiped, a synced browser profile on a home computer. There is no malice required, and rotating anyway costs an afternoon.

Deleting the mailbox too early. The mailbox is your best inventory of the accounts they created, and it is often the only way to recover one through a password reset. Convert it or keep it long enough to work through the list, as the license and mailbox handling guidance covers.

Forgetting personal devices entirely. A BYOD policy that never contemplated departure means a phone with a live mailbox and a synced browser walks out with them, and the laptop return ceremony makes everyone feel like the job is done.

Rotating service accounts in a hurry and breaking production. The temptation, after finding out a departed engineer’s key still works, is to rotate it immediately. Inventory it, find the dependency, then rotate it in a maintenance window.

Assuming SSO covers apps that were never behind SSO. The list of apps in your identity provider and the list of apps your business uses are not the same list, and the gap between them is where this whole problem lives.

Leaving the credential step to HR. The HR checklist ends at the badge and the laptop. Credential offboarding is IT work with a defined owner, or it is nobody’s work.

Waiting for the last day. Notice period is when the risk is highest and attention is lowest. Vault access can be reduced immediately, well before the final Friday, without anyone being treated badly.

Never inventorying until someone leaves. The reason a departure turns into a two-week scramble is that the inventory does not exist. A quarterly credential review makes the next exit a report instead of an investigation.

What is next in this series

Departures are one of the two moments a credential problem becomes visible. The other is a breach, and a later article in this series covers what to do when business passwords are compromised. If you have not yet chosen a tool, start with why your business needs a password manager and how to choose one. If you have, deploying it is the work that makes everything above cheap. And the rule that keeps it from regrowing belongs in writing, in your cybersecurity policy, where offboarding gets a credential stage of its own.

How Sequentur can help

If someone just left and you are not sure what they still have access to, schedule a call and we will work through the list with you.