I'm a few months into a technician role at a small MSP that primarily supports dental practices. My previous experience was in a large corporate IT environment with well-defined processes, but many of these offices currently use shared workstation passwords, common local accounts, and widespread administrator access. Most do not have an on-premises domain.
My manager wants new clients to use managed individual accounts and a more structured identity platform, and he has asked me to improve security for some existing clients as well. I'm comfortable with traditional Active Directory, but I'm unsure how much can realistically be improved for larger practices without moving them to a domain. Dental applications such as Dentrix, Eaglesoft, Open Dental, imaging systems, cameras, and other chair-side equipment may also require local servers or elevated privileges.
What would be a sensible security-improvement roadmap for these practices? I'm especially interested in identity and access management, MFA, endpoint protection, patching, backups, compliance responsibilities, and deciding between on-premises Active Directory and cloud services such as Entra ID and Intune. Our current toolset includes Ninja RMM, OpenText, and Complete UniFi deployments.
5 Answers
Dental software can make a clean security design complicated. Dentrix, Eaglesoft, Open Dental, imaging platforms, cameras, and chair hardware may depend on local servers, service accounts, application-specific permissions, or elevated rights. Before removing admin access or changing sign-in methods, verify the vendor’s supported configuration and test it on a pilot workstation.
Some offices will benefit from a hybrid design: cloud identity and device management for users and endpoints, with a properly secured local server for the clinical applications. Avoid assuming that every program should simply run as administrator, but also avoid breaking a production system without a documented alternative.
Start with governance and risk ownership before changing technology. The practice is responsible for its healthcare privacy and security obligations, including assigning privacy and security officers, performing a risk assessment, and maintaining an appropriate security plan. Your MSP should also have a properly scoped business associate agreement and clearly documented responsibilities.
Use that assessment to prioritize the technical work: eliminate shared accounts, require unique users and MFA, remove unnecessary admin rights, establish patching and antivirus/EDR coverage, verify backups with routine restore tests, and document incident-response procedures. You can recommend controls, but the practice owners need to approve the cost and accept the remaining risk.
That ownership issue is often the hardest part. Some offices expect the MSP to fix everything while treating compliance as someone else’s problem, so the scope and responsibilities need to be written down clearly.
Build a repeatable baseline for every client. At minimum, deploy centrally managed antivirus or EDR, a reliable patching process, tested backups with an offline or otherwise protected copy, full-disk encryption where supported, firewall and Wi-Fi segmentation, least-privilege accounts, and MFA for email, remote access, RMM, backups, and administrative tools.
Also inventory every device, server, account, application, and external access path. Document exceptions instead of silently granting local admin rights. Have a specific process for former employees, lost devices, suspicious activity, and restoring a workstation or server. The tools matter less than consistently applying and checking the controls.
Present this as a business and patient-data protection project rather than just an IT preference. Give each owner a short prioritized plan with the risk, recommended fix, estimated effort, cost, and any effect on clinical workflow. Start with high-impact items such as shared passwords, exposed remote access, unsupported systems, missing backups, and accounts belonging to former employees.
Do not assume a domain is automatically secure, and do not assume cloud services remove the need for good administration. Either model can be secure when it has unique identities, strong authentication, limited privileges, current software, monitoring, tested recovery, and management buy-in.
For many small practices, Microsoft 365 with Entra ID, Intune, and Defender can provide a strong baseline without immediately deploying traditional domain controllers. Move away from shared logins, give every employee an individual account, enforce MFA, use conditional access where licensing supports it, manage endpoints, encrypt devices, and standardize security policies.
Whether this works depends on the applications. If the practice software and imaging systems are hosted locally, you may still need a server and possibly on-premises Active Directory. If the applications are cloud-based or can operate with local application accounts, a cloud-managed setup may be simpler. Treat Entra ID and on-premises AD as design choices based on application and operational requirements, not as mutually exclusive trends.
We already use Entra for some users with email and MFA. I’m trying to determine whether it can handle workstation sign-in and file access when the dental server is not joined to a traditional AD domain.
That has been our experience too. We support a mix of Dentrix, Eaglesoft, and Open Dental, and the imaging and practice-management components often have special requirements. A per-application review is necessary before standardizing permissions.