Endpoint & Detection
A field-tested hardening guide for the document management and practice management systems law firms actually use — access controls, audit logs, MFA, BYOD policy, and the integration gaps that get firms breached.
Law firm document management is one of the most security-sensitive deployments in any small business vertical. Every matter file is a privileged communication. Every search hit is potentially work product. And every system on the market — NetDocuments, iManage Work, Clio, MyCase, ProLaw, PracticePanther — was built around workflow, with security configuration documented as an afterthought.
This is a practitioner hardening guide for the systems I see most often in the field. The vendors document what the software does. They do not really document how to deploy it in a way a malpractice carrier or state bar disciplinary counsel would call reasonable. The defaults are not secure, and the defaults are what most firms are running.
Every legal-vertical DMS vendor publishes a deployment guide. None publishes a security baseline that maps to ABA Model Rules 1.6(c), 5.1, and 5.3, or to the state cyber-incident notification statutes that now apply in most jurisdictions. The deployment guide does not tell you to disable shared accounts, audit your SAML claims, rotate API keys, or test your restores.
That gap is what threat actors walk through. The pattern is consistent: a shared paralegal login with reused credentials, MFA on the SSO front door bypassed by a forgotten API key, a personal iPad with cached matter documents and no passcode. None of it requires a zero-day.
The most common finding on a law firm assessment is a shared account. It is usually called ParalegalDesk, Reception, or LegalAssistant, and three to five people log into it across the workday. More often than not it has firm-wide access because nobody wanted to tell a partner the floater paralegal could not open a file.
That configuration breaks several things at once. ABA Model Rule 5.1 makes partners and supervising attorneys responsible for subordinate attorneys; 5.3 extends the same obligation to nonlawyer assistants. Both presume the firm can identify which person did what. A shared login makes that impossible. When a client asks why their settlement memo was downloaded the day before opposing counsel filed a related motion, "one of four paralegals" is not an answer.
Every system in this guide supports per-user accounts and role-based matter access. NetDocuments has cabinet- and workspace-level security; iManage Work has the most granular permission model in the category; Clio Manage, MyCase, and PracticePanther all support per-user logins with matter-team scoping; ProLaw supports per-user accounts with role-based security templates.
The practical recommendation: one account per attorney, one per paralegal, one per staff member, no shared logins, and matter access scoped to the representation team rather than granted firm-wide. Do this before anything else on the list — most of the controls below depend on it.
Every DMS in this category supports MFA, either natively or through SAML SSO. The mistake firms make is assuming MFA on the Microsoft 365 or Google Workspace SSO is sufficient because all DMS logins flow through it. They do not.
NetDocuments supports MFA natively and through SAML SSO with Entra ID, Okta, and others. Both must be configured, and MFA should be required for every user — not optional and not "remembered" indefinitely.
iManage Work supports MFA and SAML SSO. The SAML configuration is where firms get bitten — the claim that determines which users can authenticate is often left permissive, and a misconfigured claim can let a federated guest user log in with an iManage account that was never deprovisioned. Audit the SAML claims and the iManage user table together; they should reconcile exactly.
Clio Manage offers MFA via Clio Identity or third-party SSO; the default is available, not required. MyCase, ProLaw, and PracticePanther all support MFA. Enable it firm-wide, do not allow per-user opt-out, and review the user list quarterly for lapsed enrollments.
The failure mode that catches every firm: the SSO front door has MFA, but a service account or API key path bypasses it. The Outlook plugin syncing sent items to NetDocuments, the e-signature integration pushing executed documents back to iManage, the e-discovery vendor with read access to a single matter — each uses a token that does not flow through the SSO MFA prompt. More on that below.
Cloud-hosted DMS (NetDocuments, Clio, MyCase, PracticePanther) shifts the server-hardening burden to the vendor — a real benefit for any firm without dedicated IT staff. iManage Work on-prem and older ProLaw deployments leave that burden with the firm. The threat model differs accordingly.
In cloud DMS, the dominant threat is account compromise and integration token theft. The control set is identity-layer: MFA, conditional access, managed identity threat detection on the Microsoft 365 or Google Workspace tenant, and active monitoring of API key activity inside the DMS.
In on-prem DMS, the dominant threat is server compromise. The firm owns the Windows Server build, the SQL Server hardening, the backup architecture, the patch cadence, and the EDR coverage. Most ransomware incidents I have seen in small law firms began with an on-prem document server that nobody had touched since installation.
If you are running iManage Work on-prem or an older ProLaw installation, the server is a Windows machine holding the firm's most sensitive data. Treat it like one.
A defensible baseline:
sa password is weak or vendor-default. Rotate it, remove sa from interactive use, create named SQL accounts for maintenance, and audit sysadmin membership monthly.Remote access is where small law firms get breached. The wrong patterns repeat: TeamViewer or AnyDesk on a partner's home laptop with a static password and no MFA; port-forwarded RDP to a paralegal's desktop on TCP 3389; a shared MSP RMM agent on the DMS server with no per-technician audit trail.
The right patterns are not exotic. Entra ID conditional access on every firm device, requiring compliance and MFA before any session touches the DMS. MFA on every remote session, not just the first one of the day. Time-boxed, just-in-time access for the outside IT vendor — granted when work is scheduled, revoked when it is done, with the session recorded and the agreement in place under MR 5.3. No port-forwarded RDP from the internet.
If you only do one thing this quarter, remove the unattended TeamViewer and the port-forwarded RDP.
Every system in this guide records who did what to which matter at what time. Almost no small firm has ever opened the log.
A monthly review of fifteen to thirty minutes catches what matters: bulk downloads in the days before an associate departure, after-hours access from an unusual location, deleted documents on closed matters, permission changes nobody requested in writing, and API key activity from an integration nobody remembers enabling. The cheapest control on the list, and the one most consistently skipped.
Every modern DMS lives inside an ecosystem of integrations: the Outlook plugin that files emails to the matter, OneDrive or Google Drive sync, Adobe Sign, DocuSign, court filing services, e-discovery vendors, contract lifecycle tools. Each authenticates with an API key, service account, or OAuth token, and each bypasses the front-door MFA that protects human users.
Two things to do:
Partners want to read matter documents on personal iPads, personal laptops, and personal phones. The friction between that expectation and the firm's supervisory obligations under MR 5.1 is real and unavoidable.
The compliant pattern is a managed-app configuration on the personal device. Intune App Protection Policies on the NetDocuments or iManage mobile app create an encrypted container for firm data, require a passcode, and let the firm remote-wipe matter data without touching the partner's photos. MaaS360, Hexnode, and similar MDM platforms support equivalent per-app policies — palatable to partners who do not want the firm controlling their personal phone.
The non-compliant pattern is the partner forwarding documents to personal Gmail and working from there. We have found this configuration during onboarding more times than I care to count. It is a supervisory failure under MR 5.1 and, depending on the matter, a likely violation of 1.6(c) — and it tends to be invisible until a forensic engagement turns up the forwarded messages months later.
The traditional 3-2-1 backup rule does not survive a ransomware-active threat model. The version I deploy for law firms is 3-2-1-1-0: three copies, two media types, one offsite, one immutable, zero errors on verification.
For cloud DMS, the firm still needs its own backup. The vendor SLA is not a backup, and the vendor's retention policy is not designed for the firm's litigation hold or matter-closure obligations. Use a third-party SaaS backup product — Backupify for Clio, Spanning for Microsoft 365 — and verify recovery quarterly.
For on-prem DMS, the immutable copy is the control that survives ransomware: S3 Object Lock, Backblaze B2 Object Lock, Wasabi compliance mode, or equivalent. Test the restore monthly on a non-production machine, open the DMS database, and confirm a recent matter document opens correctly. Most firms have not tested a restore in over a year.
Outside vendors with matter access — e-discovery platforms, court reporters, expert witnesses, contract attorneys — each need a written agreement specifying data handling, breach notification, and return or destruction of data at matter close. The agreement is how MR 5.3 supervision becomes demonstrable rather than aspirational. A short standard form reviewed by ethics counsel once and applied consistently, sent before access is granted, with matter and vendor tracked on a single sheet.
When we onboard a small law firm, the typical sequence is straightforward:
None of this is exotic. All of it is the difference between a firm that recovers from an incident in a week and a firm that pays a ransom, notifies clients under state breach law, and explains itself to the state bar's office of disciplinary counsel.
If you run a small law firm and are not sure where you stand against this list, book a briefing. We will walk through your DMS configuration, your audit logs, your integration tokens, your BYOD policy, and your backup strategy, and tell you honestly what to fix first.
Last updated
May 14, 2026. We refresh this content as the threat landscape and tools evolve.
FAQ
Every action in a document management system — opening a matter, downloading a file, deleting a document — is attributed to whoever is signed in. If three paralegals share one account, your audit log cannot answer who downloaded a specific privileged file the day before someone left for a competitor. ABA Model Rule 5.1 and 5.3 make partners and supervising attorneys responsible for the reasonable supervision of attorneys and nonlawyer assistants, and that responsibility is impossible to demonstrate without per-user identities. Every system in this guide supports them; the work is enabling them and training the firm to use them.
Yes. The SSO front door is one path in. The DMS itself almost always has its own user accounts, service accounts, and API key paths that do not flow through Entra ID. We routinely find firms where every human user has SSO with MFA, but a five-year-old API key for a retired e-discovery vendor still has full read access to the matter store. Turn on MFA inside the DMS, and audit the integration tokens separately.
BYOD is the awkward conversation in every law firm engagement. The compliant pattern is a managed-app configuration — Intune App Protection Policies on the NetDocuments or iManage mobile app, or an equivalent MDM container — that encrypts firm data on the device and lets you remote-wipe only the matter data, not the partner's photos. The non-compliant pattern is the partner forwarding documents to a personal Gmail and working from there. The second pattern is a supervisory failure under MR 5.1 and a likely 1.6(c) violation.
For most firms under fifty attorneys, cloud DMS (NetDocuments, Clio, MyCase, PracticePanther) is the more defensible choice because the vendor owns the server, the patching, and the underlying infrastructure. Your residual risk is account compromise and integration token theft, which a managed identity threat detection layer can address. On-prem iManage Work or older ProLaw deployments give you more control and more responsibility — Windows Server patching, SQL Server hardening, backup architecture, and EDR coverage all fall on the firm.
Monthly at a minimum. The events worth flagging are bulk downloads, after-hours access, deleted documents, user permission changes, and API key activity. Every system in this guide records these events; almost no small firm reviews them. Thirty minutes a month from a designated admin is the cheapest control on this list.
Yes. E-discovery platforms, court reporters, expert witnesses, contract attorneys, and outside IT providers who touch matter data all require a written agreement specifying data handling, breach notification, and return or destruction of data at matter close. Model Rule 5.3 makes the partner responsible for reasonable supervision of nonlawyer assistants and outside vendors. The agreement is how you demonstrate that supervision when something goes wrong.
Quarterly for matter-level access, and immediately on any departure or role change. We see firms where former associates still appear in matter teams six months after they left, and where lateral hires retained their prior firm's access for a transition period that never ended. A quarterly review takes a couple of hours and catches both.
Yes. API keys do not expire on their own. A key issued to an e-discovery vendor in 2021 that the firm stopped using in 2022 will still authenticate today unless someone revokes it. Quarterly rotation forces an inventory: which integrations are still in use, which are abandoned, and which were never properly documented. The rotation itself is straightforward; the inventory is the actual control.
Related reading
A field-tested hardening guide for Dentrix, Eaglesoft, and Open Dental — server isolation, account hygiene, backup strategy, audit logging, and the specific defaults that get practices breached.
Read articleA practitioner-style comparison of Huntress and SentinelOne for small businesses, focused on operations, staffing, response ownership, and what actually changes after deployment.
Read articleA practical 2026 buyer's guide to EDR, MDR, and XDR for small businesses, with honest recommendations, tradeoffs, and staffing realities.
Read article