Securing Lacerte, Drake, CCH Axcess, UltraTax, and ATX: A Practical Hardening Guide for Small Tax Firms

Tax software runs the practice. It holds every client's SSN, EIN, bank routing data, full corporate financials, dependents, and prior-year returns.

It is also one of the least-hardened categories of software in any small business vertical, because the people who install it are trained on workflow and deadlines — not on Windows server hardening, SQL Server defaults, or FTC Safeguards-grade audit logging.

This is a hands-on guide for five tax platforms: Lacerte, Drake Tax, CCH Axcess, UltraTax CS, and ATX.

The vendors document what the software does. They rarely document how to deploy it in a way the IRS, the FTC, or a cyber insurer would call reasonable. The defaults are not secure, and the defaults are what most firms are running.

Why a hardening guide is necessary

Every tax software vendor publishes an installation guide. None publishes a security baseline that maps to the FTC Safeguards Rule at 16 CFR Part 314, IRS Publication 4557, or the WISP every paid preparer with a PTIN has been required to maintain since 2024.

The installation guide tells you how to get returns flowing. It does not tell you to disable shared logins, rotate sa, audit portal integration tokens, deprovision seasonal contractors on April 16, or test your restores.

That gap is what threat actors walk through. A shared Reception account at the front desk. A TaxPrep1 login every contractor reuses. MFA on the SSO but a portal integration that bypasses it. An EFIN PIN in a Word document called "logins.docx." None of it requires a zero-day.

Account hygiene — the single biggest problem

The most common finding on a CPA firm assessment is a shared Reception or FrontDesk account with broad tax software access. The second most common is a TaxPrep1 or Seasonal1 login the firm reuses across every seasonal contractor.

Both break the same things. The Safeguards Rule at 314.4(c)(1) requires access controls and least privilege; a shared login satisfies neither.

The audit log becomes useless because every action is attributed to a generic identity. Offboarding becomes impossible because rotating the password means retraining everyone, so most firms skip it.

Every platform supports per-user accounts and role-based access. Lacerte and ProConnect have per-preparer accounts with role-based permissions. Drake Tax has per-user logins with security groups.

CCH Axcess has a granular permission model that can scope to specific clients and return types. UltraTax CS supports per-user accounts through the Admin Console and ties to Onvio identities. ATX supports per-user logins with role-based templates.

One account per preparer, per staff member, per seasonal contractor. No shared logins. Access scoped to the clients each person works on. Do this before anything else — most controls below depend on it.

MFA on the tax software, not just on the SSO that fronts it

Every platform supports MFA. The mistake firms make is assuming MFA on the Microsoft 365 or Google Workspace SSO is sufficient because preparers log into the firm tenant first. It is not.

• Lacerte (Intuit) — MFA via the Intuit account. For network installs, also configure Windows authentication on preparer workstations.
• ProConnect Tax and ProSeries (Intuit) — cloud platforms; MFA effectively mandatory, no opt-out.
• Drake Tax — MFA via the Drake account. Drake Portals is configured separately and also needs MFA enforced.
• CCH Axcess (Wolters Kluwer) — SSO with MFA through the firm's identity provider (Entra ID, Okta). Verify MFA is enforced on the SAML side and that the CCH user table reconciles against the IdP.
• UltraTax CS (Thomson Reuters) — Onvio integration supports MFA. Verify each preparer is enrolled, not just provisioned.
• ATX (Wolters Kluwer) — MFA available but historically opt-in. Turn it on for every user; disable per-user opt-out.

The failure mode that catches every firm: the SSO has MFA, but a vendor support path, a service account, or an integration token bypasses it. Tax ecosystems are full of these — portal integrations, e-signature, bank product partners, document management connectors. Inventory them.

Cloud versus on-prem

Cloud-hosted tax software (ProConnect, Lacerte SaaS, CCH Axcess, UltraTax SaaS, Drake Cloud) shifts the server-hardening burden to the vendor. On-prem installs leave it with the firm.

