RD Web access control needs modern MFA without cloud complexity

At a glance

What this is: This is an analysis of RD Web access control for on-prem and hybrid application delivery, with the key finding that legacy deployments still need stronger authentication and session controls without forcing a cloud-first redesign.

Why it matters: It matters because IAM teams supporting specialised applications still have to secure internet-facing access paths, and the control choice affects cost, complexity, and how much of the identity stack stays on-prem.

Context

RD Web is a legacy browser-based remote access path for on-premises applications, and the security problem is that it often survives in environments where MFA and modern access policy were not designed into the original architecture. That creates a governance gap for teams responsible for specialised or custom applications.

The article's central identity issue is not cloud versus on-prem as a preference question. It is whether access controls can be added to an internet-facing legacy surface without introducing another identity boundary that complicates operations, cost, and compliance.

For organisations that keep applications in-house for licensing, sovereignty, or compatibility reasons, the question becomes how to secure existing Active Directory-backed access without changing the delivery model. That is a familiar pattern in hybrid estates, and it is more common than many cloud-first roadmaps assume.

Key questions

Q: How should security teams protect legacy RD Web access without moving to a cloud IdP?

A: Security teams should place MFA and access rules at the RD Web or IIS publishing layer, then keep enforcement inside the existing Active Directory and server boundary. That preserves on-prem control, reduces integration overhead, and avoids creating a second identity estate just to secure one access path.

Q: Why does RD Web access create risk when MFA is missing?

A: RD Web is externally reachable, but many deployments were built before MFA was standard. Without MFA, a stolen password or other weak credential can be enough to reach specialised applications, especially when session controls, network conditions, and user context are not tightly enforced.

Q: What breaks when RD Web sessions are not governed tightly?

A: Authentication alone breaks down when users can create too many, too long-lived, or too broadly available sessions. In that case, access is technically verified but operationally overextended, which leaves published applications exposed to misuse even after the initial login event has succeeded.

Q: What should teams do when legacy remote access must stay on-prem?

A: They should separate application hosting decisions from identity governance decisions. If the application must remain on-prem, the access layer still needs MFA, session monitoring, conditional restrictions, and reporting so security assurance keeps pace with the legacy delivery model.

Technical breakdown

Why RD Web access remains a governance problem

RD Web exposes applications through a public URL while relying on older access assumptions that predate MFA as a default control. The technical issue is not just authentication, but the mismatch between a legacy remote-access layer and current expectations for granular policy, session oversight, and conditional access. In practice, these environments often rely on directory-backed identity, but the application itself was never built to enforce modern authentication workflows at the edge. That leaves security teams stitching controls around the platform rather than inside it.

Practical implication: treat RD Web as an exposed access tier that needs explicit authentication and session policy, not as a self-securing legacy portal.

How layered MFA changes the access path

Layered MFA for RD Web works by adding a control point between the user, the IIS-hosted application, and the session entry path. In an on-prem deployment, that can be done without replacing Active Directory or moving identity to a cloud IdP. The important architectural distinction is that the control is being inserted into the existing access flow, not used to rebuild the whole authentication estate. That matters for custom applications, multi-domain deployments, and environments that cannot easily absorb identity platform churn.

Practical implication: map where the MFA decision occurs in the login sequence so you can secure the application without redesigning the identity stack.

Why session controls matter after authentication

Authentication alone does not solve RD Web risk if users can create excessive, persistent, or suspicious sessions. Session limits, context-based restrictions, and real-time session monitoring extend the control plane beyond login and into runtime access governance. That is especially relevant where remote access serves specialized applications that are still operationally important but not cloud-native. The security value comes from narrowing who can connect, from where, at what time, and how many concurrent sessions are allowed.

Practical implication: pair MFA with session governance so the access decision survives beyond the initial login event.

Threat narrative

Attacker objective: The objective is to reach and abuse remote application sessions in a legacy on-prem environment without passing through stronger authentication or session governance.

