Shared mailboxes without shared passwords

A shared mailbox such as frontdesk@ should be a mailbox that nobody logs into. People reach it from their own accounts, with their own passwords and their own MFA, and every message it sends is recorded under the real person’s name. That is called delegation. It is built into Google Workspace, Microsoft 365 and PXCMail Hosted, it needs no extra software, and it removes the most common access-control finding we see in small practices and firms.

Ask a front desk how they handle frontdesk@ and you will often hear “we all know the password”. It is convenient. It also means nobody can say who sent a message, MFA cannot be turned on without breaking everyone’s phone, and a departure requires a password change that locks the whole desk out for a morning.

What a delegated shared mailbox is

A mailbox with no login of its own. People are granted access from their own accounts (read, send-as or send-on-behalf) and see it in Outlook, on their phones and in webmail alongside their inbox. When Dana at the front desk replies to a patient from frontdesk@, the patient sees frontdesk@; the audit trail records Dana. When Dana leaves, you remove Dana. Nobody else notices.

Why regulators care

The HIPAA Security Rule’s technical safeguards at 45 CFR 164.312(a) require access controls that assign a unique name or number to each user, and 164.312(b) requires audit controls that record activity in systems holding ePHI. A password six people know breaks both: there is no unique identity, so the log can only say “the front desk did it”. The administrative safeguards at 45 CFR 164.308(a)(3) add workforce procedures for granting and ending access, which a shared password makes impossible to evidence. For accounting and other firms under the FTC Safeguards Rule, 16 CFR 314.4(c) requires access controls, multi-factor authentication for anyone accessing an information system, and logging of authorized users’ activity. A shared password defeats all three.

A worked example: Lakeside Family Dental

Lakeside Family Dental is a 12-person office on Google Workspace with Dentrix. Two addresses carry most of the patient traffic: frontdesk@ for scheduling, treatment plans and referrals, and insurance@ for pre-authorizations and claims. Until last spring both were ordinary accounts with one password each, written on a card in the drawer. Three front-desk staff, the office manager and a part-time insurance coordinator used them.

The office manager’s afternoon looked like this:

1. Create frontdesk@ and insurance@ as shared mailboxes. Add the three front-desk staff and herself to frontdesk@ with send-as; add the insurance coordinator and herself to insurance@.
2. Move the two old accounts’ mail into the shared mailboxes so history and the referral threads stay searchable.
3. Turn the old logins off. Tear up the card.
4. Turn MFA on for all 12 personal accounts, which was now possible because no account was shared.

The next week a referral with a panoramic X-ray went to an oral surgeon from insurance@. The per-message record showed the coordinator’s name as the sender, the policy decision (locked delivery, because the surgeon’s server would not negotiate TLS) and the two opens on the recipient side. Six months earlier the same record would have said insurance@ and nothing more.

How to switch in an afternoon

1. List every address more than one person uses. At a dental office that is usually frontdesk@, insurance@, billing@ and referrals@.
2. Create each as a shared mailbox and add members with the right rights: send-as for addresses that correspond with patients, read-only for anyone who only needs to see the queue.
3. Move the old mailbox’s mail into it, or convert the old account in place; both Google and Microsoft support this.
4. Disable the old login. Nobody memorizes anything.
5. Check the audit trail the next day: sender names, not mailbox names.

On PXCMail Hosted shared mailboxes work this way by default and appear in Outlook, iPhone and Android with native sync. On Gateway, your Google or Microsoft admin does the same with delegation, and the provider’s own audit log keeps the attribution. Mailboxes, aliases and shared mailboxes →

Offboarding without a password change

The day a front-desk employee gives notice, the office manager removes them from frontdesk@ and disables their own account. Their phone loses the shared mailbox at the same moment, because it was never configured with its own password. There is no card to rewrite and no morning when the desk cannot read email. Write that down as your termination procedure; it is the one-paragraph policy that 164.308(a)(3)(ii)(C) asks for and that an auditor accepts. Offboarding a user →

MFA becomes possible

Shared passwords are the usual reason MFA is “not practical” at a small office: six phones cannot all receive the same code. Once every person signs in as themselves, you can require MFA on every account, including the part-timer and the seasonal hire. On PXCMail Hosted it is enforced per organization; on Gateway, turn it on in the Google or Microsoft admin console. Multi-factor authentication →

What it costs

Nothing in software you do not already have. Delegation is part of Google Workspace and Microsoft 365. On PXCMail Hosted, seats are $12 per user per month billed yearly, so Lakeside’s 12 people are $144 a month, and the shared mailboxes are set up in the console. The cost that matters is the afternoon.

Questions

Does the patient see the employee’s name?

No. With send-as, the patient sees frontdesk@ and the office name. Only the audit trail and the admin console show who sent it. Send-on-behalf shows both, which some offices prefer for referrals.

Can a shared mailbox have its own password for the scanner or the phone system?

Avoid it. Give the device its own account with a long credential and a narrow right to send, and keep it off the shared mailbox member list. If a device must send as frontdesk@, record that in your inventory so the attribution gap is known and small.

What about Dentrix or a billing system that logs in as insurance@?

Same answer: a service account of its own. Systems that send through your Google or Microsoft account inherit the PXCMail policy with no integration work, so detection and encryption still apply to what they send.

Do shared mailboxes need their own BAA or policy?

No. They are covered by the same BAA and the same policy as the rest of the organization. What changes is evidence: you can now show who accessed and sent what, which is what the audit-controls standard asks for.

We are a CPA firm, not a clinic. Does this apply?

Yes. The Safeguards Rule asks for access controls, MFA and activity logging in the same paragraph, and the IRS WISP template expects you to describe who has access to client data. A shared info@ password is the same finding with a different rule number.

---

Was this useful? Tell us at [email protected]. Related: checklists · regulations in plain English.

Sources

• 45 CFR 164.312, Technical safeguards, (a) and (b) — requires unique user identification under access control and audit controls that record activity in systems containing ePHI.
• 45 CFR 164.308, Administrative safeguards, (a)(3) — requires workforce procedures for authorizing, supervising and terminating access to ePHI.
• 16 CFR 314.4, Elements of an information security program, (c) — requires access controls, multi-factor authentication and logging of authorized users’ activity.