The problem with shared passwords in small business and how to fix it

Every small business has them. The Instagram login that three people in marketing use. The vendor portal where the account was set up under the office manager’s email and the password lives in a group chat. The shared info@ mailbox that everyone signs into with the same credentials. The QuickBooks login that the bookkeeper and the owner both use because buying a second seat felt unnecessary.

Nobody planned this. It accumulated. Someone needed access on a Friday afternoon, the fastest way to grant it was to send the password, and that became the permanent arrangement. Five years later the business has a couple of dozen credentials that several people know, no record of who knows which, and no way to change any of them without breaking something.

Shared passwords are one of the most common security problems in small business, and one of the least discussed, because they do not feel like a security problem. They feel like a workflow. This article covers why sharing credentials is both a security and an operational failure, where it usually happens, how a business password manager handles shared access properly, and what to do when someone leaves and the shared credentials are still out there.

Short answer: shared passwords remove accountability, make rotation practically impossible, and turn one compromised account into a compromise of everything that credential touches. The fix has two parts. Where the platform supports individual accounts, stop sharing and give people their own logins with role-based permissions. Where it genuinely does not, move the credential into a shared vault in a business password manager, where access is granted per person, revoked centrally, logged, and autofilled without anyone ever seeing the password.

The problem	What it costs you	The fix
No accountability	You cannot tell who did what in an audit log, because everything is “the shared account”	Individual accounts, or vault-level access records
Rotation is impossible in practice	Changing the password breaks it for six people, so nobody changes it	Vault-managed credentials that update once for everyone
One breach exposes everything	A phished password gives an attacker whatever that account can reach	Per-person access, MFA, and a smaller blast radius
Offboarding never fully completes	The person who left still knows a password that still works	Central revocation, plus a defined rotation list
The password is in chat, email, and a spreadsheet	It leaks quietly, forever, to places you do not control	Sharing through the vault, not through messages

Why shared passwords are a security problem

You lose accountability completely. The moment more than one person uses a credential, the audit log stops being evidence. A login from the shared account tells you the account was used, not who used it. If money moves, a post gets published, a customer record gets deleted, or a setting gets changed, the honest answer to “who did that” is “one of five people, we cannot tell.” That is a problem long before you have a breach, and it is a serious problem during one. Incident response depends on being able to distinguish normal activity from an intruder’s, and a shared account makes every action look equally plausible.

Rotation becomes something you never do. Good credential hygiene says you rotate a password when there is any reason to suspect exposure. In practice, a shared password is a load-bearing wall. Changing it means notifying everyone who uses it, sending the new one around, watching a few of them get locked out anyway, and fielding calls for a week. So nobody changes it. The password set in 2019 when the account was created is still the password. It has survived three departures, two agency relationships, and a laptop that was never returned.

One compromise becomes total. The whole reason reused passwords are dangerous is blast radius, and a shared password is the same failure with a different shape. Whoever holds it has everything that account can do, and one phishing email against any single person holding it hands over the entire account. Worse, shared passwords are almost never protected by multi-factor authentication, because MFA on a shared login is genuinely awkward. Whose phone gets the code? So the shared account, which is the highest-value account by definition, ends up as the least protected one.

It leaks through the channels you used to share it. Think about where the password actually is right now. A Slack or Teams message from two years ago. An email thread. A text. A shared spreadsheet in Google Drive. A note on someone’s phone. A sticky note in a drawer. Every one of those is a copy you do not control and cannot recall, and each one is searchable by anyone who later gets access to that mailbox or that chat history. Credential exposure like this is often the quiet first stage of an incident, which is why it shows up on the list of signs your network has already been compromised.

Cyber insurance and compliance are catching up. Insurers now ask directly about shared credentials, MFA coverage, and access control on renewal questionnaires. Answering those questions honestly gets harder every year, and answering them inaccurately can affect a claim. If you are already navigating what cyber insurance actually covers, credential sharing is one of the items most likely to sit between you and a clean renewal.

Why it is also an operational problem

The security case is the easy one to make. The operational case is often what actually gets a business to fix it.

Shared credentials create lockouts. When one person changes the password because they got a breach alert, everyone else is locked out and nobody knows why. They create dependency on a single human being, usually the office manager, who becomes the credential help desk and cannot take a vacation without someone needing a login. They make it impossible to grant someone temporary access without giving them permanent access, because there is no way to un-tell a password. And they make routine tasks fragile: the MFA code for the shared account goes to a phone number belonging to an employee who left, so now nobody can log in at all, and account recovery means proving ownership to a vendor with a support ticket that takes two weeks.

Every one of those is time and money, and none of them requires an attacker to be involved.

Where small businesses actually share credentials

It is rarely one bad habit. It is a handful of recurring patterns, and each has a different correct fix.

Social media accounts. Instagram, Facebook, LinkedIn company pages, X. Marketing has the login, so does the owner, so does whatever agency you used two years ago. This is the single most commonly shared category in small business, and it is one of the few where the platforms have a real answer that most businesses never turn on.