1. Entry occurs through a public RD Web URL that exposes remote application access over the internet.
2. Credential misuse or weak access policy can let an unauthorised user reach the session layer even when the application remains on-premises.
3. Once inside, the attacker or unauthorised user can abuse persistent or overbroad sessions to expand access to published applications.
4. Impact is unauthorised access to specialised business applications, operational disruption, or exposure of internal systems that were meant to stay controlled.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy remote access survives because many organisations still need application-specific delivery, not because they have solved identity modernisation. RD Web continues to exist where cloud migration is not economical, not technically feasible, or not aligned with sovereignty requirements. That means the identity problem is persistent, not transitional. Practitioners should treat it as a durable governance domain, not a temporary exception.

Internet-facing access to on-prem applications needs layered control, not a single authentication gate. MFA is necessary here, but so are concurrent session limits, context-based restrictions, and active session oversight. The governance point is that one-factor remediation does not close the risk created by a publicly reachable legacy portal. Teams need access policy that follows the session, not just the login event.

Modern identity security does not always mean cloud identity architecture. The article reflects a recurring pattern in enterprise IAM: organisations want stronger controls without turning every specialised application into an identity platform migration project. That pressure makes on-prem and hybrid access governance strategically important, especially where Active Directory remains the authoritative control plane.

Granular access control is the real differentiator in legacy application security. Broad MFA coverage alone can still leave too much exposure if sessions remain long-lived, unbounded, or difficult to monitor. The control question is therefore not whether the organisation uses MFA, but whether it can express policy at the level of user, group, workstation, network location, and session type.

RD Web highlights the identity lifecycle gap between legacy delivery and present-day assurance expectations. Access often persists because the application is useful, not because governance has kept pace with the risk. The implication for practitioners is to separate application continuity from identity complacency and measure whether the access path still matches current assurance requirements.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: MFA Guide

What this signals

Legacy access control often persists because the application cannot move, not because the IAM design is complete. RD Web is a useful reminder that many identity programmes still have to secure public entry points for specialised applications without forcing platform migration. The governance test is whether the access layer can absorb MFA and session policy while the application remains where it is.

On-prem MFA is an identity architecture decision, not just an authentication setting. When the identity source stays in Active Directory and the workload stays on-prem, teams need controls that work with that topology rather than against it. That is why hybrid access governance remains a live issue for IAM, PAM, and IGA teams.

Developer behaviour also matters in these environments: only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec. That gap reinforces the need to treat access control as part of the full delivery model, not as a narrow login problem.

For practitioners

• Audit RD Web exposure paths Inventory every externally reachable RD Web endpoint, the applications published through it, and the identity source that authorises access. Focus on whether the portal is serving specialised or legacy workloads that have no native MFA of their own.
• Add MFA at the IIS access layer Insert MFA where the RD Web access decision is made so the control protects the existing login flow instead of forcing a move to a cloud IdP. Keep the change tied to the current Active Directory and IIS arrangement.
• Limit session concurrency and scope Set rules for concurrent logins, simultaneous sessions, workstation constraints, IP range restrictions, connection type, and time of day so the access path is not only authenticated but also constrained at runtime.
• Monitor and terminate suspicious sessions Use real-time monitoring on RD Web sessions so administrators can lock, disconnect, or log off suspicious activity before it spreads into published applications. Export MFA, logon, and administrator action reports for audit readiness.

Key takeaways

• RD Web remains a relevant remote access path for specialised applications, but its legacy design leaves MFA and session governance as external controls rather than built-in protections.
• The article frames the main risk as exposed, internet-facing access that must be secured without turning every on-prem deployment into a cloud identity project.
• For practitioners, the practical response is to combine MFA, context rules, session limits, and monitoring at the existing access layer.

Key terms

• Secure Remote Access: Secure remote access is the controlled method of reaching systems from outside their normal operating boundary. In industrial environments it must combine identity verification, session governance, and protocol constraints so that support access does not become unrestricted operational control.
• Layered MFA: Layered MFA means adding multi-factor authentication at the access layer without assuming it alone solves the whole identity problem. For legacy application delivery, it works best when paired with session limits, contextual restrictions, and monitoring so the control covers both login and runtime access.
• Session Governance: The practice of binding access to a specific task, time window, and execution context, then revoking it when the work is done. For non-human identities, session governance matters because tokens and delegated permissions often persist longer than the action they were created to support.
• Hybrid Identity: Hybrid identity is an architecture that connects on-premises directories with cloud identity providers and SaaS applications. It creates operational flexibility, but it also expands the blast radius of identity compromise across multiple systems that share trust and authentication dependencies.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.