Shared Payer Portal Logins and MFA in Dental Groups: The 2026 Fix

Your biller at the second office is staring at a Delta Dental sign-in screen that wants a six-digit code. The code went to a phone that lives at the first office, in the handbag of the person who set the account up two years ago, and she is with a patient. Everyone knows the login is shared. Nobody is sure how to stop.

This guide is for the operations or revenue-cycle lead of a dental group with more than one office. It records what the payers themselves publish (every page re-read on 6 November 2026), lays out the options with what each fixes and what it does not, gives you a register you can copy, a 30-day rollout, a procedure for the day a biller leaves, and the part your IT provider owns. It does not argue whether HIPAA requires MFA; it quotes the rule text and leaves the reading to your compliance officer.

Why do dental groups end up sharing payer portal logins?

Groups share payer logins because portal accounts were created office by office, usually by whoever enrolled with the payer, and nobody was ever given the job of adding and removing users across every payer and every location. When payers added mandatory MFA in 2025, the habit stopped being an annoyance and started stopping work.

Three forces produce the shared login, and they stack:

MFA changed the arithmetic. Delta Dental of Washington's provider page says that "Only one contact method can be associated with each account," and that MFA is required "upon your initial login, when accessing the portal from a new device or browser, after 8 hours of continuous use, or following 30 minutes of inactivity." One account, one phone, several billers in several buildings: the code is always somewhere else.

No report in your practice management system records the delay, so it never reaches a budget meeting: a few minutes per eligibility check, multiplied by every biller, every office and every re-authentication timer, is paid in overtime and in claims that wait. Our guide to hidden IT costs in dental groups covers how to put a number on this kind of friction.

What do the payers actually allow?

Most of the large dental payers already issue individual logins, and several say in writing that shared accounts are discouraged or against their terms. What differs is the MFA method each supports, which decides whether a vaulted shared credential can even work. The table records only what each payer publishes on its own pages.

Payer and vendor pages checked 6 November 2026. Each Delta Dental member company publishes its own rules, so confirm with the ones you bill.

Two details in that table decide your design. First, Delta Dental's published methods are email, text and voice, with no authenticator app, so a code for a Delta Dental account must land in a mailbox or on a phone that your group controls. Second, Availity and Principal accept an authenticator app, which means a credential stored in a business password vault can generate its own codes.

Does HIPAA say anything about sharing a payer login?

The Security Rule does not mention payer portals, multi-factor authentication or shared logins by name. It does set standards for your workforce's access to electronic protected health information, and the portal account is how your staff reach patient eligibility and claims data. What follows is the rule text, not a reading of it.

The technical safeguards at 45 CFR 164.312 include "(i) Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity," and the standard "(d) Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed." The administrative safeguards at 45 CFR 164.308 include "(C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends," and "(D) Password management (Addressable). Procedures for creating, changing, and safeguarding passwords."

A payer's portal is the payer's system, and how these standards apply to an account on someone else's website is a question for your compliance officer or counsel. What is not in question is practical: a shared login gives you no way to say which person signed in, and a former employee who still knows the password can keep signing in until it is changed.

On the proposed rule: HHS published a proposed update to the Security Rule on 6 January 2025 (90 FR 898); the comment period closed on 7 March 2025. The Fall 2025 Unified Agenda entry for RIN 0945-AA22 shows the stage as "Long-Term Actions" and a timetable line reading "Final Action 07/00/2027", which is the agency's own placeholder, not a compliance date. Until a final rule is published, the MFA deadlines your group has to meet come from the payers and from your insurer.

Which option fits your group?

Register every biller individually at each payer that issues personal accounts, and move whatever cannot be split into a business password vault, with the code generated there or sent to a mailbox the group controls. You are replacing the one phone and the unsecured shared inbox. The table shows what each option fixes and leaves broken.

Option 1: a login per person at every payer that offers one

Delta Dental's pages tell you to create an account per team member, Availity's guide says user accounts are free and that your administrator creates them, and Principal registers each person by email address. It is the only option where the payer's own log names the person and where one departure means deleting one account. The cost is the registration work itself, repeated for every payer and every office, which is why someone has to be assigned to it with time to do it. Best for: every payer in the table above.

