Review Who Has Access Before Sharing a Mailbox Password

A shared login hides who did what

A password identifies an account, not the person using it. If several colleagues sign in with the same credentials, a message sent from that mailbox does not, by itself, show which colleague composed it. The same uncertainty can apply to changes such as moving or deleting mail. This makes routine handoffs harder: a teammate may need to ask the whole group whether anyone replied, rather than checking with the person responsible.

A shared password also spreads access beyond the original conversation. Someone might save it in a browser, password manager, or written handoff, and it can remain usable after the person’s duties change. The practical issue is not only whether a password is strong; it is whether access can be limited to the people who need it and reviewed when that need changes.

Start with a clear access inventory

Before changing anything, write down who needs the mailbox and why. Separate tasks such as reading incoming requests, drafting replies, sending as the team, and managing account settings. These are different needs; a person who only sorts incoming mail may not need the same access as someone responsible for account administration.

Include former team members, temporary helpers, shared devices, and any place where the password may have been stored. If you do not know who has it, mark that uncertainty rather than assuming the list is complete. This inventory gives an administrator a concrete basis for recommending an access arrangement.

• Record each person, their work-related need, and whether that need is ongoing.
• Note known saved copies or devices, without writing the password itself into the inventory.
• Flag uncertain access so it can be addressed before the mailbox is relied on for sensitive work.

Prefer individual access when appropriate

Where available and suitable, individual access is easier to manage than a common password: each person uses their own sign-in, and access can be considered person by person. It can also make everyday coordination clearer because colleagues can discuss who is handling a task without treating the mailbox credentials as a team-wide key.

Do not assume that a mailbox alias is a separate account or login. An alias is not automatically an independent mailbox, and the right arrangement depends on what the workspace supports. Ask an authorised workspace administrator whether individual access to the needed mail is available, and whether it fits the team’s responsibilities and plan.

Ask about roles instead of guessing

If several people need to work on one address, ask the authorised workspace administrator about role-based options. Describe the actions each person needs to perform, rather than asking only for “access.” For example, explain whether a colleague needs to read messages, send replies, or change mailbox settings. The administrator can say which controls, if any, are supported for your role, plan, and provisioning state.

Do not infer that a particular permission exists just because another mail service offers it. Workspace controls and permissions vary, and server-side enforcement determines what an account can do. If the available option does not match the team’s needs, ask what alternative arrangement is supported before distributing a password.

Example request: “Please advise whether [person@example.com] can read messages for [team@example.com] without using the same sign-in as everyone else. [person@example.com] needs to read and draft replies, but does not need to manage account settings. Which supported arrangement fits this workspace?”

If a password has already been shared

Treat a widely shared password as access that may be difficult to account for. Ask the authorised administrator to review the current arrangement and advise on a supported transition. If the team decides to change credentials, coordinate the change with the people responsible for the mailbox so that legitimate work is not unexpectedly interrupted. Do not send the replacement password through a broad group message.

Review the places where the old credential may have been saved and follow the organisation’s approved process for removing or updating it. If an optional security control such as two-factor authentication is relevant, confirm whether it is available and appropriate for the account rather than assuming it is enabled. Keep the review focused on access, not on blaming a particular person.

Confirm the new arrangement works

After the administrator confirms a change, ask each intended user to sign in through their own authorised route and perform only the actions assigned to them. Check that a person who should not manage settings cannot do so, and that someone responsible for replies can complete the expected work. If an action is unavailable or an unexpected person still has access, report the specific issue to the administrator.

Finally, update the access inventory with the arrangement confirmed, who approved it, and when the team should review it again. A short review after staffing or responsibility changes helps keep access aligned with current work. It does not establish who performed past actions, but it gives the team a clearer basis for managing access going forward.