Windows Server 2025: Sign RDP Files with rdpsign /sha256

Windows Server 2025 administrators should modernize .rdp file signing with rdpsign /sha256, but they should not remove or “convert” the SHA-1-named trusted-publisher Group Policy. Microsoft still documents that policy as using SHA-1 certificate thumbprints, and its April 2026 RDP security changes do not announce the policy’s retirement.
The distinction matters because two similarly named values serve different purposes. The /sha256 option selects a certificate for signing an RDP file, while the existing trusted-publisher policy identifies certificates that Windows should trust by their SHA-1 thumbprints. Treating those mechanisms as interchangeable could break a working trust deployment without improving the security of newly generated RDP files.

April’s RDP Dialog Changes the Default Experience​

Starting with Microsoft’s April 2026 security update, Remote Desktop Connection displays a security dialog whenever a user launches a connection by opening an .rdp file. Microsoft’s documentation says unsigned files appear with an “Unknown publisher” warning because Windows cannot verify who created the file or whether it was modified.
The update also changes how requested local-resource redirections are handled. Resources requested by the RDP file are disabled by default in the dialog, requiring the user to explicitly enable the ones that should be available to the remote session.
That makes RDP file provenance more visible and places an additional user decision in front of each connection. Organizations distributing unsigned connection files may therefore see more warnings, more support calls, and inconsistent choices about resource access.
The practical response is to sign centrally distributed .rdp files and establish deliberate publisher trust where appropriate. It is not to assume that every Microsoft setting containing “SHA1” must immediately be replaced.
WindowsForum has previously covered the operational disruption that can follow Remote Desktop changes in Windows Server 2025 RDP patch failures and the broader mix of Remote Desktop bugs and patch fatigue. The April 2026 change is different in character: it is a documented tightening of the file-launch trust experience, not evidence that the trusted-publisher GPO has disappeared.

The Safe Migration Is in the Signing Workflow​

Administrators can separate this work into signing, trust, and user-experience tracks. The first should be modernized now; the second should be preserved and maintained according to Microsoft’s current documentation.

1. Inventory the .rdp files distributed through portals, shares, scripts, software deployment systems, and administrator documentation.
2. Identify which files are unsigned and would therefore appear as coming from an unknown publisher after the April 2026 update.
3. Review the certificate currently used to sign managed .rdp files, including its expiration and the process for replacing it.
4. On Windows Server 2016 or later, including Windows Server 2025, sign RDP files by supplying the certificate’s SHA-256 thumbprint to rdpsign:

rdpsign /sha256 <certificate-SHA256-thumbprint> <full-path-to-file.rdp>

1. Test the resulting file on an updated client before broad distribution, checking the displayed publisher and every requested resource redirection.
2. Retain and validate the existing policy named “Specify SHA1 thumbprints of certificates representing trusted.rdp publishers” rather than replacing it based solely on its name.
3. When the signing certificate changes, update the trusted-publisher configuration with the SHA-1 thumbprint belonging to the new certificate, following Microsoft’s documented policy format.
4. Remove obsolete certificate entries only after confirming that no active RDP files still depend on the corresponding publisher certificate.

The command and the trust list can therefore refer to the same certificate through different fingerprints. A certificate has multiple representations, and the algorithm used to calculate a thumbprint is not automatically the same thing as the algorithm governing every cryptographic operation involving that certificate.
That is the naming trap at the center of this change. An administrator can correctly use the SHA-256 fingerprint with rdpsign while also correctly entering the certificate’s SHA-1 fingerprint into the trusted-publisher policy.

SHA-1 in the GPO Name Does Not Mean SHA-1 File Signing​

Microsoft Learn still names the policy “Specify SHA1 thumbprints of certificates representing trusted.rdp publishers.” Its documentation states that certificates whose SHA-1 thumbprints match the configured list are treated as trusted RDP publishers.
By contrast, Microsoft’s rdpsign documentation says /sha256 replaces /sha1 on Windows Server 2016 and later. For a Windows Server 2025 signing workflow, /sha256 is therefore the current option admins should use.
These statements are not contradictory. One describes the fingerprint stored in a policy list; the other describes the fingerprint supplied to the file-signing command.
The word SHA-1 understandably triggers concern because the algorithm is obsolete for security-sensitive signing scenarios. But a certificate thumbprint used as an administrative identifier is not equivalent to generating a new SHA-1 signature. Removing a trust rule merely because its friendly name contains SHA-1 risks confusing an identifier with a signing method.
Microsoft may eventually redesign or rename this policy. Based on the documentation available for the April 2026 update, however, it has not announced that transition. Administrators should not invent a migration target that Microsoft has not documented.

