Table of Contents
Key Takeaway
- 🔑 One login usually rules every machine in your office: the remote management tool your IT provider uses can reach, control and transfer files to any endpoint it services — which is exactly what the remote access audit below is designed to expose and control.
- 🧨 The threat is no longer hypothetical: CISA confirmed worm-style attacks abusing ScreenConnect’s file-transfer feature (CVE-2026-84869, CVSS 9.9), and RMM abuse remains one of the most-tracked attack vectors of 2026.
- 📋 The audit takes one afternoon: nine steps — inventory the tools, map the accounts, cut the dangerous permissions, force MFA, allow-list the networks, patch the clients, watch the sessions, govern the vendor, and calendar the re-audit.
- 🛡️ The 60-second stopgap exists: disabling file-transfer permissions in ScreenConnect roles blocked the worm’s delivery mechanism without any upgrade — proof that permission hygiene beats patching urgency.
The most powerful account in your company probably is not yours. It belongs to whoever can open a session on every laptop, server and register the business runs — the IT provider’s remote management tool. This month proved how quickly that power can be hijacked: attackers used rogue ScreenConnect clients to push malware to every machine that connected to a poisoned session, CISA put the flaw on its emergency list, and the patch that fixed it required touching every client installation, not just the server. A remote access audit is the discipline that turns this uncomfortable dependency into a managed, measured risk — and it takes an afternoon, not a project budget.
This remote access audit guide is the practical companion to our coverage of the ScreenConnect vulnerability spreading in worm-like attacks. There, the story; here, the checklist.
Step 1: Inventory Every Remote Access Tool
You cannot audit what you cannot list. Start by answering a question most offices get wrong: what software can reach into your machines? The usual suspects are ScreenConnect, AnyDesk, TeamViewer, Splashtop, RustDesk and whatever bundle your MSP installed. Check three places: the installed-programs list on a sample of machines, your MSP’s service documentation, and the “Remote Desktop” settings on Windows machines where RDP may be enabled by an old helpdesk ticket and never closed. Include the forgotten ones — the bookkeeper’s home laptop, the loaner unit in the stockroom, the previous provider’s tool that was never uninstalled. Each entry in the inventory gets four fields: tool name, version, who administers it, and whether unattended access is enabled.
The inventory usually produces the first finding of the audit: tools nobody remembered approving. Legacy installs from previous IT providers are a classic persistence path for attackers, because nobody watches software everyone forgot exists. Count the tool, not the license: unattended-access agents often run as services with generic names, so cross-check the inventory against running services on two or three machines rather than trusting the programs list alone. A five-minute check of running services against your inventory list typically surfaces at least one unlisted agent — and every unlisted agent is an unaudited door.
Step 2: Map Who Can Open a Session
Next, list every account that can start a remote session: technician accounts at the MSP, shared “tech” logins, former employees whose accounts were never disabled, and the vendor support accounts that came with the tool. For each, record the authentication method. Shared passwords count as zero authentication in an audit — they cannot be attributed to a person and they survive employment changes. The output of this step is a one-page access map: tool, account, human owner, authentication strength. If that page lists an account whose owner you cannot name, you have found your first remediation item.
This step also protects the relationship with your provider. Asking “which named technicians hold access to our environment” is a normal governance question, and providers with mature practices answer it from a dashboard in minutes.
Step 3: Cut the Permissions You Don’t Need
Remote tools ship with everything enabled because enabled features demo well. Audit each role in the administration panel against what the business actually needs. File transfer is the permission that mattered most in the ScreenConnect worm — attackers pushed four VBScript payloads through it — and ConnectWise’s interim guidance was to deselect TransferFiles (or TransferFilesInSession on legacy versions) in every role that does not genuinely need it. The change requires no upgrade and takes minutes per role. Apply the same logic to other high-risk permissions: unattended access, session recording exemptions, restarting machines, and executing commands. The audit standard is simple: every permission that is not demonstrably needed is a finding, not a default.
Step 4: Force MFA and Least Privilege on Technician Accounts
Multi-factor authentication on every technician and administrator account is the highest-value line in any remote access audit, because stolen technician credentials are how attackers skip the social-engineering step entirely. Enable MFA in the tool itself, not just on the email account that receives its alerts — and prefer app-based or hardware factors over SMS. Then apply least privilege: a junior technician does not need the ability to touch the domain controller, so role-scoped access by machine group beats one all-powerful “admin” role. Audit the vendor’s guidance here; tools like ScreenConnect expose role-based permissions precisely so that the domain administrator’s reach is not the default.
Step 5: Allow-List the Networks That Can Reach You
Self-hosted remote tools should accept connections only from known sources: the provider’s static IP ranges, your office egress, your VPN. Firewalls and router ACLs can enforce this in one rule set. For cloud-hosted tools, enable the vendor’s IP allow-listing feature where available and disable unused access channels — the web client nobody uses, the mobile app nobody installed, the legacy port left open from an old version. The worm-style attacks documented this month propagated through the tool’s own session channel; shrinking the surface that channel exposes is exactly the kind of control that blunts a cascading event.
Step 6: Patch the Clients and Pin the Version
The ScreenConnect flaw lived in clients before version 26.6.5 — meaning the server being current meant nothing for the hundreds of endpoints running old builds. The audit action: check the client version on every machine in your inventory, upgrade stragglers in priority order (servers and finance machines first), and then pin the version by disabling auto-update on end-user machines so your provider controls deployment deliberately. Ask the provider for their patch SLA in writing: how many days between vendor advisory and client rollout. Three days matches CISA’s emergency deadline for federal agencies; two weeks is a reasonable commercial standard; “when we get to it” is a finding.
Step 7: Log and Watch the Sessions
Most remote tools can log every session: who connected, from where, to which machine, when, and what was transferred. Turn the logging on, ship the logs somewhere the provider cannot edit, and review the last ninety days once as your audit baseline. You are looking for the shapes of abuse: sessions at 3 a.m. to machines that nobody tickets, file transfers to endpoints without a corresponding support request, new client installations nobody requested. The Huntress-documented worm incidents — reconstructed in public incident notes — all began with an anomalous client appearing on a user’s machine after a persuasive call — the kind of event a session log plus a user-reporting habit catches early.
Step 8: Govern the Vendor Relationship
The audit ends where the trust began: the contract. Add four clauses to every MSP or IT-provider agreement — notification of security incidents affecting their tooling within 24 hours, disclosure of which remote tools and versions they run in your environment, named-technician access lists reviewed quarterly, and your right to audit the configuration annually. Providers who resist these four sentences are telling you something. This is the same lesson the year’s supply chain attacks on IT workers keep teaching: your security now depends on other people’s patching discipline, so the discipline has to be contractual, not hopeful.
Step 9: Calendar the Re-Audit
A remote access audit decays: tools get added, technicians change, permissions creep back. Scheduling the re-audit is part of the audit itself. Calendar a quarterly one-hour re-audit — re-run the inventory, diff the access map, spot-check three client versions, and read one month of session logs. The first audit is an afternoon; the quarterly pass is an hour. The alternative is discovering your attack surface during an incident, which is how most organizations currently run this process.
For teams extending the same discipline to AI tooling, our 7-step lockdown guide for self-hosted AI applies the identical logic to local models: inventory, access control, network boundaries, patching, logging. The tools change; the audit does not. That invariance is what makes the remote access audit the highest-leverage afternoon a small team can spend on security.
The One-Page Remote Access Audit Checklist
- Inventory: every remote tool listed with version, admin and unattended-access status.
- Access map: named humans for every account; shared logins eliminated or flagged.
- Permissions: file transfer and command execution disabled in roles that don’t need them.
- MFA: enforced on every technician and administrator account, app or hardware factors preferred.
- Network: allow-lists enforced; unused clients, apps and ports disabled.
- Patching: clients on current versions; written vendor patch SLA in days.
- Logging: session logs on, shipped off-box, one month reviewed per quarter.
- Contract: incident notification, tool disclosure, named access list, audit right.
- Cadence: quarterly one-hour re-audit on the calendar with an owner.
Run the remote access audit checklist against your own environment and score it honestly: a line item you cannot verify in five minutes is a gap, not a pass. Offices that complete all nine lines are structurally harder to breach through the exact channel — the trusted remote session — that this year’s worst attacks used.
Frequently Asked Questions About the Remote Access Audit
What is a remote access audit?
A remote access audit is a structured review of every tool, account and permission that allows someone to reach your computers remotely. It inventories the software, maps the humans behind each account, trims excess permissions, verifies MFA and patching, and puts logging and vendor governance in place. The nine-step version above takes an afternoon the first time and an hour per quarter after that.
Why is remote access suddenly a top risk?
Because attackers follow the trust. CISA added the ScreenConnect file-transfer flaw (CVE-2026-84869) to its actively-exploited catalog after worm-style attacks pushed malware through remote sessions, and security researchers have tracked RMM abuse as a leading attack vector all year. The remote session is the one channel every office already trusts, which makes it the channel attackers rent rather than fight.
How do I know if my IT provider uses ScreenConnect?
Ask them directly — which remote-access tools they operate, which client versions are deployed on your machines, and whether file-transfer permissions are disabled in roles that do not need them. You can also check installed programs on a sample machine for ScreenConnect, AnyDesk, TeamViewer or similar. A provider who answers all three questions quickly is demonstrating the governance you are paying for.
What is the fastest mitigation if I find an old ScreenConnect client?
Two moves in order: disable the TransferFiles permission in every ScreenConnect role — it needs no upgrade and removes the worm’s delivery mechanism — then upgrade all clients to version 26.6.5 or later, prioritizing servers and finance machines. Patching the server alone leaves endpoints exposed because the vulnerability lives in the client.
How often should we repeat the audit?
Quarterly. Remote tooling changes constantly — new tools get installed, technicians join and leave, permissions creep. A one-hour quarterly re-audit that re-runs the inventory, diffs the access map, and spot-checks versions keeps the afternoon-long first audit from decaying into shelfware.
Can employees install remote tools themselves?
Only through a verified IT request channel — never because an unsolicited call, chat or email asked. Every worm-style incident documented this month began with social engineering that convinced a user to install a rogue remote client. The human rule — verify before you install — is the one control no patch replaces.
Financial Disclaimer: This article is for informational and educational purposes only and does not constitute professional cybersecurity advice. Organizations should consult qualified security professionals and vendor advisories before changing remote-access configurations.
