Set policy for device exposure, not just user access, because the router becomes part of the trust chain. Require patching, disable unnecessary external access, and separate work access from consumer cloud features or remote-admin services. If the device cannot be governed, it should not be treated as a trusted path into corporate systems.
Why SOHO Routers Change the Access-Control Problem
A SOHO router is not just a connectivity device when people work through it from home or small offices. It becomes a dependency in the access path, which means its firmware, configuration, exposed services, and remote-management features can affect whether corporate access is trustworthy. Organisations need to treat that router as part of the control surface, not as an invisible background component.
The practical implication is that user identity alone is not enough to decide trust. A device that can expose work traffic, forward ports, run consumer cloud management, or permit remote administration can widen the attack surface around the remote worker. That is why policy has to cover the endpoint path and the router path together, especially when the router sits between an employee and sensitive systems.
For teams that already govern remote access, this is the point where the trust model has to be explicit. The question is not only who the user is, but also whether the network path is maintained, patched, and sufficiently isolated for work use.
What Organisations Should Require Before Treating the Path as Trusted
Set minimum controls for the router itself. Require timely firmware updates, remove unnecessary external administration, and disable any consumer-facing remote features that are not needed for work. If the device exposes services to the internet, that exposure should be reviewed the same way you would review any other externally reachable system that supports access into corporate environments.
Separate work access from consumer cloud features whenever possible. Features such as vendor cloud management, remote support shortcuts, and app-based admin convenience can create alternate control paths that are outside corporate oversight. If the router cannot be governed to the standard your remote access policy requires, then it should not be used as a trusted path to business systems.
Where remote work must traverse home networking equipment, the safer pattern is to reduce the router’s role to basic connectivity and push trust decisions back into managed security controls. That usually means strong authentication at the access layer, constrained routes or segments, and a clear rule that unmanaged router functions do not inherit trust simply because the user is approved.
How to Handle Exceptions and Unsupported Home Networks
Not every household network can be made equivalent to an enterprise-managed perimeter. Some devices are end-of-life, some are locked to consumer cloud ecosystems, and some cannot be patched or monitored reliably. In those cases, the right decision is often to deny trusted access until the path is remediated or to move the worker onto a more controlled access method.
That exception handling should be written as policy, not handled ad hoc by help desk judgement. A simple rule works best: if the router cannot meet the minimum exposure, patching, and isolation requirements, it is an untrusted transport layer. The organisation can still support the worker, but it should not silently inherit risk from an unmanaged home device.
For third-party or high-impact roles, the bar should be even higher because a compromised home router can become a convenient staging point for interception, redirection, or credential capture. In those cases, the access method should be designed so that loss of trust in the local router does not automatically mean loss of trust in the user account.
Risk and Threat Considerations
SOHO routers are attractive because they often sit outside normal enterprise management, are rarely monitored, and may expose remote-admin or cloud-control features that were never intended to support corporate trust. If that device is weakly patched or broadly exposed, it can become a pivot point for interception, unauthorized access, or persistence on the remote worker’s path.
Failure mechanism: An attacker exploits exposed management, outdated firmware, weak credentials, or a consumer remote-support feature to alter routing, redirect traffic, or gain a foothold that affects work access.
Impact: Corporate systems may receive traffic through an untrusted path, which can undermine confidentiality, weaken access assurance, and expand the blast radius of a compromise beyond the endpoint itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Remote access trust depends on strong user authentication at the access boundary. |
| IA-5 — Authenticator Management | Router-linked access depends on protecting and rotating credentials, secrets, and remote-admin auth material. | |
| AC-4 — Information Flow Enforcement | Separating work access from consumer router features requires explicit control over traffic paths. | |
| Recommendation — Enforce strong authentication for remote users before granting enterprise access. Manage and rotate authenticators for remote-access paths and supporting devices. Enforce information-flow rules that keep work traffic on approved paths only. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Remote access through home routers still requires secure authentication controls. |
| A.5.15 — Access control | Policy must govern which remote paths are trusted, including unmanaged home networking equipment. | |
| A.8.9 — Configuration management | Patching, disabling exposed services, and removing unnecessary features are configuration-management concerns. | |
| Recommendation — Require secure authentication for any path that reaches corporate systems. Define access-control rules that reject untrusted remote access paths. Maintain router configurations so exposed services and remote features stay minimized. | ||
Practitioner Guidance
What to prioritise: Put router exposure, firmware currency, and remote-management settings into the remote-access approval process. If those controls are missing, do not treat the home network as a trusted extension of the enterprise.
Decision rule: If the router cannot be patched, governed, and separated from consumer cloud administration, move the worker to a more controlled access pattern rather than making exceptions for convenience.
What to verify: Confirm which internet-facing functions are enabled, whether remote admin is reachable from outside the home, and whether the router is still within vendor support. The key check is not ownership alone, but whether the device is operable under policy.
Practitioner takeaway: For remote work, the router is part of the trust boundary, so access policy must judge the whole path, not just the user identity.
Related resources from NHI Mgmt Group
- What should organisations do when users work around MFA or other access controls?
- How should organisations implement identity and access governance in cloud and remote work environments?
- What breaks when organisations rely on always-on desktop access instead of just-in-time access for remote users?
- How should organisations design remote desktop access for hybrid work without expanding network trust too broadly?