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.
Editorial analysis by NHI Mgmt Group, based on content published by IS Decisions: “How to secure client access to custom RD Web applications”.
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.
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.
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.
Practitioner guidance
- Audit RD Web exposure paths Inventory every externally reachable RD Web endpoint, the applications published through it, and the identity source that authorises access.
- 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.
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: RD Web access control needs modern MFA without cloud complexity