Key takeaways
- Microsoft says to always block sign-in for the account behind a shared mailbox and keep it blocked.
- A Microsoft 365 shared mailbox holds up to 50 GB without its own license and supports up to 25 users.
- CIS Safeguard 5.1 calls for an account inventory validated at least quarterly, and 5.3 for disabling accounts idle for 45 days.
- California's reasonable security statute covers organizations whether or not they operate at a profit.
- Placing a shared mailbox on litigation hold requires an Exchange Online Plan 2 license or Plan 1 with Exchange Online Archiving.
- After a user mailbox is converted to a shared mailbox, Microsoft says the original username and password keep working, so block sign-in on the account.
Why do shared mailboxes and generic accounts matter at a nonprofit?
Shared mailboxes and generic accounts are the logins nobody owns. A login like info@ or volunteers@ that several people know the password to cannot be traced to one person, often has no multifactor authentication, and keeps working long after the people who used it have moved on. For a nonprofit holding donor records and client case files, that is one of the easiest ways in for an attacker, and the fix uses tools you already have in Microsoft 365.
Nonprofits create these accounts for sensible reasons: a front desk inbox, a donations address, an events login for the volunteer coordinator. Staff and volunteer turnover does the rest. The CIS Critical Security Controls call for an inventory of every account with a name, username, start and stop dates and department, validated at least quarterly (Safeguard 5.1), and for disabling dormant accounts after 45 days of inactivity where the system supports it (Safeguard 5.3).
California law points the same way. Civil Code section 1798.81.5 requires a business that owns, licenses or maintains personal information about California residents to maintain reasonable security procedures and practices, and section 1798.80(a) defines business to include organizations whether or not they operate at a profit. The statute does not define reasonable security, so a documented account cleanup is part of the record a board can point to.
What is the difference between a shared mailbox and a generic account?
A shared mailbox is a Microsoft 365 mailbox that several people open with their own sign-in. A generic account is an ordinary user account, with its own password and often its own paid license, that several people sign in to as if they were one person. The first is built for team use. The second is the one to clean up.
Microsoft's guidance on shared mailboxes is direct: "A shared mailbox isn't intended for direct sign-in by using its associated user account. Always block sign-in for the shared mailbox account and keep it blocked." A shared mailbox can store up to 50 GB without a license of its own, each person who opens it needs their own licensed Exchange Online mailbox, and it supports a maximum of 25 users. Past that, Microsoft recommends a Microsoft 365 group instead.
That means a generic account converted into a shared mailbox often frees a license, and every person who uses it signs in with their own credentials and their own multifactor prompt.
How do you find every shared and generic account?
Start with three lists you already have: your mailboxes, your user accounts and your sign-in logs. Accounts that are not named for a person, or that sign in from many places, are the ones to review.
- In the Exchange admin center, list mailboxes and sort by type. For each shared mailbox, note who has access, whether direct sign-in is blocked and whether it still carries a license.
- In the Microsoft 365 admin center, export active users and flag names that are not people: info, office, admin, frontdesk, volunteer, events, donations, intern, scanner.
- In the Microsoft Entra sign-in logs, check which flagged accounts are signing in, how often and from where. Entra keeps these logs for 7 days on Entra ID Free and 30 days on P1 or P2, so export them before you start if you want a longer view.
- Repeat the search outside Microsoft 365: Google Workspace, your donor database, payment and accounting systems, and social media. Shared logins in those systems are common and easy to miss.
Put everything in one spreadsheet with columns for account, system, purpose, current users, last sign-in, owner and decision.
How do you decide what to keep, convert, replace or close?
Give every account one of four outcomes and a named owner who answers for it.
- Keep as a shared mailbox: team inboxes such as info@ or donations@. Grant access to named people only, block direct sign-in and remove any license it does not need.
- Convert: a generic user account that is really a team inbox becomes a shared mailbox, so people reach it through their own accounts and their own multifactor authentication. Microsoft notes that the original username and password keep working after a conversion, so block sign-in on the account right away and do not delete it, because it anchors the shared mailbox.
- Replace: a generic login to a donor database, payment portal or social media account becomes individual accounts, or the platform's own delegated access feature where one exists.
- Close: accounts with no owner and no sign-in in the last 45 days are disabled first, then deleted after a waiting period once you confirm nothing depends on them.
Check retention before you delete anything. Microsoft notes that placing a shared mailbox on litigation hold requires an Exchange Online Plan 2 license, or Plan 1 with the Exchange Online Archiving add-on. If a mailbox may hold records your document retention policy or a funder agreement requires you to keep, settle that question first.
What about accounts that really cannot be individual?
Some systems allow only one login: an older vendor portal, a kiosk, a scan-to-email device. Treat each one as a documented exception with compensating controls.
- Store the password in a business password manager shared with named people, never in a spreadsheet, a shared document or on a sticky note.
- Turn on multifactor authentication wherever the system supports it, with the second factor held by the account owner. CIS Safeguard 6.3 expects MFA on externally exposed applications.
- Change the password whenever someone who knew it leaves.
- Limit device and service accounts to the one job they do.
- Write the exception down: account, purpose, owner, who has access and the next review date.
Which shared mailbox best practices keep the cleanup from coming undone?
Three habits keep it in place: tie accounts to onboarding and offboarding, review access every quarter, and report the count to leadership. Cleanup that is not built into routine work slowly reverses as staff and volunteers come and go.
- New shared mailboxes and shared logins need a short request naming an owner and a purpose.
- Offboarding removes the person from every shared mailbox and password vault entry, and triggers a password change on any shared credential they knew.
- Each quarter, compare shared mailbox access lists with your current staff and volunteer roster. CIS Safeguard 5.1 sets quarterly as the minimum.
- Report the number of generic accounts to leadership. A count that only goes down is easy for a board to follow.
What should a nonprofit do this quarter?
- Export users and mailboxes, and flag every account not named for a person.
- Block direct sign-in on every shared mailbox.
- Assign a named owner to every remaining shared or generic account, in writing.
- Convert generic email accounts into shared mailboxes, and replace shared logins elsewhere with individual or delegated access.
- Disable unowned accounts with no sign-in in 45 days.
- Add shared mailbox removal and shared password changes to the offboarding checklist.
- Put a quarterly access review on the calendar.
How s90 helps
s90's Identity Posture service maps every account in your Microsoft 365 tenant, flags shared and generic logins, and tracks the cleanup in a report leadership can read. If you would like a second look at your account list, we are happy to start there.


