Forum Discussion
KB5082063 RDP Security update
To the Windows Security Team,
I am writing as an IT Manager responsible for a nationally distributed business infrastructure spanning Queensland, Victoria, South Australia, the Northern Territory, Tasmania, and shortly New South Wales, Australia.
The April 2026 security update KB5082063 introduced a mandatory RDP publisher verification dialog that, with respect, achieves very little in terms of genuine security while causing significant disruption to legitimate business operations at scale.
My concerns are as follows:
1. THE FIX IS WORSE THAN THE THREAT
The dialog appears on every RDP file launch in workgroup environments regardless of whether the publisher is verified and trusted. IT administrators who have gone to the effort of signing RDP files, deploying certificates, and configuring trust stores are still presented with the same warning as an unsigned file from an unknown source. This completely undermines the value of the publisher verification system.
2. THE REAL-WORLD IMPACT
This update required me to spend two full days troubleshooting across a Friday evening and Saturday — time that should have been spent managing a growing national operation — only to discover the resolution was a single registry key buried in a support article. Multiply that across thousands of IT administrators globally and the productivity cost of this update almost certainly exceeds any security benefit it provides.
3. THE SECURITY ARGUMENT IS FLAWED
A determined attacker will find a way around this dialog within hours of it shipping. The users most at risk from RDP phishing — those who would blindly open unsolicited RDP files — are the same users who will click through any security dialog without reading it. This update protects no one who needs protecting and inconveniences everyone who doesn't.
4. WORKGROUP ENVIRONMENTS WERE NOT CONSIDERED
The update appears to have been designed with domain-joined enterprise environments in mind. Businesses running legitimate workgroup configurations — which is extremely common across small to medium enterprises in regional and national Australia — have no clean path to suppress this dialog without resorting to registry modifications that Microsoft itself warns may be removed in a future update. That is not a solution, that is a time bomb.
5. INSIDER PREVIEW GAVE NO WARNING
As an organisation running Windows 11 Insider Preview builds across our environment for months prior to this update, we never encountered this behaviour. It appeared without warning in the stable April 2026 cumulative update, suggesting workgroup scenarios were simply not tested in any preview ring.
I respectfully request that Microsoft:
- Honour publisher trust stores properly so verified and trusted publishers are not treated identically to unknown ones
- Provide a fully supported, permanent Group Policy setting for workgroup environments
- Include regional and SME workgroup scenarios in Insider Preview testing cycles
- Reconsider the one-size-fits-all approach to security dialogs
Security theatre that disrupts legitimate users while doing nothing to stop bad actors is not security. It is bureaucracy — and for businesses like ours operating across an entire country, it is an expensive one.
Regards,
Dyson Pelgrave
IT Manager
Wholesale Paint Group
Cairns, Queensland, Australia
Operating across QLD | VIC | SA | NT | TAS | NSW
5 Replies
Agree with how badly this new prompt is flawed.
Anyone who cannot do the admin registry fix or sign the rdp files may be interested in the little c# clickbot exe I have developed. GitHub dbak91/RdpOneClick
You create a shortcut like "RdpClick.exe <rdp file> Clipboard Drives" to swiftly click clipboard and drives to go back to the old double click and type ux
"THE FIX IS WORSE THAN THE THREAT" - Perfect!
This is overkill. Some other admins have taken to uninstalling the security update that causes this crap. What's next? Pop-up warning messages for the warnings about pop-up warning messages? If you run a "feature" through a focus group and the only people that like it are from Russia and N Korea, maybe don't roll that "feature" out.
"Hey CoPilot, Can you disable this pop-up warning message?"
"I'm sorry Dave. I can't do that."
Does anyone remember when M$'s goal was to make a make an efficient user friendly computer interface?You are correct that a signed RDP file from a trusted publisher still triggers the security dialog rather than being suppressed automatically. According to technical documentation about this update, when an RDP file carries a valid code signature from a trusted Certificate Authority (CA), Windows displays the publisher's name rather than "Unknown publisher," but the dialog itself remains.
Yes i have to agree about that the fix is way worse than the informatic treat beacause of the problems that the security update generated more issues that fixing any problems and I feel really sorry that you had to troubleshoot the friday evening of april 17 and the saturday 18 april and Microsoft should fix this update and the update doesn't protect as you said unless that you need it like for RDP phising like you said in the argument and there were no warnings so people did not knew I think that the update should be optionnal only if you have an issue with the RDP files and put a warning in case that a treat is detected in a test in Est endpoint security and Microsoft defender and always check the files before executing them for you to be safe
I agree with all of the above. In addition, I have a standalone PC, not part of a domain or workgroup. My user account is the Creator/Owner of the RDP files I use daily. They did not come from an external source. I created them, know them and trust them. I use them many times a day every day to access our Dev/Test, DR and Prod servers . Now I have 4 additional clicks EVERY TIME I need to access a server from my desktop.
Applying this extra warning to local and signed files actually weakens security. I created a local certificate, added it to the trust stores, and signed my own RDP files hoping to overcome this extra workload. I still get the additional 'warning'. The only difference is the publisher name instead of 'Unsigned'. I will habituate ignoring the warning because I will come to expect it every time I click my shortcut. So if ever there actually was a malicious one somehow introduced, I wouldn't notice the difference. Insert the tree among the forest analogy here if it helps.
Get rid of the additional security popup for locally-created RDP files where I am the creator owner, or have taken ownership, of the RDP file. In workgroups and domains where users aren't the owner, then having the file signed should do the same. Only show the warning for externally-originated, unsigned files where there is chance of a potential threat.
