M1035 Limit Access to Resource Over Network Guide

Most intrusions need to reach a service over the network before they can abuse it: a remote access portal, an RDP host, a container API or a cloud metadata endpoint. MITRE ATT&CK mitigation M1035 Limit Access to Resource Over Network is the control that decides which users, workloads and devices can reach those services at all. This guide reads M1035 from the ATT&CK point of view: the 19 techniques and sub-techniques it mitigates in ATT&CK v20, how to prioritise implementation, where non-human identities change the picture, what M1035 does not cover, and how to measure it. It is for security architects, network and platform engineers and detection teams. Segmentation design is covered in the Network Segmentation Guide and zero trust architecture in the NIST SP 800-207 Zero Trust Architecture Guide; this page links them rather than repeating them.

Key takeaways

Reachability is the control. M1035 is about who can connect to a service, not about how the service authenticates; it narrows the set of sources that can even attempt a login or an exploit.
Broadest coverage is remote access and management planes. Of the 19 techniques ATT&CK v20 links to M1035, most concern remote services, external remote services and container or cloud management APIs.
Machine endpoints count. Instance metadata services, the Docker daemon and the Kubernetes API server are network resources that hand out credentials or execution; ATT&CK explicitly lists them.
Concentrate, then restrict. Put remote access behind gateways, VPN concentrators or ZTNA brokers so policy, MFA and logging are enforced in one place, then block direct paths.
Measure exposure, not just policy. Count services reachable from untrusted networks and direct RDP or SMB paths that bypass the gateway, and track them to zero.

What M1035 is

ATT&CK describes M1035 as restricting access to network resources such as file shares, remote systems and services to only those users, accounts or systems with a legitimate business requirement, using network concentrators, RDP gateways and zero trust network access, alongside hardening services and protocols. Its listed measures are: audit and restrict permissions on shares and remote access tools; aggregate remote access through RDP gateways, VPN concentrators or ZTNA with MFA and conditions on time, device and identity; disable unneeded services such as Telnet, FTP and legacy SMB and block unused ports; isolate critical resources with VLANs, firewalls or micro-segmentation; and log successful and failed access attempts.

It overlaps with, but is not the same as, its neighbours:

M1030 Network Segmentation builds the zones; M1035 decides who may cross into a specific service.
M1037 Filter Network Traffic inspects and filters flows by content and protocol; M1035 is access policy per resource.
M1042 Disable or Remove Feature or Program removes the service; M1035 restricts the service you must keep.

MITRE D3FEND models the same defence as Network Resource Access Mediation (D3-NRAM), "control of access to organizational systems and services by users or processes over a network", under the broader Network Access Mediation (D3-NAM), with Remote File Access Mediation (D3-RFAM) for file shares.

Techniques M1035 mitigates in ATT&CK v20

All 19 non-revoked techniques and sub-techniques linked to M1035 in the ATT&CK v20 Enterprise dataset, grouped by tactic, with ATT&CK's usage text paraphrased.

Tactic	Technique	How M1035 helps (ATT&CK usage)
Initial Access	T1190 Exploit Public-Facing Application	Confirm every publicly exposed service is meant to be public; restrict internal-only services
Initial Access, Persistence	T1133 External Remote Services	Route remote services through centrally managed concentrators such as VPNs
Initial Access	T1200 Hardware Additions	Network access control with device certificates and 802.1X; restrict DHCP to registered devices
Lateral Movement	T1021 Remote Services	Prevent unnecessary remote access to file shares, hypervisors and sensitive systems via concentrators and RDP gateways
Lateral Movement	T1021.001 Remote Desktop Protocol	Use remote desktop gateways
Lateral Movement	T1021.002 SMB/Windows Admin Shares	Consider disabling Windows administrative shares
Lateral Movement	T1563.002 RDP Hijacking (T1563 guide)	Use remote desktop gateways
Privilege Escalation, Persistence	T1546.008 Accessibility Features (T1546 guide)	Manage RDP connections and their security configuration through an RD Gateway
Credential Access	T1552 Unsecured Credentials	Limit network access to sensitive services such as the instance metadata API
Credential Access	T1552.005 Cloud Instance Metadata API	Limit access to the metadata API with a host-based firewall such as iptables
Credential Access	T1552.007 Container API	Keep container service access to local Unix sockets or SSH; require TLS and disable unauthenticated Docker and Kubernetes API access
Credential Access, Collection	T1557 Adversary-in-the-Middle	Limit access to network infrastructure that can reshape traffic
Credential Access, Collection	T1557.002 ARP Cache Poisoning	Static ARP entries for key devices (ATT&CK notes this may be infeasible on large networks)
Execution	T1609 Container Administration Command	Restrict container service communications to managed, secured channels with TLS
Execution	T1610 Deploy Container	As above, including container orchestration web applications
Discovery	T1613 Container and Resource Discovery	As above
Stealth	T1612 Build Image on Host	Use the Docker API over TLS on port 2376 rather than unauthenticated access on port 2375
Stealth, Persistence	T1542 Pre-OS Boot	Prevent access to file shares, remote access and unnecessary services
Stealth, Persistence	T1542.005 TFTP Boot	Restrict protocols without encryption or authentication; limit management interfaces to trusted sources

