Are Remote Support and Remote Access Tools Your Riskiest Software?

For most organisations, yes: remote support, remote monitoring and management (RMM) and privileged remote access tools sit in the riskiest class of software you run, next to VPNs and firewalls. The code is not worse than anything else. The risk comes from the combination: they face the internet, hold administrator rights on many machines at once, store credentials, and look legitimate to your security tools, so one flaw or one stolen login reaches everything.

That combination is why CISA, the NSA, the FBI and partner agencies wrote a whole guide on securing remote access software, and why these products keep turning up in the Known Exploited Vulnerabilities catalog. In October 2026 a remote support product that had been exploited as a zero-day since late August was finally patched; our incident post on that flaw covers the details. This post answers the general question: should these tools get special treatment, and what does that look like in practice?

Key takeaways

• Remote access tools combine four risk factors that rarely meet in one product: internet exposure, broad privilege, reach across many endpoints and low detection, because the traffic and binaries are legitimate and signed.
• CISA's 2026 patching directive weighs exactly those factors (exposure, known exploitation, automatable exploitation and full system control). When a flaw in an internet facing remote access tool is exploited, it usually lands in the three day tier.
• You cannot protect tools you do not know about. Inventory every remote access product, including agents your MSP, OT vendors and software suppliers installed, and the copies that run as portable executables with no install at all.
• Keep administrative consoles off the open internet. Put them behind a VPN, a zero trust access broker or an isolated management network, as CISA's BOD 23-02 requires for federal management interfaces.
• Patching is not the end of the response. After an exploited flaw, hunt for compromise, rebuild from a known good state if needed, and rotate every credential the tool stored or injected.
• Treat the vendor as a privileged insider, with due diligence, contract terms and a written policy.

Why are remote support, RMM and privileged access tools such frequent targets?

What counts as a "remote access tool"

The joint CISA, NSA, FBI, MS-ISAC and Israel National Cyber Directorate guide, published on 6 June 2023, uses three overlapping terms:

• Remote access software: anything that lets a user connect to and operate a computer, server or network from somewhere else.
• Remote administration solutions: software that grants network and application access and administrative control of a device remotely.
• Remote monitoring and management (RMM): an agent installed on each endpoint that continuously reports health and status and lets an administrator run tasks such as patching, scripting and backup.

In practice that covers attended remote support, unattended access agents, RMM platforms and privileged remote access or jump host products that broker administrator sessions. Many products do several at once.

The four properties that make them high value

The guide is blunt about why attackers like these tools. Paraphrasing its main points:

1. They do not trip security tools. Remote access software is signed with valid code signing certificates and used every day for legitimate work, so antivirus and EDR products rarely flag it. The guide notes RMM install paths are often excluded from EDR inspection.
2. They replace custom malware. An attacker who controls a legitimate remote tool has everything a remote access trojan offers, without writing or deploying one. The guide calls this living off the land.
3. They can run without installation. Many products ship portable executables that run in the user's context without administrator rights, which can get around software installation controls.
4. They scale. One console can drive many machines, and if an attacker compromises an MSP, the guide warns, they can reach many of that MSP's customers.

Add two more that come from how the products are deployed:

• They are internet facing by design. A remote support server has to accept connections from technicians and endpoints wherever they are. That makes the server itself an edge device, and edge devices are where exploitation concentrates. A threat intelligence firm's count for the first half of 2026, reported by IT Brief, found 215 actively exploited vulnerabilities, up 34% year on year, with gateway and edge products such as SSL VPNs and firewalls frequently exploited and remote access appliances called out as exposed points worth inventorying.
• They hold secrets. Privileged remote access products often store or inject the credentials technicians use to log in to targets. After the October 2026 zero-day, CISA told owners to rotate every credential the appliance stored or injected, revoke all active sessions and review new MFA registrations on privileged accounts. That list tells you how much a compromised appliance can hold.

A short history of the pattern

This is not one bad month. The table lists incidents with primary sources; it is not a complete list and not a ranking of products.

The attack routes vary (vulnerable servers, phished users, stolen credentials, abused app permissions), but the blast radius is always larger than one machine.

So are they the riskiest software you run?

