patch management: Dentrix, Eaglesoft, Open Dental: Why One

Three different dental network diagrams that a single patch shield cannot fit

August 23, 2026 Dentrix, Eaglesoft, Open Dental: Why One Patching Policy Cannot Cover All Three

Posted at 05:40h in IT Security by Raymond

Ask almost any security guide what a dental practice should do to avoid ransomware and you will get the same three words: keep everything updated. It is true, and it is nearly useless as stated — because the three software platforms that actually run dentistry do not handle updates the same way, and a patching policy that treats them as interchangeable is how practices end up either half-updated and broken, or unpatched and encrypted. The uncomfortable fact behind most healthcare ransomware cases is that the vulnerability used had a fix available for months. The protection existed. Nobody installed it, or someone installed it in the wrong order and something broke, so updates got postponed “until things calm down.”

If your practice runs Dentrix, Eaglesoft, or Open Dental, here is the short answer: you need three different patching disciplines, not one, plus a coordinated plan for the operating system, database, imaging bridges, and device firmware that sit around them. Below is what that means in practice.

At a glance: how the three platforms differ

Platform	Update model	Database engine	The patching gotcha
Dentrix	Server and every workstation must run matching versions	Microsoft SQL Server	A partial rollout leaves mismatched machines that cannot connect — the office stops working
Eaglesoft	Tied to a specific, vendor-certified SQL Server version	Microsoft SQL Server (certified versions)	An out-of-sequence Windows or SQL update can break the database connection
Open Dental	Frequent releases; the whole office moves to one version together	MySQL / MariaDB	Fast cadence is a strength, but every machine still has to be on the same version at once

Dentrix: everything moves together or nothing does

Dentrix expects the server and every workstation to run the same version. That single rule shapes your entire patching approach. You cannot quietly update one operatory computer on Tuesday and the rest next month — a version mismatch between a workstation and the server can leave that machine unable to open the database, and in a busy practice that reads as a hard outage, not a minor inconvenience. So a Dentrix update is an event: scheduled after hours or on a closed day, applied to the server and every workstation in one coordinated pass, with a verified backup taken first. The corollary is that you cannot afford to fall far behind, because the longer you wait, the larger and riskier the eventual jump. This same version-and-platform coupling is why Dentrix’s own support lifecycle matters so much — when it dropped support for Windows 10, practices still on that OS were pushed into an OS migration and a software update at the same time.

A dental network where one workstation on the wrong version is disconnected from the rest — When a platform demands matching versions, a single machine left behind can take the whole office offline.

Eaglesoft: the database is the constraint

Eaglesoft’s sensitivity is less about matching every workstation and more about what sits underneath it. It runs on Microsoft SQL Server, and Patterson certifies specific SQL Server (and Windows) versions for each Eaglesoft release. That coupling is where careless patching bites: a Windows feature update or a SQL Server change applied out of sequence — or a jump to a SQL version the installed Eaglesoft release was never certified against — can sever the application’s connection to its own database. The lesson is not “don’t patch.” It is that operating-system, SQL Server, and Eaglesoft updates have to be planned together against the vendor’s compatibility matrix, rather than each being allowed to auto-update on its own whim. Automatic, unsupervised OS updates on the server are exactly the wrong setting here.

Open Dental: fast, frequent, and still all-together

Open Dental takes a different philosophy: frequent, incremental releases on a MySQL or MariaDB backend, which makes it comparatively easy to stay current. But “easy to update often” is not the same as “update whenever, wherever.” The whole office needs to move to the same version together, so even a nimble platform still calls for a coordinated rollout and a backup beforehand. The advantage a fast-moving platform gives you is that if you keep pace, each step is small and low-risk; the trap is letting a practice drift months behind and then attempting a large leap under pressure after an incident.

A layered stack of operating system, database, application, imaging, and firmware each on its own update clock — Patching is not one task. The OS, the database, the practice software, imaging bridges, and device firmware each move on their own clock.

The layers most practices forget to patch