In cloud, 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.

In on-prem, the dominant threat is server compromise. The firm owns the Windows Server build, SQL Server hardening, backup, patching, and EDR.

The machine ransomware looks for is an on-prem tax server untouched since installation, running SQL Server with a default sa password reachable from the LAN.

The on-prem tax server itself

If you run Lacerte network, Drake server, CCH Axcess on-prem, or ATX network, the tax server is a Windows machine holding the firm's most sensitive data.

• Supported Windows Server release — 2019 or 2022 — ideally Server Core. A Windows 11 Pro desktop under the front desk acting as the firm "server" is not defensible.
• No interactive RDP from outside the LAN. Put remote admin behind an RDP gateway with MFA or a zero-trust broker.
• EDR on the server. Huntress Managed EDR belongs on every tax server, not just workstations. The most common gap is workstations protected, server unprotected — exactly backwards.
• SQL Server hardening. Lacerte, CCH Axcess, and ATX use Microsoft SQL Server. On older installs the sa password is weak or vendor-default. Rotate it, remove sa from interactive use, create named SQL accounts for maintenance, audit sysadmin membership monthly.
• NTFS permissions on the return store — service account at least-privilege rights to only the directories it needs.
• SMBv1 disabled, SMB signing required, and no daily-driver browsing or email from the tax server. Ever.

Remote access — the wrong way and the right way

Remote access is where small CPA firms get breached. The wrong patterns repeat:

• Unattended TeamViewer or AnyDesk on a partner's home laptop with a static password and no MFA
• Port-forwarded RDP from the firm's public IP to a preparer's workstation on TCP 3389 "during tax season"
• A shared MSP RMM agent on the tax server with no per-technician audit trail

The right patterns are not exotic. Entra ID conditional access on every firm device — including the partner's home laptop — requiring compliance and MFA before any session touches the tax software. MFA on every remote session.

Time-boxed, just-in-time access for the vendor's support team, granted when a case is open and revoked when it closes, with a written breach notification clause. No port-forwarded RDP from the internet.

If you only do one thing this quarter, remove the unattended TeamViewer and the port-forwarded RDP.

Audit logging — every tax platform has it; almost no one reviews it

Every platform in this guide records who did what to which return at what time. Almost no small firm has ever opened the log.

• Lacerte: Tools then Audit Log.
• Drake Tax: Reports then Activity Log.
• CCH Axcess: Admin then User Activity.
• UltraTax CS: Admin Console activity log.
• ATX: Admin then User Activity.

Monthly review is the off-season minimum. During tax season — January through April 15, plus extensions through October 15 — the cadence should be weekly.

Flag after-hours access, bulk return exports, deleted returns, preparer or status changes, and activity on returns assigned to a preparer who is out or has left. Thirty to sixty minutes a week from a designated admin. Cheapest control on the list; most consistently skipped.

Seasonal contractor accounts — the highest-risk identity surface

Seasonal contractors are unique to tax practice and unique in their risk profile. The same contractor may work for two or three competing firms across a filing season. They are onboarded fast, given access to sensitive client data, and offboarded faster — or not offboarded at all.

• Provision on a fixed start date after the background check and signed confidentiality agreement clear.
• Unique per-contractor account, never shared. A Seasonal1 login every contractor reuses is a Safeguards Rule violation.
• Documented training before first login covering anti-phishing, IRS-impersonation themes, password manager use, and the firm's incident reporting path.
• Deprovision on a fixed end date — no later than April 16 unless the contractor is documented as continuing on extensions. Tax software and Microsoft 365 or Google Workspace accounts come down the same day.

Quarterly access reviews catch what the seasonal cycle misses, including former contractors who retained access months after their last return.

The EFIN, PTIN, and PIN problem

The firm-level EFIN, each preparer's PTIN, and the IRS-issued EFIN PIN authenticate to the IRS e-file system, not to the tax platform. Treat them as privileged identities.