Certificate Rotation Is the Real Operational Risk​

The most likely failure point is not an overnight disappearance of the GPO. It is certificate lifecycle management.
When an RDP signing certificate expires or is replaced, newly signed files identify a different certificate. A trusted-publisher list containing only the previous certificate’s SHA-1 thumbprint will not automatically recognize the replacement.
A controlled rotation should therefore overlap the old and new certificates long enough to test both the signing pipeline and client trust. Admins need the SHA-256 thumbprint of the new certificate for rdpsign /sha256 and its SHA-1 thumbprint for the existing trusted-publisher policy.
The deployment should also verify what users actually see. A successful rdpsign command is not, by itself, proof that every managed client has the intended certificate trust or policy configuration.
This is where inventory becomes important. Copies of old .rdp files can persist in Downloads folders, shared drives, ticket attachments, desktop shortcuts, and internal documentation long after the central version has changed. Rotating trust too aggressively may turn those files into warning-generating exceptions, while leaving old trust indefinitely expands the set of certificates Windows accepts as trusted publishers.
The appropriate balance depends on the organization’s distribution process, but the principle is straightforward: add the new certificate, validate new files, replace distributed copies, and then retire the old trust entry deliberately.

---

The Rollback Switch Buys Time, Not a Strategy​

Microsoft documents a temporary way to restore the previous warning-dialog behavior. Administrators can create the RedirectionWarningDialogVersion value under:
HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
The value is a REG_DWORD, with data set to 1.
Microsoft explicitly warns that a future Windows update might remove support for this setting, including on older Windows versions. That warning applies to the dialog rollback; it is not an announcement that the SHA-1-thumbprint trusted-publisher policy will be removed.
This distinction is easy to lose when both items appear in the same RDP hardening discussion. The temporary registry value is backward compatibility for the old prompt experience. The trusted-publisher GPO is a separate mechanism for deciding which certificates represent trusted .rdp publishers.
Using the rollback may be defensible when the April 2026 dialog disrupts a critical deployment and administrators need time to test signed files or update instructions. It should not become the permanent answer, because Microsoft has already said support may disappear.
A better short-term plan is to use the rollback only with a removal date and a named owner. During that window, sign managed files with /sha256, update certificate trust, test redirections, and prepare users for the new dialog.

Redirections Need Their Own Test Plan​

Signing and trusting an .rdp file addresses publisher identity, but it does not eliminate the need to review requested resource access. After the April 2026 update, those redirections begin disabled in the security dialog until the user enables them.
That can affect workflows built around resources exposed from the local computer to the remote session. Administrators should open each representative .rdp file on an updated test client and record which redirections it requests, rather than assuming a trusted publisher restores the previous default behavior in every policy configuration.
The change also creates an opportunity to reduce unnecessary access. If a connection file requests resources that its workload does not require, the better fix is to revise the file rather than training users to enable every box.
This is especially important in Server 2025 environments already carrying complicated Remote Desktop and networking runbooks. WindowsForum’s coverage of Server 2025 firewall and RDP issues illustrates why administrators benefit from separating security-design changes from unrelated connection failures: a publisher warning, a disabled redirection, and an unreachable host may appear in the same support ticket but require entirely different fixes.

What Administrators Should Watch Next​

Microsoft’s current documentation leaves one genuine uncertainty: how long the existing SHA-1-thumbprint publisher policy will remain in its present form. No retirement date, successor policy, or conversion procedure has been announced in the facts Microsoft has published about the April 2026 RDP dialog.
That means IT teams should monitor future Remote Desktop Connection policy and rdpsign documentation, but avoid speculative changes. If Microsoft introduces a new trust-list format, administrators will need an explicit mapping and deployment path before replacing the existing GPO.
For now, the defensible Server 2025 posture is precise: sign .rdp files using rdpsign /sha256, manage certificate rotation as a controlled lifecycle, test the April 2026 redirection prompts, and retain the SHA-1-thumbprint trusted-publisher policy until Microsoft documents an actual replacement.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Configure App Control policies in Windows Server | Microsoft Learn

   Learn how to configure App Control for Business through OSConfig PowerShell commands to harden security by implementing custom security policies.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Windows Server 2025 Faces Critical Firewall and RDP Issues Post-Update | Windows Forum

   Windows Server 2025, Microsoft's latest server operating system, is currently grappling with a series of critical issues following recent security updates...

   windowsforum.com