Option 3: a role mailbox for payers that only email codes

Where a payer sends codes only by email, text or voice and offers nothing else, the code has to reach a destination your group controls. The California Dental Association's advice to members is to use "an office phone as the second authentication factor" and, where email is allowed, "a general office mailbox that all team members can access," because a factor tied to one employee fails when that employee leaves. Treat this as the least bad choice, not the goal: the mailbox itself becomes the key to every portal that sends codes there, so it needs its own MFA, named delegates rather than a shared mailbox password, and a review every quarter. Best for: Delta Dental accounts that cannot be split into individual logins yet.

Option 4: a vaulted shared credential with the code in the vault

A business password manager can hold a payer login and generate its time-based code in the same record. Bitwarden's help notes that "Generating TOTP codes is available with Premium or membership to a paid organization"; 1Password stores one-time passwords inside the Login item; Keeper's guide says shared records mean staff "won't need to track down the person who has the only device containing the code." Each biller signs in to the vault as themselves, so the access log names the person even when the payer sees one account. It only works where the payer supports an authenticator app, which Availity and Principal do and Delta Dental, by its own FAQ, does not. Best for: payers that offer app-based codes but no individual logins.

Option 5: let the eligibility tool hold the credentials

Several eligibility and verification tools store your payer logins and run checks for you. DentalXChange's knowledge base shows the pattern: for each Delta Dental state portal you create a credential, generate a tool-specific email address under "MFA Management," and set that address as the MFA contact on the payer account. That removes the code from your front desk and puts it with a vendor. Before you rely on it, have the agreement, know where the credentials are stored, and review who at the vendor and in your group can see them. Our update on the eAssist billing-vendor incident is the reason to ask. Best for: groups already using such a tool, with vendor access reviewed.

How do you build a payer access register?

A payer access register is one table, owned by one named person, listing every payer portal account your group holds, the office and tax ID it belongs to, who can use it, how its code is delivered and when it was last reviewed. The rollout, the leaver procedure and your insurance application all read from it.

Build it with these columns:

A 30-day rollout that groups can actually finish:

1. 1. Week 1: inventory. Ask every office manager and the billing team for every portal they sign in to, including the ones "the old manager set up." Add the eligibility tools and clearinghouses that hold payer credentials.
2. 1. Week 1: assign the register. Give it to the billing or revenue-cycle lead, because that is the desk that approves who works which payer queue and takes the first call when a login fails. IT keeps the vault, the mailbox security and the offboarding trigger.
3. 1. Week 2: claim individual logins. Start with the payers that already offer them and carry most of your volume. Register each biller under their own email address.
4. 1. Week 2: deploy the vault. Per-person vault accounts for the billing team, a shared collection or folder for payer logins, codes generated in the vault where the payer allows an authenticator app.
5. 1. Week 3: fix the code destinations. Move every remaining email-only code to a role mailbox with its own MFA and named delegates; move voice and text codes to an office line, not a personal phone.
6. 1. Week 3: rotate the inherited passwords. Every shared password that former staff or a selling dentist may know gets changed once the new access is in place.
7. 1. Week 4: write the two procedures. New biller joins; biller leaves. Both start from the register.
8. 1. Week 4: review with your insurance application open. The questions about individual accounts, MFA and revocation should now have answers you can show. Our guide to dental cyber insurance requirements lists what carriers ask for.

What happens to payer portal access when a biller leaves?

On the last day, the register shows which payer accounts the person could reach, and each is handled: individual accounts disabled at the payer, vault access removed, role-mailbox delegation withdrawn, and any shared password they knew rotated that day. Your own directory cannot reach accounts on a payer's website, so the register is the only list that catches them.

The per-portal procedure, in order:

