D3-DRA Disable Remote Access: Switching Off Unneeded Remote Paths and Proving They Stay Off

Every remote access path that a device does not need is a door an attacker can use without touching an exploit, and most estates have more of these doors open than anyone has written down. MITRE D3FEND names the countermeasure Disable Remote Access (D3-DRA) and defines it as "Limiting access to a computing device which is not required through or from a non-organization-controlled network." It sits under the Harden tactic as a child of Application Configuration Hardening (D3-ACH), and D3FEND models it as a technique that configures Application Configuration. This card covers what D3-DRA changes, the ATT&CK techniques D3FEND relates to it, where it is implemented on Windows, macOS, Linux, collaboration platforms and OT controllers, how to prove remote access is really off, and where the control stops. It is written for endpoint engineers, infrastructure teams and OT security leads. The broader design of remote access that you do need is in the Secure Remote Access Beyond VPN Guide.

Key takeaways

• Default to off. D3FEND's own description lists deny-by-default, time-based controls and just-in-time authorisation as the ways to restrict remote access, so the baseline is no remote path unless a named need exists.
• Remove, do not just block. D3FEND's methods include turning off the OS feature, blocking the protocol with firewall rules and uninstalling remote access software. Doing only one leaves the others as a fallback for an attacker.
• The ATT&CK links are thin and inferred. D3FEND relates D3-DRA to four techniques only through the shared Application Configuration artefact, two of them email rules; the practical value is against external remote services and remote access tools, which you map yourself.
• OT gets a physical answer. D3FEND describes powering a remote access modem on and off from a controller output so that the local operator authorises every remote session.
• Prove it from outside and from the endpoint. A configuration baseline says remote access is off; an external scan, a firewall log and an endpoint inventory prove it.

D3-DRA at a glance

How it works

D3-DRA is a hardening control: it removes reachability rather than detecting misuse. D3FEND's description breaks it into a few concrete moves, which in practice form three layers.

• Feature layer: turn off the operating system or application feature that accepts remote sessions. D3FEND's Windows examples are clearing "allow remote assistance" and selecting "don't allow remote connections".
• Network layer: create firewall rules that block remote access protocols, on the host and at the perimeter, so a feature switched back on is still unreachable from networks the organisation does not control.
• Software and interface layer: uninstall remote access software that has no approved use and, where a device must be fully isolated, disable Wi-Fi, Ethernet or Bluetooth interfaces.

The definition is scoped to access "through or from a non-organization-controlled network". That matters for decisions: an internal administrator path through a jump host may be fine, while the same service reachable from the internet or from a supplier's network is exactly what D3-DRA targets. Where a remote path is needed, D3FEND's time-based and just-in-time options keep it closed except during an approved window.

OT: the operator holds the switch

For operational technology D3FEND describes programming logic in the controller so that the operator authorises remote access and local control is maintained: a remote access modem is powered on or off through a discrete output from one of the controller's I/O modules. D3FEND's references for this are Rockwell Automation's ControlLogix 5570 and 5560 controller manual and the Tricon technical product guide, alongside a Dragos article on PLC key switch monitoring. The design point is that remote access is physically absent until a person at the plant enables it. Related OT hardening is covered by D3-OPR Operating Mode Restriction and the OT Remote Access Guide.

ATT&CK techniques D3FEND relates to D3-DRA

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DRA. The rows below are inferred because D3-DRA configures Application Configuration and these techniques modify, or may modify, that same artefact. D3FEND labels such relations inferred and experimental (D3FEND 1.6.0, checked November 2026). D3FEND still lists two IDs that ATT&CK v20 has revoked; the table shows their v20 successors.

None of these four is a remote access technique. The techniques D3-DRA most directly frustrates are External Remote Services (T1133), Remote Services (T1021, including T1021.001 Remote Desktop Protocol) and Remote Access Tools (T1219), plus the ICS techniques External Remote Services (T0822) and Remote Services (T0886). That mapping is an NHI Mgmt Group view, not D3FEND data. For the attacker side see T1133 External Remote Services Defensive Guide, T1021 Remote Services and MITRE ATT&CK T1219 Remote Access Tools. The ATT&CK mitigation closest to D3-DRA is described in M1042 Disable or Remove Feature or Program.

Where it is implemented

Platforms are listed alphabetically within each row. Host firewall design is covered in the Host-Based Firewall Guide, and RDP that must remain on is covered in the Remote Desktop (RDP) Security Guide.

Where identity fits

Remote access paths are also identity paths. A VPN profile, an RMM agent's service account or an SSH key left behind on a server is a non-human credential that keeps a remote door working after the human need has gone. The Colonial Pipeline Ransomware Attack 2021 began through a legacy VPN profile that was no longer in use but had never been disabled, with a leaked password and no MFA. Disabling the path and disabling the account behind it belong in the same change. The identity side is covered in the Remote Access Identity Guide.