Risk is exposure times privilege times reach, discounted by how fast you would notice. Score your software on those axes and remote access tools land at or near the top for almost everyone. Here is how they compare with other categories.

Edge devices tie with remote access tools, and in some estates beat them. So the honest answer is "one of the two or three riskiest classes", not "always number one". Either way, this class needs different handling from the rest of your software.

How do you inventory every remote access tool in use, including ones a vendor installed?

The CISA guide lists auditing remote access software as a host based control, and the June 2025 SimpleHelp advisory shows why it is hard: some victims were running the RMM tool embedded in a third party product, not as software they had chosen. Treat inventory as a joint exercise across four sources.

1. What is installed or running on endpoints

Your EDR or software inventory tool is the first stop. Check it against these native views, because portable executables and renamed binaries may not appear as installed software. The CISA guide cites a case where a remote access binary was renamed to look like a Windows system process.

On Windows, list services and their binary paths, then look at the uninstall registry keys:

# Services with their executable paths; review anything that looks like remote support or RMM
Get-CimInstance Win32_Service |
  Select-Object Name, DisplayName, State, StartMode, PathName |
  Sort-Object DisplayName | Format-Table -AutoSize

# Installed software from both registry hives
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
                 HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Sort-Object DisplayName

# Services installed recently (System log event 7045)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 7045; StartTime = (Get-Date).AddDays(-30) } |
  Select-Object TimeCreated, Message

On macOS, remote tools usually register launch daemons or agents:

ls -la /Library/LaunchDaemons /Library/LaunchAgents ~/Library/LaunchAgents
sudo launchctl list | sort -k3

On Linux:

systemctl list-units --type=service --state=running
ss -tnp state established   # long lived outbound sessions and the process that owns them

If you run osquery across the fleet, a single query gives you a cross platform view of long lived outbound connections by process:

SELECT p.name, p.path, s.remote_address, s.remote_port
FROM process_open_sockets s
JOIN processes p USING (pid)
WHERE s.remote_port IN (443, 80) AND s.state = 'ESTABLISHED'
ORDER BY p.name;

Sort by process name and look for unfamiliar agents holding sessions open all day.

2. What the network sees

Remote tools phone home to vendor relays. Group a month of DNS and proxy logs by registered domain and compare against your approved vendors; this catches tools that never touched your software inventory.

3. What third parties installed

This is the category most teams miss. Ask, in writing:

• Your MSP: which RMM and remote support tools are on your systems, on which machines, under which accounts, and who at the MSP can use them.
• OT and building systems vendors: what remote access they use for chillers, PLCs, badge systems and lab equipment. The CISA guide lists remote access tools aimed specifically at OT networks.
• Software suppliers: whether their product embeds or bundles a remote support component. CISA's SimpleHelp advisory tells vendors that embed the tool to notify downstream customers, which only works if customers know to ask.

What the register should hold

For each tool record the product and version, where the server runs (self hosted, vendor hosted or MSP hosted), whether its console is reachable from the internet, which accounts can use it, whether those accounts require MFA, what credentials it stores, the vendor's advisory feed, your patch owner and the date it was last reviewed. An SBOM from the vendor is useful here: CISA's guide recommends SBOMs for keeping an inventory of components in a software product, and the SimpleHelp advisory asks software vendors to consider including one so customers can remediate faster. Our post on using SBOMs to find affected products fast shows how that inventory pays off on the day an advisory lands.

Should these tools ever be internet facing, and what are the alternatives?

Separate the two surfaces a remote access product exposes:

• The administrative console, where technicians log in, configure policies and manage credentials.
• The session or relay endpoint, which endpoints and customers connect to.

The console should almost never be reachable from the open internet. CISA's BOD 23-02, issued on 13 June 2023, requires federal agencies to take networked management interfaces off the internet within 14 days of finding them, either by making them reachable only from an internal network (CISA recommends an isolated management network) or by putting them behind a zero trust policy enforcement point separate from the interface. The directive names remote management protocols such as SSH, RDP and VNC. It binds only federal civilian agencies; the logic applies to everyone. CISA's October 2026 alert says the same for remote support appliances: limit external access to necessary services and restrict administrative interfaces to trusted networks.

