I would like your opinion on something before I turn it into a formal RFE. There is a very common CVAD pattern that quietly burns VDA CPU on every session, and I rarely see it questioned. Users connect over HDX to a VDA, then open mstsc inside the session to reach servers in segments that only the VDA can route to. Classic bastion. The catch is that the remote desktop is decoded by mstsc on the VDA and immediately re-encoded by HDX for the trip to the endpoint. Two encodes and two decodes, for content that should be decoded exactly once. Adaptive Display often makes it worse, classifying the busy RDP window as video and pushing it through H.264 on the VDA, so you pay CPU and lose text clarity at the same time. The idea I want to validate with you: decode the inner protocol once, on the endpoint. CWA would terminate the RDP presentation and input, while the socket to the target stays on the VDA, which relays the RDP PDU stream at the application level. No L3 forwarding, so segmentation is untouched. It is the same move Citrix already made for Browser Content Redirection and Teams optimization, now applied to RDP. Importantly, this is not RDP Proxy, because the whole point is to keep the governed HDX session intact. Why I think it would be worth it: • Lower VDA CPU and GPU per session, because the redundant decode and re-encode disappear. At scale that means higher session density and fewer hosts for the same user count, which is a direct infrastructure saving. • Lower interactive latency, because one decode replaces a decode plus a re-encode in the path. • Better image quality, because you stop recompressing already compressed content, so text stays crisp. • Cleaner device redirection, because a real RDP client engine maps clipboard, drives, and printers straight to the endpoint instead of through a fragile nested chain. • Full HDX session retained, with policies, EDT, and Director visibility, which RDP Proxy gives up. Segmentation preserved, because the socket to the target never leaves the VDA. Working name for now: In-Session Remote Protocol Redirection. What do you think of this idea?

Security could be a potential concern even if encapsulated in HDX, potential secure RDP data will run on endpoint as offloaded. The likes of BCR and Teams offload usually is different as the endpoint connects to an Internet provider, MS Cloud Teams, Youtube for BCR. Even if BCR can do it for an internal website. In this case it's not sensitive potential data running local. Last I use load of RDP within my Citrix session, CPU has never been an issue. Memory is larger especially in W25 but that's it for my conf. Anyhow why not but to me it won't make any difference.

Fair points. On security: that data already reaches and is decoded on your endpoint today, because HDX sends the rendered pixels of the RDP session to CWA right now. ISRPR changes the format it travels in, not what lands locally. The real new exposure is the client side decoder, which is why it must be sandboxed, fuzzed, policy gated per target, and opt-in. Sensitive target you do not trust? Leave it off. In transit it is no weaker, same encrypted HDX path. On CPU: agreed for static admin RDP, it stays in the cheap Thinwire path and costs almost nothing. The penalty only bites on high motion content, when Adaptive Display flips to H.264 on the VDA. That is video, dashboards, and the CCTV case, not console work. On memory: partly your side. Moving mstsc and its buffers off the VDA to CWA frees host RAM at density, which matters more on the Windows Server 2025 baseline. So for light admin RDP with memory as your limiter, you are right that it barely moves the needle. It pays off on high density, high motion inner content, latency, and cleaner device redirection. Not universal, and I would rather say that than oversell it.

I can see your points, it's a niche use case IMO, you can chance it.