Vendor and supplier portals. The distributor site, the parts ordering system, the wholesale account, the insurance broker portal. These were created with one account because that was the default, and now anyone who needs to place an order needs the password.

Shared email accounts. info@, sales@, support@, billing@. A real mailbox with a real password that several people sign into. This is the pattern with the clearest technical fix, because shared mailboxes in Microsoft 365 exist precisely so that nobody needs to share a password, and yet the password-sharing version is still everywhere.

Financial and payroll systems. Banking portals, payment processors, the accounting package. Shared here for cost reasons, because a second seat costs money, which means the highest-consequence credential in the business is shared to save a small monthly fee.

Admin accounts on your own systems. The router login, the Wi-Fi admin, the point-of-sale back office, the domain registrar, the website CMS. Often shared with an outside IT person or web developer at some point, and never rotated afterwards.

Service accounts and licenses. Software licenses, API keys, the account that runs a scheduled export, the credential a scanner uses to email PDFs. Nobody thinks of these as passwords, so they never get inventoried, and they are the ones that quietly still work years later.

The fix, part one: stop sharing what does not need to be shared

Before you move credentials into a vault, cut the list down. A surprising proportion of shared passwords exist only because nobody looked for the built-in alternative.

Use individual accounts wherever the platform offers them. Most business platforms support multiple users with role-based permissions, and many small businesses simply never set it up. Your accounting package, your CRM, your e-commerce platform, and your payment processor almost certainly allow separate users with different permission levels. Individual accounts give you per-person audit trails, per-person MFA, and instant revocation when someone leaves. The seat cost is real, but it is small next to a payroll fraud incident that you cannot even attribute to a person.

Use platform-native delegation for social media. This is the one most businesses miss. Facebook, Instagram, and LinkedIn all support granting people access through their own personal accounts, with roles, without anyone learning the page password. Meta Business Suite and LinkedIn page admin roles exist for exactly this. Set it up once and the agency you fire next year loses access with two clicks instead of a password change and a hopeful assumption.

Use shared mailboxes instead of shared logins. In Microsoft 365, a shared mailbox has no password at all. Users access it through their own account, their actions are attributable, and their access disappears when their account is disabled. If your info@ address is a licensed user with a password that four people know, converting it is one of the highest-value hours of work available to you. If you are not sure which construct you should be using, groups versus distribution lists versus shared mailboxes sorts out the differences.

Use vendor sub-accounts and guest access. Many vendor portals support additional users under one company account, often for free, and it is simply never requested. For outside collaborators, Microsoft 365 guest access lets you work with people outside your business without issuing them a credential of yours.

After this pass, the shared credential list usually shrinks by half or more. What is left is the genuinely unavoidable set: platforms with a single-login design, legacy systems, and a few accounts where a second seat truly is not justified. That remainder is what the password manager is for.

The fix, part two: share properly through a business password manager

A business password manager does not just store the shared password more neatly. It changes what sharing means.

Shared vaults, not shared passwords. Credentials go into a vault, and people are granted access to the vault. The unit of sharing becomes a permission you control, not a string of text you released into the world. Vaults are organized by function, so Finance, Marketing, IT administration, and Client accounts each hold what they should, and nothing more.

Granular permissions. Access is not binary. A user can be allowed to use a credential without being allowed to see it, edit it, export it, or reshare it. Someone in marketing can log into the scheduling tool without ever being able to read the password out of the vault, screenshot it, or paste it into a chat message.

Nobody has to see the actual password. This is the part that surprises people. The password manager autofills the credential into the login page, so the person using the account never learns the password. That means it cannot be written down, cannot be leaked accidentally, and cannot go with them when they leave, because they never had it in the first place.

Rotation stops being a project. Change the password once, in the vault, and everyone with access has the new one immediately. No announcement, no lockouts, no support calls. Rotation becoming cheap is what makes rotation actually happen, and rotation actually happening is what makes offboarding real.

Every access is logged. The vault records who accessed which credential and when. You do not get per-person accountability inside the vendor’s application, because the vendor still sees one login, but you do get a record on your side of exactly who could have been using it and when they retrieved it. In a small business investigation, that is usually enough to answer the question.

MFA becomes possible again. Business password managers can store the MFA seed for a shared account and generate the code for anyone with vault access, which resolves the “whose phone gets the code” problem that keeps shared accounts unprotected. The highest-value shared account in your business can finally have a second factor.

What this does not fix

Two honest limits, because pretending otherwise sets you up for a bad surprise.

The vendor’s audit log still shows one user. A shared vault gives you accountability at your end, not inside their application. If a platform’s own logs need to distinguish between your employees, and that matters for compliance or for a dispute, a shared credential in a vault is not sufficient. You need individual accounts on that platform, and no password manager substitutes for that.

The vault does not clean up the copies already in circulation. Moving a credential into a shared vault does nothing about the version sitting in a two-year-old Slack thread. Migration only counts if you rotate the password as you move it, which is why the rotation step below is not optional.

What to do during offboarding when shared credentials exist

Someone gives notice, and now you have to figure out what they know. This is the moment shared credentials turn from a background risk into an urgent task, and it is why every offboarding process needs a credential stage, not just an account-disable step. Both the Microsoft 365 offboarding checklist and the remote employee IT offboarding checklist cover the wider process. Here is the shared-credential part of it specifically.