The relay endpoint is harder, because remote support exists to reach machines outside your network. The options:

Two cautions. Vendor hosted is not risk free: in October 2026 the vendor of the exploited remote support product reported that one of two compromised instances was vendor hosted, as cited in our incident post (other reporting described a single self hosted appliance), and SaaS customers were still told to review credentials and configuration. And a VPN in front of everything only helps if the VPN is patched as aggressively as the tool it protects.

What is a sensible patch SLA for remote access software?

What federal guidance now says

For five years the reference point was BOD 22-01: fix anything in the KEV catalog within two weeks, or six months for CVEs assigned before 2021. On 10 June 2026 CISA revoked it and replaced it with BOD 26-04, Prioritizing Security Updates Based on Risk. The new directive scores each vulnerability on four factors: asset exposure, KEV status, whether exploitation can be automated, and the technical impact after exploitation. CISA's companion post, Patch Smarter, Not Harder, says "only the highest risk vulnerabilities must be patched within three days", while lower risk ones can wait, some until the next system upgrade. It also says the framework mostly prioritises vulnerabilities at the network's edge.

Now apply those four factors to an exploited flaw in an internet facing remote support server: exposed, on KEV, often automatable, and leading to full control of a box that controls other boxes. That is the top tier. CISA also gave a federal due date for the October 2026 remote support flaw only three days after adding it to KEV, as our incident post records.

BOD 26-04 adds one more expectation that matters here: agencies must check whether a system was compromised before the patch went on, because CISA notes that patching generally does not evict an attacker who is already inside.

A suggested SLA table

These are starting points for a private sector policy, not legal requirements. Adjust them to your risk appetite and write the exceptions down.

Why "stay on a supported line" belongs in the SLA

Two vendor advisories show how version currency shapes patch speed. When ScreenConnect 23.9.8 shipped in February 2024, ConnectWise's bulletin said partners off maintenance could get only an interim patched build, 22.4.20001, at no cost; moving to 23.9.8 or later required active maintenance. In October 2026, CISA noted that the remote support patch applied to supported versions 24.3.1 and later, and older installations had to upgrade first. Teams on current lines patched in one step; others had to upgrade first, mid exploitation. Put "on a supported release with active maintenance" in the policy, not just "patched".

The gap between patch available and patch applied

The SimpleHelp case is the clearest example of what the gap costs. CISA added CVE-2024-57727 to KEV on 13 February 2025. Its June 2025 advisory says ransomware actors had been targeting unpatched SimpleHelp versions since January 2025 and reached the customers of a utility billing software provider through instances that were still unpatched. The fix existed for months; the bottleneck was knowing where the software ran.

Step by step: a 72 hour runbook for an exploited remote access flaw

This runbook follows the order CISA used in its October 2026 alert and its SimpleHelp advisory.

Hour 0 to 4: find and contain

1. Look up every instance in your register. Confirm product, version and where it runs.
2. Check the running version, not the one in the asset record, using the method the advisory gives. CISA's SimpleHelp advisory, for example, points to the server configuration file and the server's version page.
3. If the console is reachable from the internet, close it now. For a cloud hosted server that is one command:

# AWS example: remove a world-open HTTPS rule from the appliance's security group
aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# then allow only your VPN or broker egress range
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 443 --cidr 203.0.113.0/24

4. If you cannot restrict access without breaking support for customers, decide with the service owner whether to stop the service until patched. CISA advised isolating or stopping vulnerable SimpleHelp servers.
5. Start forwarding the appliance's syslog and session events to your SIEM if they are not already there.

Hour 4 to 24: patch and preserve

6. If you suspect compromise, capture a snapshot or forensic image before patching, as CISA recommends. Patching can overwrite evidence.
7. Apply the vendor patch or upgrade. For off maintenance versions, check whether the vendor offers an interim build.

Hour 24 to 72: hunt, rebuild, rotate

8. Hunt using the advisory's guidance. CISA's 2026 alert lists unrecognised privileged or administrative sessions, unrecognised script files, gaps in logs or log forwarding, and unauthorised changes to accounts, permissions or session policies.
9. On endpoints, reuse the inventory queries to find services installed and relay sessions opened during the exposure window.
10. If you find signs of compromise, rebuild the appliance from a known good state rather than cleaning it in place.
11. Rotate every credential the tool stored or injected, revoke active sessions, and review MFA registrations on privileged accounts.
12. Record what you found, what you changed and when. Auditors, insurers and customers will ask.