Whichever platform you run, the practice-management software is only one layer. Around it sit several others, each with its own update cadence and its own failure mode:

The operating system. Windows and Windows Server updates are the ones attackers weaponize fastest — but on a dental network they are also the ones most likely to disturb a certified database or a driver, which is precisely why they must be tested rather than blindly auto-applied on clinical machines.
The database engine. SQL Server, MySQL, or MariaDB updates rarely make headlines in the office, yet an unpatched database or one taken to an uncertified version is both a security hole and a stability risk.
Imaging bridges and device drivers. The software that connects your sensors, pan/CBCT units, and intraoral scanners to the practice management system often lags behind and breaks after an OS jump — test imaging capture after every significant update, before you rely on it with a patient in the chair.
Network and device firmware. Routers, firewalls, NAS backup devices, and even the imaging hardware itself run firmware that needs updating. It is easy to forget the very devices that guard the network, yet unpatched edge devices are a favored way in — the kind of gap that turned VPN appliances into an open front door for ransomware gangs.

Why unpatched software is the way in

Ransomware operators are opportunists. They scan for systems running software with a known, published vulnerability — one with a fix already released — because that is the cheapest way in. In healthcare, the entry point is overwhelmingly a flaw that had been patchable for months. That is the whole reason patching is a security control and not just IT housekeeping: every unapplied update is a documented, advertised weakness sitting on your network with a countdown attached. Deploying those fixes promptly across a fleet is its own discipline, one that gets harder, not easier, when a practice has many machines to keep in step.

A patch tested on one isolated machine with a completed backup before wider rollout — Back up first, test on one machine, then roll out. The order is what separates a smooth update from a Monday-morning outage.

A patching discipline that actually holds

The way to make all of this manageable is to stop treating updates as interruptions and start running them as a routine, in a fixed order:

Inventory everything. You cannot patch what you have not listed. Know every workstation, the server, the database engine and its version, the imaging bridges, and every piece of network and imaging firmware.
Back up first, and confirm the backup. Every update carries a small chance of going wrong. A verified, recent backup turns a failed patch from a disaster into a rollback. Remember that a backup you have never restored is only a hope — test restores are what make the safety net real.
Test before you deploy. Where possible, apply an update to one machine or a staging environment first and confirm the practice-management software and imaging still work before rolling it to the whole office.
Coordinate the layers. Plan OS, database, and practice-management updates together against the vendor’s supported combinations, rather than letting each auto-update independently.
Schedule real maintenance windows. After hours or on a closed day, with enough time to verify and, if needed, roll back — not fifteen minutes before the first patient.

None of this is exotic. It is the difference between a practice that stays both current and running, and one that either breaks itself with a careless update or, more commonly, stops updating at all and waits to become a statistic.

The compliance angle

There is a regulatory reason to get this right as well. Under both HIPAA and Ontario’s PHIPA, a practice is expected to protect patient information with reasonable, current safeguards — and running software with known, unpatched vulnerabilities is difficult to defend as reasonable after the fact. A disciplined patch process is not only how you avoid an outage or a ransomware event; it is part of demonstrating the duty of care both frameworks require.

The bottom line for your practice

“Keep everything updated” is right in spirit and dangerous as a plan. Dentrix, Eaglesoft, and Open Dental each demand a different update rhythm, and around them the operating system, database, imaging bridges, and firmware each need their own attention — coordinated, tested, and backed up first. Done casually, patching breaks the office. Skipped entirely, it hands attackers the open door. Done as a discipline, it is one of the highest-return security investments a practice can make.

If you would like a practice that runs Dentrix, Eaglesoft, or Open Dental to have a patch-management process built around how its specific platform actually behaves — version-matched rollouts, vendor-certified database and OS combinations, tested imaging, updated firmware, and backups verified before every change — contact Compudent Systems. We help dental practices across Ontario stay both current and running, so an update never takes the office down and an unpatched flaw never lets an attacker in.

Sources & further reading:

Dentrix, Eaglesoft, Open Dental: Why One Patching Policy Cannot Cover All Three