RD Web access control needs modern MFA without cloud complexity

At a glance

What this is: This is an analysis of how to secure legacy RD Web application access with MFA and access controls while preserving on-premises operating models.

Why it matters: It matters because many IAM and identity teams still support hybrid estates where legacy app delivery, AD governance, and remote access controls have to coexist without adding avoidable identity sprawl.

👉 Read IS Decisions' guidance on securing RD Web applications with MFA

Context

RD Web remains in production because some specialised and legacy applications cannot move cleanly to cloud delivery, but browser-accessible remote application portals still need strong authentication and session control. When those controls are absent, identity governance inherits the exposure of an internet-facing access path even if the application itself stays on premises.

The governance problem is not just authentication strength. It is how to add MFA, session restrictions, and monitoring to a legacy access model without turning the programme into a cloud identity migration project or introducing a second, harder-to-govern control plane.

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: When does MFA alone fall short for published remote applications?

A: MFA falls short when it protects only the login event but not the session. For published applications, teams also need concurrent session limits, workstation or network restrictions, and real-time session visibility so a successful login cannot be used indefinitely or from an unexpected context.

Q: What do teams get wrong about securing legacy application portals?

A: Teams often treat the portal as a temporary UI layer instead of an identity control point. That leads to weak governance, fragmented logging, and inconsistent policy application. Legacy access portals should be managed like any other entry to privileged business systems.

Q: Who is accountable for MFA and session governance on on-prem application delivery?

A: Accountability should sit with the identity and access team, working with infrastructure owners, because the control is part of the authentication and access decision. NIST-style access governance and Zero Trust thinking both assume identity controls follow the access path, not just the application location.

Technical breakdown

Why RD Web access becomes a governance problem without MFA

RD Web is an IIS-based remote application delivery path that exposes a public URL to users reaching on-premises resources. By itself, that creates an authentication boundary that is weaker than modern identity designs because the portal can be reachable from anywhere while the application behind it may still depend on Active Directory and local infrastructure controls. Without MFA, the access decision collapses to password strength and network reachability. That leaves administrators trying to govern a legacy entry point with controls that were not native to the platform.

Practical implication: treat the RD Web endpoint as an identity control point, not just an application convenience layer.

How on-prem MFA changes the control model for IIS-hosted apps

Adding MFA at the IIS or RD Web layer lets teams strengthen authentication without moving the application identity boundary to a cloud IdP. That matters in hybrid estates because the access flow stays inside the existing AD and server architecture, which reduces the number of systems that must be trusted for each login. The technical issue is not merely extra authentication steps. It is whether the verification step occurs close enough to the application delivery path to preserve local control, logging, and policy enforcement.

Practical implication: place MFA where the application is published so the access decision remains aligned with on-prem governance.

Why session controls matter as much as login controls

Strong login authentication does not prevent abuse after the session begins. For published applications, concurrent session limits, context-based restrictions, and real-time monitoring help reduce the blast radius of a compromised account or an overused shared access pattern. These controls are especially useful in environments where users access specialised applications from multiple domains, workstations, or connection types. The important technical point is that authorization should continue after login through session constraints and operator visibility.

Practical implication: enforce session-level constraints and monitoring, not MFA alone, for published remote application access.

NHI Mgmt Group analysis

Legacy remote access creates an identity governance gap, not just an authentication gap. RD Web survives because it fits specialised applications that are hard to modernise, but that longevity also preserves a public-facing access path built before MFA was normal. The governance problem is that legacy delivery tiers often sit outside the identity programme's strongest controls, even when they front critical business applications. Practitioners should treat these portals as part of the identity attack surface, not a separate IT convenience layer.

On-prem MFA is the right control placement when the application is staying on-prem. The article's central value is not the MFA method itself but the decision to keep authentication enforcement close to the IIS-hosted app and inside the existing AD boundary. That reduces architectural drift and avoids creating a second identity estate just to secure one legacy access path. The implication is that identity teams should match control placement to application residency, not force every access problem into cloud identity patterns.

Context-aware session governance is the named control pattern here: access should be constrained after authentication, not just before it. Concurrent session limits, workstation restrictions, and real-time session monitoring make the access model harder to abuse when a public URL fronts valuable internal applications. That pattern matters because many legacy portals are still used by external clients or across multiple domains, where a single successful login can carry more operational risk than the login event suggests. Practitioners should think in terms of session containment for published apps.

