French supermarket shoppers may have been greeted with quite a site recently: a river of ice cream in their path.
On the night of October 11, 2026, attackers took remote control of the systems that run refrigerators and freezers at hundreds of supermarkets across France … and turned up the heat.
Millions of dollars worth of food spoiled. Some stores reported fires.
The list of affected chains reads like a French shopping trip: Intermarché, Carrefour, Monoprix, E.Leclerc, and Coopérative U. Coopérative U alone counted 80 affected stores, and its CEO called the attack “unprecedented, extremely serious, and unacceptable.”
Investigators haven’t said exactly how the attackers got in. But the compromised controllers are built to be managed remotely, so a maintenance company can check temperatures or clear an alarm without driving to every store. France’s national cybersecurity agency (CERT-FR) told owners to stop exposing those management interfaces to the internet.
I’d bet the thinking in a lot of those stores sounded something like this:
The maintenance company handles the freezers, so the freezers are handled.
The freezers aren’t computers, so IT doesn’t need to worry about them.
Except, they are.
Remote access always increases your risk level. It requires exposing devices to the Internet, where they can be discovered by the bad guys. But remote access is often necessary – and even if unnecessary – often provides some benefit to the business. The key is finding a way to enable the business to use remote access securely.
Why Remote Desktops Demand GRC Attention
“Remote desktop” covers any tool that lets someone see and control a computer they aren’t sitting in front of. At most companies, it shows up in a few forms:
- Native Windows remote access. Remote Desktop Protocol (RDP) is built into Windows and lets one machine control another. Remote Desktop Services (RDS) extends it so many users can work on the same server.
- Virtual Desktop Infrastructure (VDI). Employees log into a desktop that lives in a data center or the cloud, such as Azure Virtual Desktop or Amazon WorkSpaces, rather than on their own laptop.
- Third-party tools. TeamViewer, AnyDesk, Splashtop, ConnectWise ScreenConnect, and their cousins let a support person jump onto a machine anywhere with an internet connection. Managed Service Providers (MSPs) use Remote Monitoring and Management (RMM) platforms to do the same across hundreds of client machines at once.
- Equipment and building systems. Refrigeration, heating and cooling, and security systems often come with a web dashboard or vendor remote access, so technicians can manage them from anywhere. Those are the kinds of controllers the attackers reached in France.
Your business needs remote access. Hybrid work, information technology (IT) support, customer service, and fixing a server at 2 a.m. without driving to the office all depend on it. I wouldn’t tell a client to rip it out.
But every one of those tools is a door into your environment, and attackers know where the doors are. In its 2025 Active Adversary Report, Sophos found that attackers abused RDP in 84% of the incident response and managed detection cases it handled. Exploiting external remote services was the most common way in, at 56% of cases.
Arctic Wolf’s numbers are even less comforting. In its 2026 Threat & Predictions Report, 65% of intrusions (outside of business email compromise) started with abuse of remote access tools like RDP, VPNs, and RMM software.
You are not targeted. You get found.
So look at remote access through the lens of Governance, Risk, and Compliance (GRC). The technical controls cover how remote access works. GRC covers the decisions around it: who gets access and why, how much risk the business is willing to accept, and how you’ll prove all of it to an auditor or a customer.
Governance. You need a Remote Access Policy and an Acceptable Use Policy that everyone understands. Write them in plain language, so people read and follow them instead of leaving them on a shared drive.
Risk. Inventory every remote path into your environment, classify each by the sensitivity of what sits on the other end, and put a number on how likely and how damaging a compromise would be. A production database and the receptionist’s laptop shouldn’t get the same controls.
Compliance. Your auditors and customers are going to ask.
- SOC 2 (System and Organization Controls 2). Covers remote access under its CC6 logical and physical access controls.
- ISO (International Organization for Standardization) 27001:2022. Covers it under remote working (A.6.7), access control (A.5.15), privileged access rights (A.8.2), information access restriction (A.8.3), and secure authentication (A.8.5).
- HIPAA (Health Insurance Portability and Accountability Act) Security Rule. Requires access controls, audit controls, and person or entity authentication.
- PCI DSS (Payment Card Industry Data Security Standard) v4.0.1. Requires multi-factor authentication for all remote network access from outside your network (Requirement 8.4.3).
Core Use Cases: Tailored Management Strategies
The right controls depend on what’s at the other end of the connection. Here are the five situations we see most with clients.
A. Remote Servers That Must Be Managed
Scenario. Production, database, and infrastructure hosts: high-privilege, high-impact machines your IT or DevOps (development and operations) team legitimately needs to reach, often in a hurry.
Business goals. Fast, reliable admin access from anywhere, without a drive to the data center.
Key risks. RDP opened to the internet on the database server “just for the weekend,” three years ago. One shared admin login that six people use.
Recommended controls and failsafes.
- Never expose these servers directly to the internet. Route admins through a bastion host (a hardened “jump” server) or a Virtual Private Network (VPN) plus Zero Trust Network Access (ZTNA), which checks the person and device before granting access.
- Hand out admin rights by the hour. Privileged Access Management (PAM) tools grant admin access “just in time” and take it away when the task is done.
- Turn on Network Level Authentication (NLA) and multi-factor authentication (MFA) everywhere. NLA makes users prove who they are before a session starts. MFA has no exceptions for executives.
- Record and audit every session. When something goes wrong, you want a replay.
- Allowlist Internet Protocol (IP) addresses and geofence. No admins abroad? Block foreign logins.
For the GRC overlay, review least-privilege access quarterly, and alert on odd sessions: a 3 a.m. login, a new country, a six-hour session.
Quick-start checklist.
- This week, find every server that accepts RDP from the internet. (Your MSP can give you the list.)
- Move those servers behind a bastion host or VPN, with NLA and MFA on.
- Schedule the first quarterly admin access review, with a named owner.
B. Remote Desktops That Probably Shouldn’t Be Directly Managed
Scenario. Standard employee laptops, personal devices (BYOD, or Bring Your Own Device), and low-sensitivity endpoints, where RDP or an RMM agent adds risk with little upside.
Business goals. Employees get help when something breaks.
Key risks. RDP switched on for every laptop because it was on in the original image.
Or a free copy of AnyDesk that someone installed so a relative could help fix the printer.
Recommended controls and failsafes. Keep native RDP turned off. On Windows Pro and Enterprise laptops, Remote Desktop stays off until someone turns it on, so the real job is making sure nobody does. For the apps people need, give them access to those apps directly (through the app’s own login, or through ZTNA) instead of control of a whole desktop.
Then use your Mobile Device Management (MDM) tool, such as Microsoft Intune, to check that each laptop is managed and up to date. Pair it with conditional access (in Microsoft Entra ID, if you’re a Microsoft shop), which blocks any device that fails that check.
“But Rob, our IT person needs to get onto laptops to fix things!”
Sure. When temporary access is truly needed, make it time-boxed, require the employee’s consent, and monitor the session.
Quick-start checklist.
- Use your MDM tool to turn off native RDP on standard laptops and keep it off.
- Pick one approved remote support tool, and use the app-blocking settings in your endpoint security tool to block the rest.
- Run a software inventory to find remote tools that are already installed. (That free copy of AnyDesk is probably in there.)
C. Customer/Client Machines with Your Company Software Installed
Scenario. Software-as-a-service (SaaS) support, MSP work, or field devices, where you troubleshoot machines you don’t own.
Business goals. Fix customer problems fast and keep their trust.
Key risks. Always-on, unattended access to every customer install, through one support login the whole team shares.
Recommended controls and failsafes.
- Explicit, recorded consent for every session. The customer clicks yes each time, and you keep proof.
- Time-limited, revocable access. Sessions time out, and the customer can end them anytime.
- Role-based restrictions. Technicians start view-only and get control only when the ticket calls for it. File system browsing stays off by default.
- Data Loss Prevention (DLP) during sessions. Turn off file transfer and clipboard sharing in your remote tool unless a ticket needs them.
- Post-session audit logs. Keep them, and share them with the customer on request. (Your enterprise customers will ask.)
- A vendor risk assessment of the remote tool itself. Remote support vendors get breached too. In February 2024, AnyDesk disclosed that attackers had reached its production systems, and it revoked its security certificates and reset customer portal passwords. Check your vendor’s SOC 2 report, its MFA options, and how fast it ships security patches.
Bonus: keep support accounts separate from internal admin accounts, so a support login can never touch your own servers.
Quick-start checklist.
- Make per-session consent and view-only mode the defaults in your support tool, with file transfer and clipboard sharing off.
- Split support accounts from internal admin accounts.
- Patch your remote support tool as soon as security updates ship. (Attackers were actively exploiting a ConnectWise ScreenConnect flaw in February 2024.)
D. MSPs or Other Vendors Managing Your Machines
Yikes.
Scenario. Your MSP or another vendor has an RMM agent or other remote tool on your computers.
Business goals. Outsourced IT that works without becoming the easiest way in.
Key risks. Anyone who compromises your MSP (or its RMM tool) has a path to every computer you own.
On July 2, 2021, attackers affiliated with the REvil ransomware gang exploited a flaw in Kaseya VSA, an RMM product. They hit fewer than 60 MSPs directly, and through them, up to 1,500 downstream businesses. Many of those businesses had never touched Kaseya’s software. They had hired an MSP that did.
Recommended controls and failsafes. Keep your MSP. But as I wrote in Clean for the Cleaning Lady, hiring a vendor doesn’t hand them responsibility for your risk. A 2022 joint advisory from CISA, the NSA, the FBI, and their international partners makes the same point: understand the access your MSP has, and write the security you expect into the contract.
First, understand what they can do:
What can your tool do on our machines, and who on your team can do it?
Will you give us session logs if we ask?
Second, understand their security capabilities and protocols:
Does every one of your technicians use MFA to get into the RMM platform?
If another one of your clients gets compromised, what stops it from reaching us?
Quick-start checklist.
- Send your MSP those four questions before renewal, and put the answers in the contract.
- Review your MSP’s account activity at least once a quarter, so you know their access is used only for the work you hired them to do.
- Make sure someone on your team (a name, not a department) knows how to cut off the vendor’s access in under an hour.
E. Other Unique or Emerging Use Cases
A few more situations are worth planning for:
- Third-party vendors and contractors. Give them scoped, temporary, monitored access to “just enough” systems. Set it to expire automatically on the contract end date, and name the person who confirms it did.
- Hybrid and remote workforce on company devices. Use your MDM tool to set a baseline for every laptop, and use conditional access (see Section B above) to block any device that’s missing security updates, has disk encryption turned off, or isn’t enrolled in your MDM tool.
- Development, test, and QA (quality assurance) environments. Keep them isolated from production, make them easy to restore to a clean snapshot, and fill them with test data only.
- Incident response and forensics. Use read-only or forensic tools during an investigation, and keep a chain-of-custody log (who touched what, and when) so the evidence holds up.
- Auditor, board, and executive access. Read-only portals or escorted sessions work fine here. Nobody needs admin rights to read a report.
- Supply-chain and partner scenarios. Hold partners who connect to your environment to the same standard your largest customer holds you to. (We cover how to assess them in What is vendor risk management?)
Building a Solid GRC Framework for Remote Desktop
You need five things written down and a person who owns them.
Policy Essentials
Your Remote Access Policy should cover seven things:
- Scope. List the systems, people, and vendors the policy applies to.
- Roles and responsibilities. Name who approves access, who reviews it, and who owns the policy.
- Approved tools and methods. Keep a short list of the remote tools you allow, and say that everything else is blocked.
- Authentication requirements. Require MFA for all remote access, plus NLA for RDP.
- Monitoring. Spell out what gets logged and recorded, and who reviews it.
- Incident handling. Explain what happens when a session looks wrong, including who can shut it down.
- Enforcement. State what happens when someone uses an unapproved tool.
We recommend keeping the policy language as brief and reader-friendly as you can, so people actually read it. Accuracy comes first, though: the policy needs to cover everything that matters for your environment, even if that takes a few extra pages.
Risk Assessment Process
Inventory every remote access path, classify how sensitive each one is, score the risk, and apply controls in proportion.
A 30-person SaaS company might end up with one approved support tool and RDP off everywhere. A 750-person enterprise probably needs PAM, session recording, and a ZTNA rollout. Both are reasonable answers for their size.
Technical Control Layers
- Preventive controls keep the bad guys out: MFA, encryption, network segmentation, and patch management.
- Detective controls notice when something is off: session monitoring, alerts sent to your Security Information and Event Management (SIEM) system, and alerts for unusual logins.
- Responsive controls limit the damage: the ability to end a suspicious session automatically, and audit trails you can hand to an auditor as compliance evidence.
Administrative and Cultural Controls
Make training on approved tools mandatory. Run a tabletop exercise (a one-hour “what would we do if…” meeting) at least once a year, built around “our MSP just got breached.” And tie access reviews to Human Resources (HR) off-boarding, so access ends the day employment does.
Tool Selection Criteria
Before you buy, ask the vendor to show you:
- Compliance support. Will they sign a HIPAA Business Associate Agreement (BAA) or a data processing agreement under the General Data Protection Regulation (GDPR), if you need one? Do they have a current SOC 2 report?
- Security track record. Do they publish security advisories, and how fast did they patch the last serious flaw?
- Audit-ready logs. Can you export session logs and keep them for as long as your auditors require?
- Zero-trust fit. Does the tool check the user and the device on every connection, rather than trusting anyone already inside the network?
Then get an independent evaluation from someone with nothing to sell you. (We don’t resell remote access tools, so we have no favorite. Plenty of opinions, though.)
Implementation Roadmap & Measuring Success
90-Day Starter Plan
- Weeks 1 and 2: Inventory. Name one person to own the plan. Then find every remote access tool, open RDP port, RMM agent, and vendor account. You will find at least one you didn’t know about. If any server has RDP open to the internet, close it now rather than waiting for week 5.
- Weeks 3 and 4: Policy and risk assessment. Write the policy, and rank what you found from scariest to least scary.
- Weeks 5 through 8: Controls rollout. Turn on MFA everywhere, remove unapproved tools, and lock down vendor access.
- Weeks 9 through 12: Testing and training. Test the controls, train the help desk and users, and run the tabletop.
KPIs to Track
Track these four Key Performance Indicators (KPIs) to see whether the plan is working. Start measuring them before you change anything, so you have a baseline to compare against.
- Mean time to resolve support tickets. If this number climbs, security is slowing down the help desk.
- Blocked unauthorized access attempts. Watch the trend over time, and look into any sudden jump.
- Repeat audit findings on remote access. The target is zero.
- Employee satisfaction with remote support. Add a one-question survey after each remote support session.
Continuous Improvement
Review the policy every quarter, and include your remote access paths in an annual penetration test (an outside firm trying to break in, with your permission). Then tie what you find back to the risk scores from your assessment. When your leadership team or board asks whether the 90 days were worth it, you can show them how much risk went down, in numbers.
Saying Yes, Safely
Smart remote desktop management means saying “yes, safely,” not saying “no.” Your help desk still fixes the broken laptop, your maintenance company still clears the freezer alarm from its office, and your customers still get fast support.
It helps you sell, too. The next time a customer’s security questionnaire asks how you control remote access, you’ll have an answer, and the deal keeps moving. When the auditor asks for evidence, you’ll hand over the logs.
Start with week 1: name an owner, find out who can still get in, and take access back from anyone who no longer needs it.
If you’d like to know how dangerous your remote access setup is, a risk assessment is a good start.
As for that river of ice cream, someone has already mopped it up. The harder cleanup is figuring out who else can still log into the freezers.
Make sure you can answer that question for your own business.
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click!