Grouped by what you actually configure, the list falls into four clusters: remote access paths (T1133, T1021, T1021.001, T1563.002, T1546.008), internet exposure (T1190), management and control planes (T1552.005, T1552.007, T1609, T1610, T1612, T1613, T1542.005) and local network infrastructure (T1200, T1557, T1557.002, T1021.002).

Implementation priorities

NHI Mgmt Group recommends this order, which starts with the paths most often used for initial access.

Inventory exposure from the outside. List every service reachable from the internet and from user VLANs, by port and owner. Anything internal-only that is reachable externally is the first fix (T1190, T1133).
Concentrate remote access. Put remote access behind a gateway, VPN concentrator or ZTNA broker that enforces MFA and device conditions, and remove direct paths. Microsoft's Remote Desktop Gateway, for example, provides encrypted access to Remote Desktop resources over the internet, with connection and resource authorisation policies (RD CAP and RD RAP) deciding who may connect and to which hosts. See the ZTNA Guide and the Remote Desktop (RDP) Security Guide.
Restrict internal RDP, SMB and WinRM to admin sources. Allow inbound RDP and remote management only from privileged access workstations or jump hosts, and block workstation-to-workstation SMB. Disable administrative shares where operations do not need them (T1021.002).
Lock down management planes. The Docker daemon listens on a non-networked Unix socket by default; Docker documents SSH (DOCKER_HOST=ssh://) or TLS with tlsverify and CA-signed client certificates for remote access. The Kubernetes API server serves TLS on port 6443 by default (443 in many production clusters); restrict who can reach it with private endpoints and source allowlists in addition to RBAC. Hypervisor and storage management interfaces belong on a dedicated management network.
Protect metadata endpoints. On AWS, require IMDSv2 so requests without a session token fail, and keep the default PUT response hop limit of 1 unless containers on the instance need more. ATT&CK also suggests host-based firewall rules so only the processes that need the metadata API can reach it. See the EC2 Instance Metadata Service Hardening Guide and the Cloud Instance Metadata Services Compared Guide.
Retire unauthenticated protocols. Disable Telnet, FTP, SMBv1 and TFTP where not required, and where TFTP network boot is needed, limit it to a provisioning VLAN (T1542.005).
Control what joins the network. Use 802.1X with device certificates and DHCP registration so unregistered devices cannot reach trusted systems (T1200). See the Network Access Control (NAC) Guide.

Testing and rollback

Observe before blocking: run new firewall or security group rules in log-only mode, or review flow logs for 2-4 weeks, to find legitimate sources before denying.
Pilot rings: move one business unit or one cluster at a time behind the gateway; keep the old path open but monitored for a fixed window, then close it.
Rollback: keep rule changes in version control and deploy them as code, so a rule can be reverted in one change; keep an out-of-band management path for administrators in case the gateway fails.

Choosing a mechanism

Mechanism	Best for	Techniques mainly covered	Trade-offs
RDP gateway or bastion	Administrative RDP and SSH into server estates	T1021.001, T1563.002, T1546.008	Single choke point to make highly available; protocol-specific
VPN concentrator	Broad network access for managed devices	T1133	Grants network-level access; needs segmentation behind it
ZTNA broker	Per-application access with identity and device posture	T1133, T1021, T1190 (for internal apps)	Application onboarding effort; legacy protocols can be harder
Host and cloud firewalls, security groups	Source restrictions on specific ports and management APIs	T1552.005, T1552.007, T1609, T1610, T1612, T1613	Rule sprawl; needs ownership and review
Network access control (802.1X)	Devices joining wired and wireless networks	T1200, T1557	Certificate lifecycle and profiling exceptions

Small organisations: remove direct internet exposure first, use a single gateway or ZTNA service for all remote access, and use cloud security groups to restrict management ports to one admin network. Large organisations: combine ZTNA for users, bastions for administrators, policy-as-code firewalls for workloads and NAC for campus networks, with an owner for every exposed service.

Non-human identities and network policy

Workloads, pipelines and agents connect to far more resources than people do, and their credentials are often long-lived. M1035 is one of the few controls that still works after an NHI credential is stolen, because the credential is only useful from somewhere that can reach the target.

Metadata endpoints are credential services. In the Capital One breach, a misconfigured web application firewall was used to obtain its role credentials through the instance metadata service; requiring IMDSv2 and limiting metadata access are among the lessons the page draws.
Restrict where credentials can be used. Cloud data perimeters and conditions on network origin limit a stolen key to expected networks; see the AWS Resource Control Policies and Data Perimeter Guide. This pairs with M1036 Account Use Policies.
Pod and service egress. In Kubernetes, network policies (enforced by the cluster's network plugin) can stop workloads reaching the API server, metadata endpoints or databases they do not need. See the Kubernetes Security Guide.
CI/CD runners. Runners hold deployment credentials; restrict the networks they can reach, and the sources allowed to reach their management interfaces.

What M1035 does not stop

Abuse from an allowed source. If an attacker controls an admin workstation or a gateway session, network restrictions allow them through. Pair with M1032 Multi-factor Authentication and M1026 Privileged Account Management.
Weak authentication on the gateway itself. Concentrating access moves risk to the concentrator. The Change Healthcare breach began with a stolen credential on a Citrix remote access portal that had no MFA.
Exploitation of services that must be public. Restricting access does not patch a public application; vulnerability management and application hardening still apply.
Server-side request forgery. A trusted internal service making requests for an attacker is an allowed source; metadata tokens and egress controls reduce the impact.

Detection and measurement

Log: gateway, VPN and ZTNA authentication and session logs; firewall and flow logs for denied and allowed connections to management ports (3389, 445, 5985/5986, 22, 2375, 2376, 6443); share access auditing for sensitive shares; Kubernetes API server audit logs; cloud logs showing metadata-derived credentials used from unexpected sources.
Alert on: RDP or SMB sessions that did not come through the gateway or jump host; any connection to Docker port 2375; API server requests from outside approved networks; new internet-exposed services.

Metric	Target
Services reachable from the internet without an approved owner and exception	Zero
Share of remote administrative sessions brokered by a gateway, bastion or ZTNA	Close to 100%
Direct workstation-to-workstation RDP or SMB flows observed per week	Trending to zero
Cloud instances that still accept IMDSv1	Zero outside documented exceptions
Container and cluster management APIs reachable from untrusted networks	Zero
Firewall rules past their review date	Trending down each quarter

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-17 Remote Access; AC-3 Access Enforcement	Authorise and control remote access; enforce access decisions
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection; CM-7 Least Functionality	Managed interfaces and disabling unneeded services and ports
NIST CSF 2.0	PR.IR-01; PR.AA-05	Networks protected from unauthorised logical access; access permissions enforced
MITRE D3FEND	D3-NRAM, D3-NAM, D3-RFAM	Network and remote file access mediation
Related ATT&CK mitigations	M1030, M1032, M1034, M1036, M1037, M1042	Zones, authentication, devices, account conditions, filtering, service removal

Common failure patterns

A gateway alongside direct paths. The gateway is deployed but RDP or SSH remains reachable directly, so policy and logging are bypassed.
A concentrator without MFA. One credential opens the whole network, as in the Change Healthcare case.
Management APIs on flat networks. Docker, Kubernetes, hypervisor and storage interfaces reachable from user subnets or the internet.
Metadata left open to every process. IMDSv1 still allowed and no host restriction, so any SSRF or container escape reaches workload credentials.
Exceptions without owners. Temporary firewall openings never reviewed, which slowly rebuild a flat network.

Practitioner checklist

Produce an external and internal exposure inventory by service, port and owner.
Route all remote access through a gateway, concentrator or ZTNA broker with MFA, then close direct paths.
Restrict inbound RDP, SMB, WinRM and SSH to admin sources only.
Keep Docker on the local socket or SSH/TLS, never unauthenticated TCP; restrict Kubernetes API server reachability.
Require IMDSv2 and restrict metadata access on cloud instances.
Disable Telnet, FTP, SMBv1 and administrative shares where not needed.
Enforce 802.1X or equivalent for devices joining internal networks.
Alert on sessions that bypass the gateway and on new internet-exposed services.
Review firewall and security group exceptions quarterly with owners and expiry dates.

M1035 Limit Access to Resource Over Network: Restricting Who Can Reach Services and APIs