The change in the threat model
For most of the last decade, dental practice security guidance has focused on the practice's own surface: passwords, malware on operatory workstations, training the front desk not to click suspicious attachments. That guidance was correct. It is also no longer enough.
Increasingly, the way dental and dental-adjacent practices are breached is not through the practice's own credentials. It is through the IT vendor's. The vendor has remote-access tooling installed across every customer they support. When that vendor account is compromised - whether by phishing, a credential leak, or an attacker tunneling in through the vendor's own infrastructure - every customer they support inherits the breach.
What we have actually seen, in plain terms
Several recent breaches in dental and dental-adjacent healthcare were traced back to a managed service provider's remote-access account, not to the practice's own systems. The practice did everything its training said to do; the vendor did not, or could not, and the practice paid for it.
The dental-specific tell is that the lateral movement tends to land first on the practice-management database server (Dentrix, Eaglesoft, Open Dental) because it is large, central, and high-leverage. Imaging vaults follow. The practice notices when an operatory cannot open today's schedule; by that point, the encryption has been running for hours.
What "vendor as attack surface" means structurally
The vendor's remote-access tooling is doing three things simultaneously:
- It is a credential - a powerful one, scoped to your environment, often shared across the vendor's technician team and rarely rotated on technician departure.
- It is unaudited from your seat - you cannot, in most existing setups, enumerate exactly when the vendor was logged in, what they touched, and on whose authorization.
- It is the path of least resistance - attackers know this. A phish against a vendor's tech team yields the keys to dozens of practices.
The structural fix
You cannot remove the vendor's access entirely - they need it to do their job. What you can do, and what we think every practice owner should ask their vendor about this quarter, is to convert that access from opaque to auditable.
A glass-box platform makes this concrete: every action the vendor takes against your systems is logged with the policy that authorized it, on a dashboard you own and your vendor cannot edit. The vendor still works; you can see them doing it. Opacity stops being a courtesy issue and becomes a security control. (See Glass-box RMM.)
What to ask your IT vendor this quarter
- "How many of your technicians have remote access to our environment today, and how do you remove that access when one of them leaves?"
- "Where do I see the log of every time your team was logged in to our systems in the last 30 days, and what they did?"
- "Is your remote-access tool MFA-enforced for your technicians, and how would I verify that?"
- "If your tooling itself were compromised tomorrow, what is the blast radius for our practice specifically?"
- "What is your incident-response commitment to us if a breach of your tooling exposes our data?"
These are reasonable questions to ask any vendor with the keys to your operatory. A vendor who reacts defensively is itself a data point.
What CyberCore does specifically
Every action the agent takes against your environment is logged on your dashboard with the policy that authorized it and the confidence score that triggered it. Every action a human on our side takes - including the rare cases where a human needs to intervene because the agent cannot resolve a fault - shows up the same way, with the responsible engineer identified. You cannot make remote access disappear; you can make it visible.