Can You Share a Payer Portal Login? MFA, User Accounts and Credential Rotation
Payer portals like Availity and UnitedHealthcare require a separate login for every user. Here's how to handle administrators, billing vendors, MFA and password changes.
Updated November 5, 2026, based on Availity, UnitedHealthcare, Blue Shield of California, HHS, the federal regulatory agenda and NIST as of that date.
No. Major payer portals expect every person who signs in to have their own login. Availity's help center says each user needs an account that is unique to them, and UnitedHealthcare's portal FAQ says each user needs to create their own One Healthcare ID.
A shared login breaks the portal's rules, and it hides who did what. When a claim is changed or an authorization is submitted under one shared account, nobody can say later which person did it. It also means one password change or one lockout stops everyone at once.
Most of the fix is administrative. Each portal needs a named administrator, every person and outside party needs their own account, and MFA and password changes need a plan before they cause outages.
Major payer portals require one login per person
The large portals spell this out. Availity's account guidelines say "sharing a single user account among several users goes against Availity's security policy," and tell anyone using a shared login to ask their administrator for their own account.
UnitedHealthcare's FAQ is just as direct. Its answer on sharing a One Healthcare ID begins "No," and says each user needs to create their own ID and connect it to the tax IDs they work under.
For other plan portals, read the user agreement your organization accepted when it registered. That agreement is what the plan will point to if an account is suspended.
HIPAA's unique user ID rule points the same way
Payers run their portals as systems that hold protected health information, so the HIPAA Security Rule applies to them. Under 45 CFR 164.312, unique user identification is a required specification, so each user is assigned a unique name or number that tracks their activity.
The same section requires audit controls that "record and examine activity" and procedures to verify that a person seeking access is who they claim to be. A shared login undermines all of these, because the audit log can only show which account acted.
The portal's own terms are what you agree to, and they can be more specific than the rule. The Security Rule helps explain why they say what they say: with a shared login, nobody can tie an action to a person.
Your organization's portal administrator controls access
On Availity, the person who registers the organization becomes its primary administrator, and other portals use a similar role. Administrators add and manage users and control what they can access.
Make sure you know who that person is for each portal you use. Availity users can find their administrators under My Account, on the Organization(s) tab. If the only administrator has left the company, fix that first, because nobody else can add users until it is resolved.
A few habits keep this manageable:
- Name a primary and a backup administrator for each portal.
- Keep a list of who has an account on which portal and under which tax ID.
- Remove access the day someone leaves, as part of offboarding.
- Review the user list each quarter against your staff roster.
Billing companies and vendors get their own accounts
Outside parties should not use your staff's logins either. Blue Shield of California's Availity FAQ for providers describes the setup for billing services: each business registers with Availity and sets up its own users. The billing service gives its user IDs to the practice, and the practice adds those IDs to its organization.
That keeps the billing company's activity separate from yours in the portal's records. It also means you can remove their access without changing anyone else's password. Ask the same question for any vendor or tool that will sign in on your behalf: whose account will it use, and can you see and remove that account yourself?
What MFA looks like on payer portals
Second-factor methods vary by portal. UnitedHealthcare's One Healthcare ID help center walks users through setting up an authenticator app, and offers sign-in with a passkey. Availity's 2-step authentication help says users are prompted to enroll after they log in, that SMS and voice have been phased out, and that an account can connect to one authenticator app on one device at a time.
MFA makes shared logins harder to keep running. If the code goes to one person's phone or inbox, that person has to be available every time anyone signs in. Codes sent to a shared mailbox spread the problem around instead of solving it. Individual accounts let each person carry their own second factor.
HIPAA itself does not name MFA today. HHS has proposed changing that: the proposed Security Rule update published January 6, 2025 would require multi-factor authentication using at least two of three kinds of factor, something you know, something you have, and something you are. It is still a proposal: the federal regulatory agenda entry for the rule lists it as a long-term action, with final action targeted for July 2027. Check that entry for its current status before you plan around it.
Plan logins around batch volume
Whether one login can hold more than one session at a time varies by portal. If your team runs eligibility checks or claim status lookups in batches, the number of accounts can limit how much work happens at once.
Work this out before a busy week. If 50 new patients need checks on a Monday and three people have accounts on that portal, those three people set the pace. Adding accounts for more staff goes through the same administrator, so ask early. The guides to Availity automation and UnitedHealthcare portal automation cover what those batches usually include.
Password changes without breaking work
Portals set their own password rules, and you have to follow them, including any forced change on a schedule. Federal guidance has moved away from scheduled changes. NIST's Digital Identity Guidelines, SP 800-63B, say verifiers "shall not require subscribers to change passwords periodically," but shall force a change when there is evidence a password was compromised.
Whatever the portal requires, plan for the change:
- Track when each account's password expires, so it doesn't lapse in the middle of a batch.
- When someone changes a password, update everywhere it is stored on the same day, including any password manager or tool that signs in for you.
- Stop using a password that has failed. Repeated failed attempts can lock the account, and restoring it may need identity verification, the portal administrator or the portal's support line.
- Treat an unexpected password reset email as a possible compromise, and tell the administrator.
Frequently asked questions
Can two staff members use the same Availity login?
No. Availity's guidelines say each user needs their own account, and that sharing one goes against its security policy. Ask your organization's Availity administrator to create a separate account for each person.
Can our billing company use our login?
It shouldn't. The billing company should register and set up its own users, and your administrator adds those user IDs to your organization. That keeps their activity separate from yours and lets you remove their access on its own.
What happens if the person who owns the portal account leaves?
If they were the only administrator, nobody else can add or remove users until the portal reassigns the role. Each portal has its own process for that, so start with its support line. A backup administrator on every portal avoids the problem.
Does HIPAA require MFA?
Not by name today. The current rule requires unique user IDs and verifying who is signing in. HHS proposed in January 2025 to require MFA explicitly, and the federal regulatory agenda targets a final rule for July 2027. Some portals, including Availity's and UnitedHealthcare's, already ask for a second factor.
Can an automation tool have its own portal login?
It depends on the portal's terms, so check the user agreement and ask the plan if it isn't clear. Wherever it is allowed, give the tool its own account rather than a staff member's, so its activity is recorded separately and its access can be removed on its own.
Juggling logins across payer portals?
Champ automates portal work like eligibility checks and authorizations. We set it up and run it, so your staff sees only the finished results. If portal logins are slowing down that work, learn more here.
This post is general information, not legal, compliance or billing advice. Rules vary by payer and portal and change often, so confirm with each portal's administrator or support team and your compliance lead before acting. Champ is not affiliated with or endorsed by Availity, UnitedHealthcare, Blue Shield of California, HHS or NIST.
Continue reading
See all
Prior Authorization Turnaround Times: What CMS Requires Payers to Meet
Under CMS-0057-F, most Medicare Advantage and Medicaid plans must decide prior authorizations within 7 days, or 72 hours when urgent. This guide covers who the rule applies to, when payers can extend, and how to keep requests moving.
Payers Without an API: How RCM Software Gets Eligibility, Claim Status, and Prior Auth Answers
HIPAA standardizes the format of eligibility, claim status and prior auth transactions, not how much detail comes back. Here is what X12, CMS-0057-F APIs, portals and phone each return, and how to set a fallback order per payer.
Why In-Network Claims Deny as Out-of-Network: Enrollment and Roster Errors
Out-of-network denials for contracted providers can trace to the payer's provider record or the member's plan. How to read the codes, fix the record and get claims reprocessed.