Implementation steps

1. Inventory every remote path. List OS remote features (RDP, Remote Assistance, SSH, screen sharing), installed remote access and RMM tools, VPN profiles, supplier access and OT modems. Use endpoint software inventory, an external port scan and firewall rule exports, and compare them.
2. Classify by need. For each path record who needs it, from which network and how often. Anything with no named owner and need is a removal candidate; anything rarely needed is a candidate for time-based or just-in-time enablement.
3. Set the baseline. Configure the Group Policy, MDM or configuration management settings above to disable the features by default, and add host firewall rules that deny the protocols from untrusted networks.
4. Pilot in audit first. Before blocking, log connections on the target protocols for two to four weeks (an example period, not a standard) to find undocumented dependencies such as support teams, monitoring tools or vendor maintenance.
5. Remove the software. Uninstall unapproved remote access tools and add application control rules for installed and portable versions, as CISA AA23-025A recommends.
6. Disable the identities. Disable the VPN accounts, RMM agent credentials and SSH keys tied to the removed paths.
7. Roll out in rings and keep a rollback. Apply to one business unit, then wider. Rollback is re-enabling the policy for a named group through the same management tool, with an expiry date on the exception.

How to verify it works

• External view: scan your internet-facing ranges for remote access ports on a schedule and compare with the approved list. Any listener not on the list is a finding.
• Endpoint view: query configuration state (the effective Group Policy or MDM result for the RDP and Remote Assistance settings, Sharing settings on macOS, service state on Linux) and installed software for remote access tools.
• Log view: on Windows, successful RDP logons appear as event 4624 with logon type 10 (RemoteInteractive); after hardening these should come only from approved jump hosts. Firewall logs should show denied attempts, not accepted sessions, on blocked protocols.
• Drift alerts: alert when a hardened setting changes, when a remote access tool is installed or executed, or when a new listener appears.

Limits, bypasses and failure patterns

• Portable tools in user context: CISA AA23-025A describes attackers running portable remote access executables that need no installation and no administrator rights. Disabling OS features does not stop them; application control and outbound blocking do.
• Outbound tunnels: an attacker on the host can open an outbound tunnel that needs no inbound listener. That falls to outbound filtering and detection; see T1572 Protocol Tunnelling Defensive Guide.
• Local administrators re-enable it: anyone with local admin can turn RDP back on unless the setting is enforced by policy and monitored for drift.
• Not configured is not off: for the Remote Desktop policy, not configured means the local setting decides. Set the policy to Disabled explicitly. The same pattern applies to Microsoft 365 automatic forwarding, where the default value is system-controlled.
• Forgotten paths: supplier modems, out-of-band management cards and old VPN profiles sit outside endpoint management and are missed by baselines.
• Break-glass gaps: removing all remote access without a tested emergency path leads to rushed, unsafe exceptions during an outage. Define and test the break-glass route first.

Framework mapping

Related countermeasures

• Application Configuration Hardening (D3-ACH): the parent; see D3-ACH Application Configuration Hardening.
• Network Access Mediation (D3-NAM): controls the remote access you keep; see D3-NAM Network Access Mediation.
• Operating Mode Restriction (D3-OPR): the OT companion for keeping controllers in a safe mode.
• Multi-factor Authentication (D3-MFA): for every remote path that stays open; see D3-MFA Multi-factor Authentication.

Practitioner checklist

• Keep one inventory of every remote path, its owner, its source network and its expiry.
• Set "Allow users to connect remotely by using Remote Desktop Services" to Disabled where RDP is not needed; do not leave it not configured.
• Disable Solicited and Offer Remote Assistance unless support processes depend on them.
• Turn off Remote Login and other Sharing services on macOS endpoints that do not need them.
• Deny remote access protocols from untrusted networks on host and perimeter firewalls.
• Uninstall unapproved remote access tools and block portable versions with application control.
• Disable the VPN profiles, agent credentials and SSH keys behind every removed path.
• Give OT remote modems an operator-controlled on and off switch.
• Scan externally and alert on configuration drift every month.

Standards and references

• MITRE D3FEND: Disable Remote Access (D3-DRA)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-17, CM-7, SC-7)
• CISA: Protecting Against Malicious Use of Remote Monitoring and Management Software (AA23-025A)
• Microsoft Learn: RemoteDesktopServices Policy CSP
• Microsoft Learn: RemoteAssistance Policy CSP
• Apple: Allow a remote computer to access your Mac
• Google Workspace Admin Help: Let users automatically forward their own Gmail emails
• Microsoft Learn: Control automatic external email forwarding

Related NHI Mgmt Group resources: Secure Remote Access Beyond VPN Guide · Remote Desktop (RDP) Security Guide · Exposed RDP Compromise · M1042 Disable or Remove Feature or Program · MITRE D3FEND Guide