If the tool came through an MSP, run these steps with them and get findings in writing. Our compromised dependency incident playbook covers the parallel steps for software you build.

What should you ask a remote access vendor in due diligence?

The CISA guide asks developers of remote access products to offer lower privilege modes such as read only monitoring, watch for abuse of free trials, keep audit logs hard to delete, threat model and fuzz their interfaces, and map practices to NIST's Secure Software Development Framework. That makes a good question list.

Store the answers with the vendor record and set a review date.

How do you detect misuse of a legitimate remote tool?

The CISA guide asks defenders to baseline normal activity first and correlate remote tool activity with other suspicious behaviour to cut false positives. Then layer these controls.

Allowlist approved tools and block the rest

The CISA guide and advisory AA23-025A both recommend application control that allows only approved remote tools and blocks both installation and execution of portable versions of unapproved ones. MITRE ATT&CK lists the same idea as execution prevention under T1219, Remote Access Tools. Block the network side too: CISA recommends blocking inbound and outbound connections on common remote tool ports and protocols at the perimeter, allowing only legitimate use.

Watch for the behaviour chain, not the brand

MITRE's tool agnostic detection strategy for T1219 looks for a sequence: a remote control agent starts, it persists through a service, autorun, systemd unit or launch daemon, it holds a long lived outbound connection to external infrastructure, and it spawns interactive child processes such as shells or file managers. Any one step is normal; all four where no approved tool should run is a strong signal.

Useful starting points on Windows:

• System event 7045 (a service was installed) for remote tool services appearing outside change windows.
• Process creation events where PowerShell or another script host installs a remote tool silently. The CISA guide notes attackers often deploy RMM agents this way.
• Binaries whose name does not match their signer or file description, which catches renamed tools.

Rate limit mass actions

One of the CISA guide's more specific recommendations: put safeguards on mass scripting. If an account pushes commands to 10 or more devices within an hour, require MFA again to confirm the source is legitimate. Ransomware deployed through RMM looks exactly like a mass script run.

Protect the logs from the tool

The CISA guide tells MSP and SaaS customers to keep direct access to log servers, and the ability to delete or alter logs, out of reach of RMM tools. If the tool that can run anything everywhere can also wipe the logs, an attacker who controls it can too. Stream logs off box in real time.

Review sessions, not just alerts

Weekly, someone should read each privileged tool's session list, looking for unusual hours, unfamiliar targets, new technician accounts and new MFA devices. It is dull work that finds misuse no alert catches.

What contract terms matter for a vendor whose tool has privileged access to you?

The Five Eyes advisory AA22-131A, published in May 2022, and the 2023 CISA guide both give contract guidance for customers of MSPs and remote access providers. Pulling them together with the lessons from later incidents:

• Incident notification. Define how and when the provider tells you about confirmed or suspected incidents in its own infrastructure, not only in yours. Name a time limit.
• Logging visibility. The provider must log its activity in your environment, including its presence, actions and connections, and give you access to those logs.
• MFA and least privilege. MFA on every provider account that touches your systems. Provider accounts limited to the systems they manage, kept out of your domain administrator groups and disabled when not in use.
• No credential reuse. The provider must not reuse administrator credentials across customers.
• Patch commitments. For hosted services, a patch window for critical and exploited flaws and a written confirmation when done. For self hosted products, timely advisories and fixes for every supported line. If you need help defining "critical" in the clause, see how to define a critical vulnerability in a patch SLA clause.
• SBOM and advisory access. A right to receive an SBOM per release and to subscribe to security advisories.
• Responsibility split. Who does hardening, detection, incident response and recovery, and what is excluded. CISA asks providers to explain clearly what customers are and are not buying.
• Exit. On termination, the provider removes its agents, disables its accounts and returns or destroys any stored credentials, and confirms in writing.

