Client support portal Pay invoice Sales(615) 555-0110 Support(615) 555-0111
Chartline Health IT
Dental  ·  10 Jun 2026  ·  6 min

Eaglesoft, dba, and sql

A practice management system that shipped with hardcoded database credentials, and what to actually do about it in a live operatory.

Patterson's Eaglesoft historically shipped with a hardcoded database username and password: dba and sql. Versions 17 and below stored passwords in plaintext.

This is not a secret and it is not new. It has been publicly documented for years. What is remarkable is how often we still find it unchanged during an assessment.

Why it matters more than it sounds

On its own, a default database credential is bad. In a typical dental practice architecture it is considerably worse, because of what sits around it.

Dentrix, Eaglesoft, and Open Dental typically run on an on-premise SQL or Sybase server in a closet. That server is usually on the same flat network as every operatory workstation, the front desk, the imaging server, and frequently the guest Wi-Fi. There is often no egress filtering. The backups are frequently on a share reachable from the same network.

So the practical consequence is that any compromised workstation — one phishing click at the front desk — has direct, authenticated read access to the entire patient database. No privilege escalation required. The credential is already published.

This is the structural driver behind the 2024 and 2025 dental ransomware wave, and it is why dental groups carry the highest exposure per dollar of revenue in our book.

What to actually do

The instinct is to change the password, and you should — but carefully, and it is not the whole answer.

  1. Confirm what you are running. Version, patch level, and whether the database service is reachable from the workstation VLAN. Test it rather than assuming.
  2. Coordinate the credential change with the vendor. Integrations, imaging bridges, and reporting tools may hold the credential. Changing it blind on a Tuesday morning will take the practice down, and taking the practice down is how a security project becomes a political problem.
  3. Segment the server. This is the higher-value control and it does not depend on the vendor's cooperation. The database server does not need to accept connections from the guest network, the imaging modalities, or the thermostat.
  4. Move the backups out of reach. Immutable, offsite, and not on a share that a compromised workstation can enumerate.
  5. Remove local administrator rights from clinical workstations. Almost every lateral movement path we have traced in a dental environment started with a user who had them and did not need them.
  6. Document the compensating controls. Legacy Eaglesoft also lacks granular permissions and comprehensive access logging, which is a minimum-necessary problem under §164.502(b) and an audit-controls problem under §164.312(b) at the same time. You cannot close those gaps in the application. You can document what you did instead, and that document is what an investigator will ask for.

The uncomfortable part

If your IT provider has never mentioned this, it is worth asking why. It is not obscure. It is one of the first things anyone who works in dental technology learns, and its absence from the conversation usually means dental is a small part of a general commercial book rather than the whole of it.

Next step

See where you actually stand.

Fifteen questions, each mapped to a Security Rule citation. You get a scored result naming the specific §164 requirement behind every gap. No call required to see it.

Under attack right now? (615) 555-0119

Our incident line is answered 24/7/365 by a security engineer, not a queue. Clients and non-clients both. If you are mid-incident, call before you email.