Securing remote access: a balanced view of the benefits and the risks

Why the guidance is balanced rather than prohibitive

Joint guidance from CISA and partner agencies opens by acknowledging remote access software as a proactive and flexible way for organisations to oversee networks, computers and devices. That framing is deliberate: banning the capability is neither realistic nor desirable, because the operational benefits — support, maintenance, business continuity — are substantial.

The risk is that the same properties which make remote access useful to administrators make it useful to attackers. It is expected on the network, it grants interactive control, it often runs with high privilege, and in many estates nobody has an accurate list of which tools are installed where.

How remote access gets abused

The recurring patterns in incident reporting are consistent. Attackers install legitimate remote access tools as a persistence mechanism, because such tools are less likely to be blocked than bespoke malware. They exploit weak or reused operator credentials. They target help-desk processes with social engineering to obtain a session on a real user's machine. And they take advantage of estates where remote access exists but is not logged, so the intrusion leaves no trail.

Notably, most of these are failures of governance rather than of the software. The controls that address them are organisational as much as technical.

• Unapproved remote tools installed by users, suppliers or attackers
• Credential compromise on operator accounts without multi-factor authentication
• Social engineering of the help desk to obtain a consented session
• Standing unattended access to devices that never needed it
• Sessions that are never logged, reviewed or attributable to a named person

The control set that matters

Guidance converges on a compact set of controls. Know what is installed; allow only what you approved. Bind every operator to a named identity with strong, phishing-resistant authentication. Grant the least access that does the job, and prefer consent-based sessions where a person is present. Log every connection centrally, where an attacker on the endpoint cannot edit the record. Then build a detection rule for remote sessions that fall outside the expected pattern.

Encryption in transit is table stakes rather than a differentiator. The harder questions are about identity, authorisation and evidence.

• Inventory and allow-list approved remote access software; alert on anything else
• Named accounts with multi-factor authentication — never shared operator logins
• Least privilege and role separation between viewing, controlling and administering
• Consent and visible indicators for attended sessions
• Central, tamper-resistant session logging with defined retention
• Detection rules for out-of-hours, unusual-source or unexpected-tool sessions
• Defined offboarding that removes operator and third-party access promptly

Third parties are the hard part

Suppliers, contractors and managed providers frequently need remote access, and their access is the least well governed in most organisations. It is granted quickly under project pressure, rarely time-bounded, and often survives the end of the contract.

Treat third-party access as a first-class control area: named individual accounts rather than a shared supplier login, access windows tied to scheduled work, the same logging as internal staff, and a contractual obligation to notify you of personnel changes.

Architecture choices

There is more than one way to deliver remote access, and the choice shapes the risk. Traditional VPN-based access extends network reachability and then relies on internal controls. Zero-trust approaches authenticate and authorise each access request against the specific resource. Hosted desktop approaches keep data and processing centrally, so a lost endpoint carries less exposure. Many organisations end up with a hybrid.

The relevant question is not which model is fashionable but what each one assumes. VPNs assume the internal network is a meaningful boundary. Zero-trust assumes you can reliably evaluate identity and device state at every request. Hosted desktops assume you can afford the central capacity and tolerate the latency. Pick the assumption you can actually satisfy.