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.
- Confirm what you are running. Version, patch level, and whether the database service is reachable from the workstation VLAN. Test it rather than assuming.
- 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.
- 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.
- Move the backups out of reach. Immutable, offsite, and not on a share that a compromised workstation can enumerate.
- 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.
- 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.
What a real risk analysis contains, and what the SRA Tool produces
A completed HHS Security Risk Assessment Tool questionnaire is not a risk analysis. OCR settlements have said so repeatedly. Here is the difference.
Read it How we think · 27 May 2026Why we do not run our own 24/7 SOC
The arithmetic of covering one seat around the clock, and what we do with the money instead.
Read it