1. Revoke their vault access first. If you have a password manager, this is one action and it covers every credential they could reach. It takes a minute and it should happen before the exit conversation, not after.

2. List every shared credential they had access to. Vault access records make this a report. Without a vault, it is an interview and a memory exercise, which is exactly why the vault matters. Include the accounts they created themselves, which are the ones most likely to be missing from any list.

3. Rotate by priority, not alphabetically. You will not rotate everything in one afternoon, so sequence it.

Priority	What to rotate	Why first
Same day	Banking, payroll, payment processing, domain registrar, email admin	Direct financial loss and account-takeover potential
Within 48 hours	Systems the person used routinely, remote access, VPN, POS back office	Highest familiarity, highest likelihood of casual re-entry
Within a week	Social media, vendor portals, marketing tools, CMS	Reputational and operational damage, lower financial exposure
Within a month	Everything remaining, including service accounts and licenses	Housekeeping, but do not let it slip past a month

4. Change the recovery paths, not just the password. If the account’s recovery email, phone number, or MFA device belongs to the person leaving, rotating the password accomplishes nothing. They can reset it back. Recovery details are the step people skip, and it is the step that actually loses you the account.

5. Check for credentials they created that nobody else knows about. The SaaS trial that became a production dependency, the API key for the integration they built, the scheduled export running under their personal login. These surface later, usually at the worst time, when something stops working and nobody knows why.

6. Write down what you rotated. A short record of what was changed and when. If a security question comes up in six months, this is the difference between an answer and a guess.

If you do not have a password manager and someone just left, do not wait for a rollout to begin. Work the priority table above by hand today, then start the deployment so that the next departure is a five-minute task instead of a two-week scramble.

How to fix this in a 30-day pass

You do not need a project plan. You need four evenings.

Week one: inventory. List every credential more than one person knows. Ask each person directly, because everyone knows about different ones. Do not skip the boring ones. The router, the registrar, the alarm system, the scanner’s email login.

Week two: eliminate. For each item, ask whether the platform supports individual accounts, delegation, or a shared mailbox. Every credential you can eliminate is one you never have to manage again. Fix the social accounts and the shared email addresses in this pass, because those two categories usually account for the largest share of the risk.

Week three: consolidate and rotate. Move whatever is left into shared vaults in your business password manager, organized by function. Rotate every credential as you move it, because until you do, the old value is still in a chat history somewhere. Turn on MFA for the shared accounts that support it now that the vault can hold the seed.

Week four: write the rule down. One paragraph in your cybersecurity policy: credentials are never shared over chat, email, or text, sharing happens through the vault, and offboarding includes a credential rotation step. Then make it real by adding the vault steps to onboarding and offboarding, so the next new hire never learns the old habit in the first place.

Common mistakes

Moving the password into the vault without rotating it. The credential is now managed and still leaked. The old value is in a chat thread you forgot about. Rotate on migration, every time, no exceptions.

Treating the vault as a place to store the spreadsheet. Pasting the shared password into a secure note, then copying it out and sending it to people, is the old process wearing a costume. Share by granting vault access, not by retrieving and forwarding.

Sharing everything with everyone. A single vault that all staff can reach reproduces the original problem with better encryption. Structure vaults by function and grant only what each role needs.

Leaving MFA off the shared accounts. These are the accounts most worth protecting and the ones most often left bare. Once the vault can hold the MFA seed, the reason for skipping it is gone.

Forgetting the accounts nobody thinks of as accounts. Service accounts, API keys, scanner and copier credentials, the license portal. They never get rotated because they never get inventoried.

Rotating the password but not the recovery email or phone. A former employee who controls the recovery path controls the account, whatever the password is.

Letting one person hold the keys. Replacing a shared spreadsheet with a single office manager who holds everything is a different single point of failure. Two administrators, and a tested recovery process.

Assuming the agency gave the access back. Outside marketing agencies, web developers, and former IT providers are one of the most common holders of live credentials. If access was granted by handing over a password, assume they still have it until you have rotated it.

Skipping the credential step at offboarding because the person left on good terms. Most credential incidents after a departure are not malicious. They are an old saved login on a personal laptop that gets sold, or a phone that is not wiped. Rotate anyway.

Doing the inventory once and never again. Sharing regrows. Six months after a clean-up, a new vendor portal and two new tools have appeared. A short quarterly review keeps the list from rebuilding itself.

What is next in this series

Shared credentials and departing employees are the same problem seen from two angles, and the next article in this series covers the second one: what happens to your passwords when an employee leaves, including the credentials they created that nobody else knew about. If you have not picked a tool yet, start with why your business needs a password manager and how to choose one. If you already have, deploying it across the business covers the rollout. And if you are thinking about access more broadly, shared credentials are one of the clearest examples of why zero trust starts with knowing who is actually who.

How Sequentur can help

If your business is sitting on a pile of shared logins and you want help untangling them without breaking anything, schedule a call and we will work through the list with you.