In most companies we walk into for the first time, there's that one mailbox. biuro@, sales@ or invoices@. Five people log in to it, the password was set in 2019, and the last time anyone actually thought about who has access was when the previous assistant left — meaning, formally, never.
This is one of those things that in a 10–50-person company almost always looks bad and almost nobody wants to touch. Because "it works". Right up to the day when someone clicks a phishing link out of that mailbox and you don't even know who was logged in at the time.
This piece is about how to end that. Without a revolution, without forcing the sales team into changes they won't understand, and without paying for new licences you don't need.
Why this is a problem
A mailbox shared by password breaks three things at once.
Audit. You don't know who sent what. An invoice went out of invoices@ to the wrong customer — who released it? The logs show one account that five people log into. The trail stops at the server-room door.
Off-boarding. A sales rep leaves. They know the password for sales@. You change it — fine, but who makes sure the change actually reaches the other five people without ending up in an Excel on Slack? In practice, nobody.
MFA. Since five people from five different phones use the account, nobody adds a second factor. The shared account stays on password only, full stop. This is one of the favourite ransomware entry points into Polish SMEs — MFA disabled on an account that also holds half the company's mailbox.
A shared mailbox is not the same as a shared password
Here's the mistake that repeats itself for years. People say "we have a shared mailbox" meaning "we have one Microsoft 365 account that several people log into with the same password". Those are two different things.
Shared password = one mail account, one licence, one password, many users. Same as a regular employee account, except a team uses it. Everything we said above is about this mode. And it has to go.
A shared mailbox in Microsoft 365 is a separate object: an address like biuro@ with no licence of its own, to which individual employees get delegated access from their normal accounts. Everyone signs in with their own mail and password, has their own MFA, but also sees the biuro@ mailbox alongside their own and can send from it with the full address. Microsoft 365 logs show exactly that Anna Nowak (a.nowak@) sent the mail "on behalf of biuro@". Google Workspace has a close equivalent via delegated access and groups that can send as a group.
The whole job we're describing is a migration from the first mode into the second. It's a cheap change — a shared mailbox in Microsoft 365 up to 50 GB doesn't need a separate licence. But nobody usually does it on their own initiative, because "for now, it works".
What it looks like in practice
At one of our clients — a 22-person accounting office near Warsaw — there were four of these accounts: biuro@, invoices@, hr@ and debt@. Each had its own password, stored in two places: a sticky note under the senior accountant's keyboard, and an Excel file in a folder called "Shared\Passwords" (we didn't make that up).
Seven people logged into invoices@. MFA — none, because "it's impractical when the girls rotate". The account also had full access to a OneDrive folder holding scans of clients' ID cards. Textbook worst case.
The migration took them three afternoons on their side and about two working days on ours. After six weeks the result was:
- The four password-accounts were gone. In their place were four shared mailboxes with delegated access for exactly the people who actually needed it (on average 3–4 per mailbox instead of 7).
- All employees had MFA on their regular accounts — because those are now the accounts they use to reach the shared mailboxes. Before, two people had it "for later".
- Microsoft 365 logs now show who sent each mail from
invoices@. First time in five years anyone could check. - An accountant leaving two months later took 30 minutes instead of a day, with a clean audit trail that access had been withdrawn.
Not counting time saved if an incident actually happened, the payoff was also immediate in a different way: the constant, vague background worry that "someone at some point" might have looked at those ID scans was gone. Because now "someone" has a first and last name.
How to do it in your company
The operation breaks into four steps. You can do it in-house if someone knows the Microsoft 365 admin panel, or outsource it — this is hours, not days.
- Pull the list of mailbox-accounts. Go into Microsoft 365 admin, filter for accounts used by more than one person. Names like
biuro@,reception@,sales@,service@,orders@,complaints@are usually suspects. Build a list: address, who actually uses it, for what, how much history it holds. - Create a shared mailbox next to it. In Microsoft 365 you create a new shared mailbox, e.g.
biuro-new@. You copy the history from the old account (New-MailboxImportRequest or via Outlook export/import — easier). You delegate access to specific people from their normal accounts. - Swap the addresses. The old account is converted to a shared mailbox (you can — just remove the licence and change type), after redirecting or renaming the addresses. Warning: this is the step where you want a snapshot and a weekend of slack, because you can break routing. Alternative: the new shared mailbox takes over the address and the old account stays offline for a while as a backup.
- Kill the old password, enforce MFA. After a week, once nobody is shouting that something doesn't work — you disable the old password. You verify in Entra ID that everyone now holding delegated access has MFA on their own account.
Two things people forget. First: the calendar. A shared calendar attached to the mail account has to be moved separately, or replaced by a Microsoft 365 group calendar. Second: mobile apps. The team needs to know that in Outlook they add their own account, and biuro@ shows up "next to it" — they don't have to sign in with a second password anywhere.
Who owns the mailbox
Last thing that decides whether the order holds for a year or three months. Every shared mailbox has to have one owner — first name, last name, email. Not "biuro" as an abstraction, but a specific person you go to with "should Marek still have access to invoices@ now that he's moved to sales?".
In practice that's the department head to whom the mailbox "belongs". Not IT — because IT doesn't know who to let in. IT's role is executional: they change the permissions when the owner asks. That single simple rule eliminates 80% of access drift on its own.
What next
This is not a quarter-long project. It's a week of work — plus one small habit (a review every six months of who has access to which shared mailbox). But it closes one of the most common, dumbest and cheapest-to-fix ransomware entry points into Polish SMEs.
If you want to see what this looks like in your company and whether it can be done without taking mail offline for the weekend — half an hour of conversation is enough to size it up.
A password half the company knows isn't a password. It's a visitor pass you handed out to everyone — including the ones who left long ago.