• Named owner for the EFIN and the PIN — typically the partner who signed the IRS application.
• Rotate the EFIN PIN when staff with knowledge of it depart.
• Never store the PIN unencrypted in a shared drive, in email, or a Word document called "logins.docx." Use the firm's password manager.
• Annual EFIN re-verification with the IRS under Pub 3112. The IRS does revoke EFINs for non-compliance.

The EFIN authorizes a firm to file. Treat it like the firm's most sensitive identity, because it is.

Client portal and e-signature integrations

Every modern tax platform lives inside an ecosystem of integrations:

• SmartVault
• SafeSend Returns
• DocuSign
• Adobe Sign
• Bank product partners
• Document management connectors like Doc.It or GoFileRoom
• The Outlook plugin

Each authenticates with a token that bypasses front-door MFA.

1. Inventory every integration. List every authorized application, API key, and service account in the tax software admin console and the SSO identity provider.

   Cross-reference against vendors in actual use. Typical first-pass result: two to four active tokens for integrations the firm stopped using over a year ago.

2. Rotate API keys quarterly and disable unused integrations. Rotation forces the inventory to happen.

Verify each integration's breach notification clause in its TOS or signed MSA. If a portal vendor breaches and the firm finds out from a news article, the FTC will not accept "we did not know" as a Safeguards Rule defense.

Backup strategy — 3-2-1-1-0 for tax firms

The traditional 3-2-1 rule does not survive a ransomware-active threat model. The version we recommend for CPA firms is 3-2-1-1-0: three copies, two media types, one offsite, one immutable, zero errors verified.

For cloud tax software, the firm still needs its own backup. The vendor SLA is not a backup, and the vendor's retention policy is not aligned with IRS or state CPA record retention obligations.

Use a third-party SaaS backup for Microsoft 365 and any cloud tax data the vendor exposes for export, and verify recovery quarterly.

For on-prem tax servers, 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 off-season and weekly during the season — restore to a non-production machine, open the database, confirm a recent return opens correctly. Most firms have not tested a restore in over a year.

BYOD and work-from-home preparers

Preparers want to work from home, especially during the season's worst weeks. The friction between that expectation and the Safeguards Rule is real and unavoidable.

The compliant pattern is a managed configuration on the personal device — Intune App Protection Policies (MAM, not full MDM) on the firm's access path to the tax software. Encrypted container for firm data. Remote wipe scoped to firm data only, not the preparer's personal files.

The non-compliant pattern is the preparer emailing returns to a personal Gmail, or saving client data to a personal OneDrive or Dropbox.

Make it the first security awareness focus area for a tax firm: quarterly training, with documented completion, that calls out the patterns staff actually try.

Where Obsidian Ridge fits

A typical hardening sequence for a CPA firm is straightforward:

• Deploy Huntress Managed EDR on the tax server (if on-prem) and every workstation, including partner laptops and preparer home machines under managed configuration.
• Deploy Huntress Managed ITDR on the firm's Microsoft 365 or Google Workspace tenant.
• Where log retention is required, add Ridge Log, our log collection and retention add-on, for the tax platform, the identity provider, and the endpoint fleet.
• Enable per-user accounts in Lacerte, Drake, CCH Axcess, UltraTax, or ATX, and retire shared reception and seasonal logins.
• Enforce MFA on the tax software itself, not just at the SSO, and audit every integration token.
• Configure a monthly off-season and weekly in-season audit-log review, plus a quarterly access review.
• Rebuild the backup to 3-2-1-1-0 with an immutable copy and a tested restore.
• Provide the written information security plan, mapped to the Safeguards Rule and IRS WISP requirements.

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 IRS Office of Professional Responsibility.

If you run a CPA firm and are not sure where you stand against this list, talk with us or review the accounting cybersecurity program.

We will walk through your tax software configuration, audit logs, integration tokens, seasonal contractor process, and backup strategy, and tell you what to fix first.