When a 30-location DSO rolls out a new identity and access policy, IT flags every team in the organization. Each person gets their own login. MFA on everything. Standardize on a password manager for the rest. Reasonable instincts, all of them. Then the RCM director sends the note three weeks later: "We're worse off than before they started."

The problem is not MFA. The problem is that dental carrier portals were not built for MFA the way enterprise software was. And when security teams evaluate carrier portal access without understanding how billing actually uses those portals, they solve the wrong problem thoroughly.

What MFA actually looks like on a carrier portal

When a denial specialist at a central RCM team logs into the Aetna provider portal, they are logging in with credentials that belong to the practice, not to themselves. Aetna doesn't sell individual user seats to dental practices the way Salesforce sells seats to sales teams. There is one provider login per practice, or one per billing NPI. The denial specialist uses it. The eligibility coordinator uses it. The posting lead working the same queue uses it.

When IT says "each person needs their own login," the answer for carrier portals is not a configuration change. There is no configuration to make. The carrier doesn't offer individual user provisioning at the tier most dental practices are on.

That's the first thing the security team gets wrong: they assume the credential problem at carrier portals looks like the credential problem everywhere else.

Here is what happens when a biller logs into the UnitedHealthcare provider portal and the session requires a one-time code. The code goes to whatever device was registered when the account was set up. For a practice that's been operating for five years, that is usually the front desk phone. Sometimes it's the office manager's personal cell. Sometimes it's a shared Gmail address with a password nobody has changed since 2021.

At a 25-location DSO with centralized billing, your denial specialist sits in your billing center and is working a UnitedHealthcare claim. The code for that portal goes to the front desk at the practice in Scottsdale. Someone at that desk texts it to someone at the billing center. The billing center has 12 portals open and 12 potential practice front desks to track down codes from on any given morning. The code expires in 90 seconds.

The security team's new MFA policy doesn't change this. The code is still going to Scottsdale. The denial specialist is still waiting.

Why the "just use a password manager" instinct falls short

Generic password managers solve a specific problem: storing credentials so staff don't write them on sticky notes or share them by text. They don't solve the 2FA routing problem. LastPass stores your Delta Dental username and password. It does not intercept the one-time code Delta sends to the front desk office manager's cell phone. 1Password does the same, and it does it very well. It has nothing to do with where the code lands.

I have seen this play out in real procurement cycles. An IT director at a mid-sized DSO evaluates credential management options, compares them on per-seat cost, picks the cheapest tool that checks the "password manager" box on the audit list, and sends the recommendation upward. Three months later, the RCM director is back in his office explaining that the code problem is worse, not better, because billing has now been asked to follow a policy that doesn't address the actual friction. The per-seat math was correct. The diagnosis was wrong.

Generic password managers are excellent products for what they do. They simply don't do what dental RCM billing staff actually need at carrier portals, because the problem isn't credential storage. It's real-time authentication routing across carrier portal systems that each have their own behavior, their own registered devices, and their own failure modes.

What billing sees that IT doesn't

There are roughly 350 dental insurance carriers that practices bill to with any regularity, depending on geography and plan mix. Each one has its own portal. Each one has its own session timeout, its own MFA behavior, and its own device registration from whenever the practice originally set up the account.

Some carriers route codes to email. Most route to a registered phone. A handful still require you to call their provider line to retrieve a code, which takes four to 12 minutes. Three carriers I've tracked recently have started rolling out Authenticator app enrollment, though that enrollment requires portal access to begin with, which creates a loop if you've lost access to the original registered device.

The security team knows about MFA as a concept. They don't know about how Delta Dental of California's portal handles session timeouts differently from Delta Dental of Pennsylvania, or how the Cigna portal treats centralized billing users when the registered phone number is at a practice location that's not where the billing team sits. That knowledge lives in the RCM team. It is tacit. It doesn't appear in any carrier's IT documentation.

When IT runs an access audit, they see shared credentials and flag them. They don't see the reason those credentials are shared: the carrier portal offers no clean alternative at the practice billing tier, and the alternatives that exist at higher access tiers involve credentialing processes that take months and still don't solve the routing problem.

The RCM lead who has been doing this work for years is not sharing credentials because she doesn't know better. She's sharing credentials because the carrier's system architecture leaves no clean option, and she's built informal workarounds that keep claim throughput moving. Flagging the shared credentials without understanding the architectural constraint doesn't make the practice more secure. It makes the billing team spend more time on workarounds, which makes them less consistent about following any policy at all.

What actually needs to change

This is not an argument that security doesn't matter at carrier portals. HIPAA is explicit: systems containing protected health information require a unique user identifier and an audit trail of who accessed what and when. Carrier portals contain protected health information. Shared logins in Chrome, or passed via text message, satisfy neither requirement.

The argument is that the audit trail and the routing problem have to be solved together, not as two separate workstreams. A credential policy that enforces unique identifiers without fixing the routing problem forces billing staff to work around it. A routing fix that doesn't maintain per-user access logs doesn't satisfy the audit requirement. Both problems need an answer from the same system.

This is what Unify does for central RCM teams. When a denial specialist at your billing center logs into any of the carrier portals your practices use, Unify routes the one-time code automatically. No call to the front desk in Scottsdale. No 90-second countdown while someone finds the right desk to text. The code surfaces where the billing team is. Unify also maintains a per-user log of who accessed which portal and when, so the audit trail that HIPAA requires is built into the workflow rather than reconstructed from memory after the fact.

We have built carrier-specific workflows for over 350 dental portals. The variation in how each carrier handles authentication is exactly why a generic password manager can't cover this: it would require knowing the behavior of every carrier, maintaining it as carriers change their MFA policies, and routing codes accordingly. That's not a password manager. That's a dental-specific carrier portal layer.

When your security team reviews your carrier portal access posture, the useful question is not "who has these credentials?" The useful question is "who received the last authentication code for the Delta Dental portal at your Phoenix location, and can you prove it?" That is a billing workflow question. It only makes sense if you understand what Delta's portal actually does when it sends a code.

Most security teams don't know the answer. Your RCM lead does. And if the two of them have been talking past each other in access reviews, it's usually because the security team is asking about a storage problem and billing is describing a routing problem. These are different conversations.

If you want to walk through what this looks like at your organization, book a call with me directly: https://calendly.com/tanner-unify/unify-demo. I'll ask which carriers your central billing team accesses most, and we'll look at exactly where the routing problem shows up in your stack.