Notifications
Clear all
Topic starter
08/07/2026 7:08 pm
TL;DR: Legacy RD Web deployments still expose internet-facing remote access for specialized applications, and the article argues that layered MFA plus granular access control can strengthen those paths without forcing a cloud IdP or redesign, according to IS Decisions. The core governance issue is that legacy application access often outlives modern authentication assumptions, so identity teams need controls that fit on-prem reality rather than cloud-first architecture.
NHIMG editorial — based on content published by IS Decisions: securing IIS-based RD Web access with MFA and access controls
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read IS Decisions' guidance on securing RD Web applications with MFA →
RD Web access control: what changes when MFA stays on-prem?
Explore further
08/07/2026 7:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: RD Web access control needs modern MFA without cloud complexity