Do not forget app permissions. The October 2026 ConnectWise incident ran through application identities customers had granted in Microsoft 365, not through a remote desktop agent. Our post on why every connected app is a durable credential explains why those grants deserve the same contract and review treatment.

What does a remote access tool policy look like for a 200 person company?

A useful policy fits on two pages and names real tools and real owners. Here is a template you can adapt; it is written as YAML so it can live in a repository next to your other configuration and be reviewed like code.

policy: remote-access-tools
version: 1.0
owner: Head of IT
review: quarterly

approved_tools:
  - purpose: attended end user support
    product: "<one approved remote support product>"
    hosting: vendor-hosted
    technician_auth: [sso, enforced-mfa]
    user_consent_prompt: required
    session_recording: on
  - purpose: privileged admin access to servers and network devices
    product: "<one approved privileged access or ZTNA product>"
    hosting: self-hosted
    console_exposure: internal-or-broker-only
    access: just-in-time, max 8 hours, ticket reference required
    credential_injection: on (technicians never see passwords)
  - purpose: endpoint management
    product: "<one approved RMM or device management product>"
    mass_action_guard: re-prompt MFA above 10 devices per hour

unapproved_tools:
  enforcement: application control blocks install and portable execution
  network: block known relay domains for unapproved products at DNS and proxy
  exceptions: written approval from Head of IT and Security, 30 days max

third_parties:
  - MSPs and vendors connect only through the approved privileged access product
  - no vendor-installed agents without a register entry and a named internal owner
  - vendor accounts disabled when not in use; reviewed monthly

patching:
  exploited_internet_facing: mitigate 24h, patch 72h, compromise check required
  critical_internet_facing: 7 days
  agents: 7 days, verify fleet coverage
  supported_release_lines_only: true

logging:
  stream_to_siem: realtime
  console_admins_cannot_delete_logs: true
  weekly_session_review: IT security lead

offboarding:
  revoke_technician_access: same day
  remove_vendor_agents_at_contract_end: true

At 200 people the main point is consolidation: one tool per purpose, a named owner, everything else blocked. Each extra tool is another exposed server, credential store and advisory feed to watch.

Where Safeguard fits, and where it does not

Be clear about the limits first. Safeguard does not patch a vendor's remote support appliance, does not monitor remote sessions and is not an EDR, so it will not detect a technician account being misused. The fix for a flaw in a commercial remote access product comes from that vendor.

Where Safeguard helps is the supplier and software side of the problem:

• Third party risk. Safeguard's Third-Party Risk Manager lets you onboard the vendors that hold privileged access, request SBOMs, projects or products from them, keep their questionnaire answers and documents with the vendor record, and score and monitor supplier risk over time. That is where the due diligence table above should live.
• SBOM analysis. When a vendor sends an SBOM for its server or agents, Safeguard analyses it against vulnerability databases including the CISA KEV catalog, so a new advisory against a component inside the product shows up against that vendor.
• Your own software. If you build internal tooling around remote access, such as scripts, portals or container images that wrap a vendor agent, Safeguard scans those repositories and images, ranks findings using exploit signals and reachability, and can open fix pull requests for the open source dependencies.
• Free lookups. Gold Open Source shows affected and fixed versions, CVSS, EPSS and KEV status for a CVE, which is a quick way to check the public facts about a component a vendor names.

Common mistakes

• Treating the remote tool as IT plumbing rather than an edge device. It needs the same exposure review, patch priority and monitoring as your VPN.
• Inventorying only what IT installed. MSP agents, OT vendor tools, embedded components in third party products and portable executables are where the surprises are.
• Leaving the admin console on the internet "because the relay has to be". The two can usually be separated.
• Patching and moving on. After an exploited flaw, a patched appliance can still host an attacker. Hunt first, rebuild if in doubt, then rotate credentials.
• Forgetting the credentials the tool holds. Rotating the appliance admin password is not enough when the tool injects domain and server credentials into sessions.
• Letting maintenance lapse on an internet facing tool. The patch you need may sit behind a renewal.

FAQ

Is it safe to use remote desktop software for IT support?

Yes, if you treat it as privileged, internet facing software: one approved product, SSO and enforced MFA for technicians, user consent for attended sessions, session recording, an admin console kept off the internet and your fastest patch SLA. Sprawl and slow patching cause most of the risk.

