They often treat patching as if it solves the risk on its own. In a perimeter model, the real issue is that the gateway stays public and continues to accept credentials. If the architecture still presents a reachable target, patched software can still be used as an entry point.
Patching Does Not Remove the Exposure Boundary
The core mistake is assuming a patched appliance is no longer a meaningful target. A remote access gateway is still internet-facing, still terminates sessions, and still has to accept some form of authentication. If attackers can reach the box and continue to test credentials, the security problem is not just software defects, it is the exposed access path itself.
That is why patching should be treated as one control in a broader remote access design, not a substitute for redesigning how entry is granted. The question is whether the appliance still presents a public trust boundary, and whether a stolen password, token, or session can still get through it.
When teams only measure success as “the CVE is closed,” they miss the larger risk: the gateway can remain the front door for valid logins, brute force attempts, password spraying, and reused credentials even after the code is current.
Why “Patched” Can Still Mean “Compromisable”
Remote access appliances fail in practice because they concentrate exposure. They aggregate authentication, session handling, and privileged reach behind a single externally reachable service, so a patch may fix one exploit path while leaving the operational attack surface intact. A patched device can still be abused if MFA is absent, dormant accounts remain active, or an attacker has already obtained working credentials.
This is why zero trust thinking is so relevant to remote access: NIST SP 800-207 Zero Trust Architecture pushes teams to verify continuously rather than assume a perimeter appliance makes access inherently safe. The lesson is that reachability and authorization still matter after patching.
Patched appliances also remain operational choke points. If the gateway is the only way in, any compromise, misconfiguration, or credential weakness on that device has outsized impact because the device becomes both the target and the path to the internal environment.
What Teams Should Be Fixing Alongside the Patch
Security teams get better results when they treat patching as the start of risk reduction, not the finish. The control stack should include removing unused remote access paths, enforcing MFA at every entry point, rotating exposed secrets, and reducing standing exposure through tighter authorization and session control. For organisations that rely on privileged or vendor remote access, Privileged Session Management Guide is useful because it focuses on what happens after authentication succeeds.
That same logic is why Remote Access Identity Guide is the right companion to patching: it frames remote access as an identity and access problem, not only a vulnerability management problem. If the appliance still accepts broad credentials, patching only reduces one way in, it does not change who can walk through the door.
Where appliance exploitation is already known or actively exploited, prioritisation should follow exposure, not patch labels alone. External sources such as CISA Known Exploited Vulnerabilities Catalog and NIST National Vulnerability Database help teams distinguish ordinary vulnerability backlog from devices that are already attractive to attackers.
What Good Patching Practice Looks Like for Remote Access
Good practice starts with a different decision rule: if the appliance is still reachable from the public internet, then patching alone is not enough to declare the risk handled. Teams should verify whether remote access has been narrowed, whether authentication is strong enough to resist credential theft, and whether the appliance still has privileged reach that is broader than business need.
For many environments, the better question is whether the gateway should exist at all in its current form. Replacing legacy VPN-style exposure with constrained access paths, better device checks, and shorter-lived sessions often reduces risk more than repeated emergency patching after each new advisory.
Practitioner takeaway: The right model is not “patch and move on,” but “patch, then prove the public access path no longer creates an easy entry point.” If the appliance still accepts credentials from the internet, the architecture is still carrying material residual risk.
Risk and Threat Considerations
Patched remote access appliances remain attractive because they sit at the boundary between the internet and internal systems. Attackers do not need an unpatched code path if they can still exploit weak authentication, stolen credentials, dormant accounts, or an exposed management interface that was never meant to stay public.
Failure mechanism: The appliance is fixed for a specific vulnerability, but the reachable login surface remains. That leaves credential abuse, password spraying, session hijacking, and post-compromise pivoting as viable paths to access.
Impact: A single externally reachable gateway can still become the entry point for broad internal compromise, even when the patch itself is current. The blast radius is often larger than the appliance name suggests because the device brokers trust into other systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-01 — Identity Management and Access Control | Remote access appliances depend on verified access and continuous trust decisions. |
| Recommendation — Apply continuous verification and least-privilege access instead of trusting a patched perimeter device. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Remote access risk persists when credentials remain valid after patching. |
| Recommendation — Rotate and govern remote-access credentials so patching is not the only defense. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Remote access appliances remain risky when credential-based entry is still possible after patching. |
| NHI-01 — Improper Offboarding | Dormant or unused remote access accounts keep exposure alive even after patches are applied. | |
| Recommendation — Strengthen authentication so a patched appliance cannot still be reached with weak or stolen credentials. Remove dormant remote-access accounts and credentials before treating remediation as complete. | ||
| MITRE ATT&CK | T1110 — Brute Force | Public remote access surfaces are commonly probed with password spraying and brute force. |
| Recommendation — Monitor and rate-limit login attempts against exposed remote access services. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The core issue is still accepted credentials on an exposed access endpoint. |
| Recommendation — Treat exposed remote access authentication as a security boundary that must be hardened, not assumed safe. | ||
Practitioner Guidance
What to verify: Confirm that patching was paired with MFA enforcement, account review, and removal of unused remote access entries. If the device still accepts legacy accounts or broad administrative logins, treat the residual exposure as unresolved.
Decision rule: If you cannot reduce or monitor the public attack surface, prioritise access redesign over repeated patch-only remediation. A current version number is not a sufficient control when the gateway remains the front door.
Practitioner takeaway: The best signal of progress is not that the appliance is updated, but that it no longer provides an easy, internet-reachable path for credentials to become internal access.
Related resources from NHI Mgmt Group
- What do security teams get wrong about remote access trust?
- What do security teams get wrong about remote healthcare access?
- What do security teams get wrong about infostealer campaigns that also include remote access?
- What do teams get wrong about monitoring internet-facing remote access appliances for exploitation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org