Hybrid identity programmes need a control model for specialised apps that cannot justify cloud migration. The article reflects a common reality in IAM: not every application is a candidate for cloud-first redesign, but every application still needs modern authentication and auditability. That makes policy consistency across AD users, groups, OUs, and server-published apps a governance requirement, not a tactical nicety. The practitioner conclusion is to standardise the control pattern, not the hosting model.

RD Web security is an example of why IAM maturity is measured by coverage, not architecture preference. Many organisations remain hybrid because business and compliance constraints keep some workloads on premises. When that happens, security teams need access controls that preserve sovereignty, logging, and operational simplicity without weakening the identity boundary. The field lesson is straightforward: modern identity governance must work across legacy delivery, not only in cloud-native estates.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• A separate finding from the same study shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a reminder that visibility gaps often sit beside control gaps.
• For teams modernising legacy access paths, the Ultimate Guide to NHIs provides the lifecycle and governance context needed to align authentication, visibility, and access review decisions.

What this signals

Legacy access governance will stay a live issue as long as specialised applications remain on-premises. Identity teams should expect pressure to add modern controls to old delivery patterns rather than replace those patterns outright. That means the programme needs a repeatable way to apply MFA, session governance, and auditability to public URLs without forcing cloud identity sprawl.

Context-aware session policy is the next maturity step for hybrid access control. Login strength alone is no longer enough when a portal can be reached from the internet and used across multiple domains or workstations. Teams that can tie user, device, and connection context into session enforcement will have a better chance of keeping legacy app delivery inside Zero Trust expectations.

With 6 distinct secrets manager instances on average, fragmentation is already a control problem in adjacent identity domains, according to The State of Secrets in AppSec. The same pattern shows up in legacy access: the more exceptions a programme creates for old applications, the harder it becomes to govern identity consistently.

For practitioners

• Map every internet-facing RD Web entry point to an identity control owner Record the server, published applications, user groups, and AD objects tied to each portal so accountability sits with IAM rather than general infrastructure operations.
• Enforce MFA at the IIS publishing layer Require second-factor verification where the application is exposed, so authentication is bound to the remote access path instead of relying on a separate cloud IdP.
• Add session limits and context rules for published apps Restrict concurrent logins, connection types, workstation ranges, and allowed access windows to reduce the blast radius of a compromised account.
• Monitor RD Web sessions in real time Use live session monitoring to identify suspicious behaviour and to lock, disconnect, or log off sessions that do not match expected use.
• Export MFA and administrator activity reports for audit evidence Retain logs for MFA events, user logons, and administrative actions so access governance can be reviewed during control testing and compliance checks.

Key takeaways

• RD Web remains a governance problem because it exposes legacy applications through an internet-facing identity boundary.
• MFA is necessary but not sufficient, because session limits, context rules, and live monitoring are what contain abuse after login.
• Identity teams should secure legacy access where it exists, rather than forcing every on-prem application into a cloud-only control model.

Key terms

• Legacy Application Delivery: Legacy application delivery is the practice of exposing older business applications through a remote access layer that users can reach from browsers or published desktops. In identity terms, it creates a distinct access boundary that often predates modern MFA, context checks, and centralised session governance.
• Session Governance: Session governance is the control of what happens after authentication succeeds, including session limits, context restrictions, monitoring, and forced termination. For remote application delivery, it prevents one valid login from becoming unrestricted access across time, location, or device context.
• On-Premises Identity Boundary: An on-premises identity boundary is the set of authentication, authorisation, and logging controls kept inside the organisation's own infrastructure rather than a third-party identity service. It matters when teams want sovereignty, local auditability, and lower architectural dependence for specialised applications.
• Published Application Access: Published application access is a model where a remote portal exposes selected internal applications to users without granting full desktop access. It is useful for specialised workloads, but it must be paired with strong identity controls because the portal itself becomes the entry point to the application environment.

What's in the full article

IS Decisions' full article covers the operational detail this post intentionally leaves for the source:

• The exact deployment prerequisite for the IIS agent on the RDWeb server.
• The specific MFA methods supported for RDP and VPN access paths.
• How admins can set access rules by AD users, groups, and organisational units.
• The session monitoring and reporting features used to support compliance evidence.

👉 The full IS Decisions article covers deployment details, supported MFA methods, and reporting options for RD Web access.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.