What is the difference between RMM and remote support software?

Remote support software lets a technician view and control a machine, usually for a session at a time. RMM installs a permanent agent on each endpoint to monitor health and run tasks such as patching and scripts across a fleet. CISA's guide treats both as remote access software. RMM carries more standing privilege because its agent is always present.

Is a vendor hosted (SaaS) remote support tool safer than self hosted?

Usually for patching, because the vendor fixes every hosted instance centrally; in October 2026 SaaS customers were patched before the advisory went out. Hosted instances can still be compromised, and you get less control over logs. Either way, review credentials and sessions after any advisory.

How fast should we patch a remote access tool?

For an exploited flaw in an internet facing server or console, mitigate within a day and patch within 72 hours, which mirrors the three day top tier in CISA's BOD 26-04. If you cannot patch that fast, take the console off the internet or stop the service until you can. Non exploited critical flaws in internet facing tools deserve a 7 day target.

Should we block every unapproved remote access tool?

Yes. CISA recommends application control that allowlists approved remote tools and blocks both installation and portable execution of the rest, plus blocking common remote tool ports and protocols at the perimeter.

How do attackers use legitimate remote access tools?

Three main ways: exploiting a vulnerable remote access server, logging in with stolen technician credentials, or tricking a user into running a portable client that connects to the attacker's own account, as in CISA's AA23-025A advisory. Security products usually treat what follows as normal admin activity.

Does MFA protect us against remote support zero-days?

Not against pre authentication flaws. The October 2026 remote support vulnerability needed no credentials or user action, according to the Canadian Centre for Cyber Security as cited in our incident post. MFA still stops stolen password attacks, but only patching and reducing exposure address unauthenticated bugs.

Do we need an SBOM from our remote access vendor?

It helps. CISA's guide recommends SBOMs for component inventory, and its SimpleHelp advisory asked software vendors to consider SBOMs to speed remediation. An SBOM tells you which open source components ship inside the server and agents, so you can see when a component advisory affects a tool you depend on.

Fix it without waiting for upstream

Remote access products are vendor software, so the fix for the product itself has to come from the vendor. The internal tooling, scripts and container images you build around them, and the open source components inside the software you ship, are where the steps below apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos is a remote support product. They show principles this post argues for: actions on your machines only with explicit approval, and an assistant limited to the tools you choose.

This first demo is a real Android session. Work is sent from the phone to a computer running the Safeguard CLI, and each command waits for approval on the phone with Allow once, Allow for turn or Deny. The approver sees the exact command before it runs.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. Asked to fix a lodash CVE, the CLI reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow fixes vulnerable dependencies in scripts and tooling you build around your remote access stack.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Least privilege for an AI assistant follows the same rule as least privilege for a remote support technician: grant only the actions the job needs.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• CISA: Guide to Securing Remote Access Software (page)
• CISA, NSA, FBI, MS-ISAC and INCD: Guide to Securing Remote Access Software (PDF)
• CISA AA23-025A: Protecting Against Malicious Use of Remote Monitoring and Management Software
• CISA AA25-163A: Ransomware Actors Exploit Unpatched SimpleHelp Remote Monitoring and Management
• CISA AA22-131A: Protecting Against Cyber Threats to Managed Service Providers and their Customers
• CISA: Kaseya ransomware attack guidance for affected MSPs and their customers
• CISA: Urges patching of critical vulnerability in BeyondTrust Remote Support (16 October 2026)
• CISA: Update on the Treasury breach (6 January 2025)
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces
• CISA BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities (revoked)
• CISA: New directive on prioritizing mitigation of cyber vulnerabilities (BOD 26-04)
• CISA: Patch Smarter, Not Harder
• ConnectWise: ScreenConnect 23.9.8 security bulletin
• MITRE ATT&CK: T1219 Remote Access Tools
• IT Brief: Supply chain attacks rise as 215 flaws are exploited
• The Hacker News: Weekly recap, October 2026
• TechCrunch: The internet is having a very bad cybersecurity day

Last reviewed: 23 October 2026. Federal directives and vendor advisories change; check the linked sources for current guidance.