MFA should be enforced at the point that controls the live Windows session, not only at the gateway. RD Gateway can broker access, but the stronger governance outcome usually comes from enforcing authentication at RD Web or the session host, where the actual application session is admitted.
Why This Matters for Security Teams
In RDS environments, MFA placement is not a cosmetic choice. It determines whether the control actually protects the interactive Windows session or only the front door. If MFA is enforced only at a gateway, but the session host admits the user with weaker checks, the attacker who reaches the host can still inherit a live desktop or application context. That distinction matters because RDS often carries privileged admin work, remote support, and sensitive application access.
Security teams also need to distinguish between authentication and session admission. A broker can validate identity, but the session host is where the live workload is exposed and where many abuse paths appear, including credential replay, lateral movement, and session hijacking. This is why current guidance aligns more closely with NIST Cybersecurity Framework 2.0 principles than with a purely perimeter-centric design. NHI Mgmt Group’s research on the Microsoft Midnight Blizzard breach underscores how identity control gaps can turn a valid login path into broader compromise.
In practice, many security teams encounter RDS abuse only after a privileged session has already been established, rather than through intentional design of the authentication boundary.
How It Works in Practice
The strongest pattern is to enforce MFA at the point where the live Windows session is admitted, while also preserving gateway controls as a useful pre-authentication layer. In most mature deployments, that means understanding the difference between the RD Gateway, RD Web, and the session host. The gateway can reduce exposure to the internal network, but it should not be the only control that decides whether a user gets a desktop or published app session.
Operationally, the objective is to ensure the final session decision is tied to the actual resource, not just the network entry point. That aligns with the broader access-control logic in NIST Cybersecurity Framework 2.0, where identity verification, least privilege, and protective controls are evaluated at the point of risk. For Windows-based RDS estates, that usually means:
- Using MFA on RD Web or the session admission flow so the user proves identity before a desktop or app session is created.
- Keeping RD Gateway as an additional control, not the sole trust decision.
- Applying conditional access or device checks where the environment supports them, especially for external or unmanaged endpoints.
- Restricting privileged RDS paths so admin sessions are not treated the same as standard user sessions.
Where organisations manage secrets and service identities around RDS, the broader NHI control picture matters as well. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities highlights how often identities remain overexposed or poorly rotated, which is relevant when RDS hosts depend on shared credentials, automation accounts, or backend service access. These controls tend to break down in legacy RemoteApp deployments with mixed authentication paths because the gateway, web tier, and session host do not share a single consistent enforcement point.
Common Variations and Edge Cases
Tighter MFA placement often increases operational complexity, requiring organisations to balance stronger session assurance against legacy compatibility and support overhead. That tradeoff is especially visible in environments with load-balanced session hosts, older clients, or published apps that were built around simpler credential prompts.
Best practice is evolving, and there is no universal standard for every RDS topology. In some environments, the gateway is still useful as the first enforcement point, but it should not be mistaken for the final one. If the session host accepts the user without a second control, the protection window is thinner than it appears. In higher-risk setups, especially those handling admin access or sensitive data, direct enforcement at RD Web or the session host is the safer interpretation of least privilege.
Edge cases also include certificate-based flows, SSO integrations, and brokered access through third-party tools. Those designs can improve usability, but they should be tested against the same question: where does the live session actually begin? If the answer is unclear, the control is probably too far upstream. NHI Mgmt Group’s analysis of the Ultimate Guide to Non-Human Identities supports a broader lesson: identity controls fail when they are attached to the wrong trust boundary rather than the actual point of access.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | MFA must verify identity at the session boundary, not just the gateway. |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero trust requires least privilege at the resource being accessed. |
| OWASP Non-Human Identity Top 10 | NHI-01 | RDS often relies on identities and secrets that need strong control and visibility. |
Inventory all RDS-related identities and secrets, then enforce MFA where those identities gain session access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