1. 1. Open the register and filter by the person's name.
2. 1. For each individual payer account: sign in as the administrator where the payer has one, or call the payer, and remove the user.
3. 1. For each vaulted shared credential: remove the person from the vault; schedule a password rotation and update the record, and the register, with the new one.
4. 1. For each role mailbox: remove their delegation; if they knew a mailbox password rather than holding delegated access, change it.
5. 1. For each eligibility or verification tool: remove their user in the tool, and confirm that the tool's own generated inboxes were never shared with them.
6. 1. Record the date against each row.

Our dental employee IT onboarding and offboarding checklist covers the wider access change; payer portals are the rows that get missed because no directory or single sign-on tool knows they exist.

The IT side: what your IT provider controls, and what it cannot

Your IT provider cannot create a user at Delta Dental for you, but almost everything around the portal account is on their side of the line: the mailbox that receives codes, the workstation that remembers the password, the vault, the logs and the vendor access. Most shared-login risk lives in those surroundings, not on the payer's website.

The role mailbox is an account too. If codes land in billing@yourgroup, that mailbox must have MFA on it, named delegates instead of a password that everyone types, and no automatic forwarding. A mailbox that exists only to receive sign-in codes is a high-value target, and the same six settings that stop email takeovers apply to it; see HIPAA email for dental offices for the setting list. For how shared mailboxes and licenses fit together, see our guide to Microsoft 365 for dental offices.

Browser-saved passwords on shared workstations. A payer password saved in Chrome or Edge on a front-desk PC is available to anyone at that keyboard, and travels with the browser profile. Your provider should turn off browser password saving by policy and move the credentials into the vault, which also autofills; our guide to password management for dental offices covers the wider policy.

Shared Windows logins in operatories and at the front desk. A payer account per person achieves nothing if six people sign in to Windows as "FrontDesk." Per-person Windows accounts with fast user switching are the floor; the question an MSP asked on r/sysadmin in August 2025, "What satisfies HIPAA without being a usability nightmare?", is the one to put to your provider, and the answer is per-person logins that take seconds.

Your own identity versus the payer's. Microsoft's documentation allows a user "a combination of up to five OATH hardware tokens or authenticator applications" on one Microsoft Entra account; Delta Dental of Washington allows one contact method per portal account. Design around the stricter one: the portal.

Code method quality. CISA's fact sheet on phishing-resistant MFA says that app- or token-based one-time passwords and push with number matching "are the best options for small- and medium-size business that cannot immediately implement phishing-resistant MFA," and that SMS or voice codes "should only be used as a last resort MFA option." Where a payer offers an authenticator app, use it; where it offers only email or text, the role mailbox and office line are the controlled version of a last resort.

Codes are now something staff can be tricked into reading out. A caller claiming to be "from the portal" or "from IT" asking for the code on your screen is the attack that MFA invites. Our guide to fake IT support scams aimed at the front desk covers the script to give your team.

Acquisitions. An acquired office's payer accounts are registered under its tax ID and stay separate after closing. Add them to the register during diligence, rotate every shared password on day one, and treat the seller's continuing access as a decision, not a default.

Vendor-held credentials. An eligibility tool that stores your payer logins is a business associate with keys to patient data at every payer you bill. Put its generated inboxes and its user list in the register, and include it in your vendor access review.

Payer access is checks 1 to 4 of the 26-point dental office cybersecurity checklist applied to accounts you do not host. If you want the surrounding controls, the mailbox, the vault, the workstation policy and the logging, looked after as one system, that is the conversation to have about dental cybersecurity services for a group.

What to ask your IT provider about payer portal access

How Legend Networking can help

Legend Networking is a Dallas-based dental IT company that has served over 3,500 practices since 2004, with in-house engineers, no outsourced first-level triage and 24/7 monitoring. If your group is working through per-person identities, workstation policies, mailbox security and vendor access, ask how our DSO IT support would approach them across your offices. If you are weighing a plan for the whole group, see what managed IT services for dental practices cover.

The author, Ian Lynch, has 22 years in dental IT and oversees the NOC, onsite dispatch and client technology roadmaps. Legend holds a 4.8 rating from 173 Google reviews. For an example of the groundwork, see a technology upgrade for a dental group covering computers, server infrastructure, networking, applications, software and security, and find dental IT support in your city.