RDP-Warnung „Unbekannter Herausgeber“ nach dem April-2026-Patchday — was wirklich dahintersteckt und wie Sie sauber reagieren

Seit dem Patchday vom 14. April 2026 begrüßt Windows seine Anwender beim Öffnen einer .rdp-Datei mit einem neuen, unübersehbaren Sicherheitsdialog. Im Banner steht „Achtung: Unbekannte Remoteverbindung", als Herausgeber ist „Unbekannter Herausgeber" eingetragen, und sämtliche Umleitungen — Zwischenablage, Laufwerke, Smartcards, Drucker, WebAuthn — sind standardmäßig deaktiviert. Wer den Dialog wegklickt, muss sich beim nächsten Doppelklick auf dieselbe Datei erneut entscheiden. In Umgebungen mit DATEV-Arbeitsplätzen, Terminalserver-Sprungbrettern oder vorbereiteten Verbindungsdateien aus dem ServiceDesk hat das innerhalb weniger Stunden zu spürbaren Reibungsverlusten geführt.

Hinter der Verhaltensänderung steht keine zufällige UI-Anpassung, sondern das Sicherheitsupdate zu CVE-2026-26151 — eine bewusst umgesetzte „Secure by Default"-Härtung der Remotedesktop-Verbindung. Microsoft reagiert damit auf die in 2025 beobachtete Welle an Phishing-Angriffen, die manipulierte .rdp-Anhänge zur Kompromittierung von Endpunkten nutzten. Für IT-Teams ist das ein zweischneidiges Ereignis: Die Härtung ist sicherheitstechnisch richtig, aber sie bricht etablierte Workflows, sobald .rdp-Dateien außerhalb eines manuell getippten mstsc-Aufrufs verwendet werden.

Was sich am 14. April 2026 wirklich geändert hat

Das April-Update verändert das Verhalten der Remotedesktopverbindung (mstsc.exe) und der davon abgeleiteten Clients gleichermaßen — auf Windows 10, Windows 11 und allen aktuellen Server-Builds. Microsoft liefert die Änderungen über die kumulativen Updates KB5083769 (Windows 11 24H2/25H2), KB5082052 (Windows 11 23H2), KB5082063 (Windows Server 2025) und KB5082200 (Windows 10 ESU) aus. Die zentralen Neuerungen lassen sich in drei Punkten zusammenfassen.

Erstens zeigt jede .rdp-Datei beim Öffnen einen zweistufigen Dialog. Beim ersten Mal nach der Update-Installation erscheint ein Schulungsdialog, der den Anwender über die Phishing-Risiken aufklärt. Danach sieht jede einzelne Verbindung einen detaillierten Sicherheitsdialog mit der Zieladresse, dem Herausgeber und einer Liste aller Umleitungen, die die Datei aktivieren möchte. Zweitens sind alle Umleitungen standardmäßig deaktiviert — der Anwender muss bewusst entscheiden, was er teilen möchte. Drittens — und das ist der eigentliche Bruch — gilt der Standardwert von AllowUnsignedFiles nicht mehr als implizite Erlaubnis. Unsignierte .rdp-Dateien lösen die Warnung jedes Mal aus, unabhängig davon, ob der Anwender sie zuvor bereits geöffnet hat.

Wichtig zu wissen: Verbindungen, die im Remotedesktop-Client manuell durch Eintippen eines Computernamens gestartet werden, sind von der neuen Logik nicht betroffen. Auch RDP-Dateien, die von Microsoft-Diensten wie Azure Virtual Desktop oder Windows 365 ausgeliefert werden, sind durch Microsofts eigenes Code-Signing-Zertifikat abgedeckt und zeigen die Warnung nicht. Der Effekt schlägt also dort durch, wo Unternehmen selbst .rdp-Dateien generieren oder über Tools wie DATEV-RDS, vorgefertigte Verknüpfungen oder ServiceDesk-Skripte verteilen.

Warum Microsoft jetzt durchgreift

Im Remote Desktop Protocol steckt mehr als nur Bildschirmübertragung. Eine .rdp-Datei ist eine UTF-16-codierte Konfiguration mit Schlüssel-Typ-Wert-Tripeln und kann jede Umleitung — von der Zwischenablage bis zur Smartcard — vorab aktivieren. In einem typischen Phishing-Szenario bekommt das Opfer eine vermeintliche Rechnung, eine Personalakte oder eine Lieferantenanfrage als .rdp-Anhang. Beim Doppelklick verbindet sich der Rechner stillschweigend mit einem Server des Angreifers, gibt Zwischenablage und Laufwerke frei und gestattet im Hintergrund Authentifizierungsumleitungen über WebAuthn. Die Schadwirkung reicht von Dateiabfluss bis zur Übernahme von Authentifizierungs-Token.

Das Microsoft Security Response Center hat 2025 einen deutlichen Anstieg solcher Angriffe dokumentiert. Mit dem April-Update zieht Microsoft die Konsequenz: Statt Anwendern eine optionale Warnung anzubieten, wird die Schutzlogik zum Standard. Wer das ändern möchte, muss aktiv handeln — entweder die .rdp-Dateien signieren, einen Herausgeber als vertrauenswürdig hinterlegen oder den Schutz per Richtlinie temporär abschwächen.

Der scheinbar einfache Weg: Registry-Rollback — und warum er eine Sackgasse ist

Microsoft hat einen Registrierungswert dokumentiert, der den neuen Sicherheitsdialog vorübergehend zurück auf das alte Verhalten umstellt. Der Schlüssel sieht so aus:

Pfad:   HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
Name:   RedirectionWarningDialogVersion
Typ:    REG_DWORD
Wert:   1

Per Gruppenrichtlinien-Präferenz lässt sich der Wert flächendeckend an Computer-OUs verteilen — mit Aktion „Erstellen", damit ein versehentlich nachgepatchtes System den Schutz nicht reaktiviert.

So bequem das wirkt: Microsoft hat den Workaround in der eigenen Dokumentation ausdrücklich als temporäre Maßnahme deklariert und gewarnt, dass ein zukünftiges Update die Unterstützung dieses Registry-Werts auch auf älteren Windows-Versionen entfernen kann. Wer den Wert produktiv ausrollt, baut sich eine Migrationsschuld auf, die spätestens mit dem nächsten halbjährlichen Feature-Update wieder auf den Tisch kommt — dann unter Zeitdruck. Ebenso wichtig: Der Wert schaltet die gesamte Phishing-Schutzlogik ab. Genau jene Anwender, die .rdp-Anhänge aus E-Mails öffnen könnten, verlieren damit den Schutz, den das Update eigentlich aufbauen soll. Aus Compliance-Sicht ist das schwer zu rechtfertigen — die Maßnahme schwächt einen gerade eingeführten Schutzmechanismus, ohne kompensierende Kontrolle.

Für eine kurze Übergangsphase — etwa um eine produktionskritische DATEV-Anbindung am Laufen zu halten, während die Signierungs-Pipeline aufgebaut wird — kann der Workaround vertretbar sein. Als Dauerlösung ist er es nicht.

Der saubere Weg: .rdp-Dateien signieren und Herausgeber vertrauen lassen

Die dauerhafte Lösung besteht aus drei Komponenten: einem Code-Signing-Zertifikat, dem mitgelieferten Werkzeug rdpsign.exe und einer Gruppenrichtlinie, die den eigenen Zertifikatsfingerabdruck als vertrauenswürdigen Herausgeber hinterlegt.

Schritt 1: Code-Signing-Zertifikat bereitstellen

Das Zertifikat muss kein öffentlich ausgestelltes Zertifikat sein. Drei Optionen sind in der Praxis sinnvoll: ein Zertifikat aus der unternehmenseigenen Active Directory Certificate Services (AD CS) mit der Vorlage „Code Signing", ein öffentliches Code-Signing-Zertifikat einer kommerziellen Zertifizierungsstelle oder — für sehr kleine Umgebungen — ein selbstsigniertes Zertifikat aus PowerShell. Für unternehmensweite Rollouts ist die AD CS-Variante klar zu bevorzugen, weil sie sich über Auto-Enrollment beziehen, in Audits sauber nachweisen und über die normale Zertifikatsrotation pflegen lässt.

Wer noch keine interne PKI hat, sollte spätestens jetzt darüber nachdenken — nicht nur wegen RDP, sondern wegen einer ganzen Reihe verwandter Härtungsmaßnahmen, von LDAPS über SMB-Signing bis hin zu signierten PowerShell-Skripten. Bei der Auswahl der Vorlage ist wichtig: Die Enhanced Key Usage muss „Code Signing" (OID 1.3.6.1.5.5.7.3.3) enthalten.

Schritt 2: .rdp-Dateien mit rdpsign.exe signieren

rdpsign.exe gehört seit Windows 7 zum Lieferumfang und liegt in %SystemRoot%\System32. Die Signatur wird in der Datei selbst hinterlegt — die .rdp-Datei bleibt im Klartext lesbar, erhält aber zusätzliche Schlüssel signscope und signature mit einer Base64-codierten PKCS#7-Struktur.

Der Befehl folgt einem einfachen Schema:

rdpsign /sha256 <zertifikat-thumbprint> "C:\Pfad\zur\verbindung.rdp"

Den Fingerabdruck liefert die Zertifikat-MMC oder PowerShell:

Get-ChildItem Cert:\CurrentUser\My |
  Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Code Signing" } |
  Select-Object Subject, Thumbprint

Für die Massenverarbeitung — etwa wenn ein ServiceDesk alle 300 vorbereiteten Verbindungen für die Außenstellen aktualisieren muss — empfiehlt sich eine kleine PowerShell-Schleife, die rdpsign.exe über alle .rdp-Dateien eines Verzeichnisses laufen lässt und das Ergebnis protokolliert. Idealerweise wird der Signiervorgang Teil der Bereitstellung: Wer .rdp-Dateien per Skript, MDM, Intune oder Login-Skript ausrollt, sollte den Signiervorgang in denselben Build-Schritt integrieren, in dem die Datei erzeugt wird.

Schritt 3: Gruppenrichtlinie für vertrauenswürdige Herausgeber konfigurieren

Allein eine signierte Datei reicht nicht — der Client muss den signierenden Herausgeber kennen. Die zugehörige Gruppenrichtlinie findet sich unter:

Computerkonfiguration
 → Administrative Vorlagen
   → Windows-Komponenten
     → Remotedesktopdienste
       → Remotedesktopverbindungs-Client
         → SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige
           Herausgeber von .rdp-Dateien darstellen

Hier wird der Fingerabdruck des Signaturzertifikats hinterlegt — ohne Leerzeichen. Wichtig dabei: Der Name der Richtlinie spricht zwar von „SHA1-Fingerabdrücken", die Einstellung akzeptiert in der Praxis aber den Zertifikats-Thumbprint unabhängig vom Signaturalgorithmus. Wer mit rdpsign /sha256 signiert, trägt denselben Thumbprint hier ein, den die Zertifikat-MMC im Reiter „Details" anzeigt. Microsoft hat den Policy-Namen seit Jahren nicht angepasst — eine separate SHA-256-Richtlinie existiert nicht.

Sobald der Client diesen Wert erhält, öffnet sich der gewohnte Sicherheitsdialog ohne die „Unbekannter Herausgeber"-Warnung. Der Name des Herausgebers — der Subject Common Name aus dem Zertifikat — erscheint sauber im Dialog, die Umleitungen werden weiterhin angezeigt, aber der Anwender erkennt sofort, dass die Verbindung aus dem eigenen Hause kommt.

Welche Variante wann passt

Die folgende Übersicht ordnet die drei Reaktionsmuster den typischen Situationen zu.

Für mittelständische Unternehmen ist die Signaturvariante in der Regel die richtige Wahl. Die Einrichtung dauert ein bis zwei Wochen, läuft danach unauffällig, und alle Änderungen sind im normalen Patch-Zyklus gut wartbar. Die Investition zahlt sich darüber hinaus auch außerhalb des RDP-Kontexts aus — eine einsatzbereite, interne PKI ist Grundvoraussetzung für eine Reihe weiterer Härtungsmaßnahmen.

Schritt 4: Signatur und Trust-Konfiguration verifizieren

Nach dem Rollout lohnt sich eine systematische Prüfung. Auf dem Client zeigt certutil -store -enterprise root und certutil -store TrustedPublisher, ob die Vertrauenskette des Signaturzertifikats korrekt aufgebaut ist. Die signierte .rdp-Datei selbst lässt sich in einem Texteditor öffnen — sie enthält am Ende die Schlüssel signscope:s:Full und signature:s: mit einer Base64-codierten PKCS#7-Struktur. Fehlen diese Zeilen, war der Signiervorgang nicht erfolgreich.

Beim Test-Öffnen der signierten Datei muss der Sicherheitsdialog den Subject-Namen des Zertifikats als Herausgeber anzeigen — nicht „Unbekannter Herausgeber". Erscheint die Warnung trotz Signatur weiterhin, liegt das in der Praxis fast immer an einem von drei Ursachen: Der Fingerabdruck wurde mit Leerzeichen in die Gruppenrichtlinie übernommen, die GPO ist auf der falschen OU verlinkt, oder das Zertifikat liegt im falschen Zertifikatsspeicher (Trusted Publisher statt nur Personal). Eine Verifikation auf einem frisch eingebuchten Testclient deckt diese Ursachen zuverlässig auf.

Stolperfallen, die in der Praxis auftauchen

In den ersten Tagen nach dem Patchday haben sich einige wiederkehrende Probleme gezeigt, die über die reine Warnmeldung hinausgehen. In Umgebungen mit Smartcard- oder Token-basierter Anmeldung an Terminal-Servern brechen Anmeldungen ab, sobald die Smartcard-Umleitung nicht explizit erlaubt ist — eine Konstellation, die viele Unternehmen über .rdp-Dateien automatisch aktiviert hatten. Hier ist die Reihenfolge entscheidend: Erst die Signatur und die GPO-Trust-Konfiguration, dann die Smartcard-Umleitung wieder im Dialog zulassen oder über eine eigene, signierte .rdp-Datei vorgeben.

Ein zweites Muster betrifft .rdp-Dateien, die über RD-Gateway-Einträge angereichert wurden. In einigen Fällen wird die Gateway-Adresse im Sicherheitsdialog als zusätzliche „Verbindung" angezeigt, was Anwender irritiert. Das Verhalten ist designt, aber die Kommunikation sollte das vorab adressieren — sonst landet jeder zweite Ticket-Eingang im First-Level-Helpdesk.

Drittens kollidiert die neue Logik mit Tools, die .rdp-Inhalte zur Laufzeit modifizieren — etwa bestimmte Single-Sign-On-Wrapper oder kundenspezifische Launcher. Jede Modifikation nach dem Signieren invalidiert die Signatur. Wer solche Wrapper im Einsatz hat, muss den Signiervorgang entweder ans Ende der Bereitstellungskette ziehen oder den Wrapper umbauen.

Und schließlich: Die Remote Desktop ActiveX-Steuerung (mstscax.dll) bietet Entwicklern eine Eigenschaft RedirectionWarningDialogVersion, mit der hauseigene Applikationen das Dialogverhalten gezielt konfigurieren können. Wer eine eigene RDP-Frontend-Anwendung pflegt, sollte die Anpassung dieser Eigenschaft in den nächsten Release-Zyklus einplanen.

Was passiert auf älteren Windows-Versionen

Die neue Schutzlogik gilt auch für Windows 10 — sowohl in den regulären Builds als auch in den ESU-Versionen. Microsoft hat die Änderung bewusst breit ausgerollt, weil ein erheblicher Teil der RDP-Phishing-Welle auf Windows-10-Geräten gelandet ist. Auf Server-Seite sind Windows Server 2019, 2022 und 2025 ebenfalls betroffen. Lediglich ältere RDP-Clients ohne aktive Wartung (Windows 7, Windows Server 2012/R2 außerhalb ESU) bleiben unverändert — sie zeigen das alte Dialogverhalten, sind dafür aber generell nicht mehr produktiv einsetzbar.

Wer eine heterogene Flotte aus Windows 10 und Windows 11 betreibt, kann dieselbe Signaturkette für beide Plattformen verwenden — rdpsign.exe und die zugehörige Gruppenrichtlinie funktionieren plattformübergreifend identisch. Wichtig: Die SHA-256-Variante des rdpsign-Aufrufs setzt eine entsprechende Windows-Version voraus. Auf sehr alten ESU-Builds ohne SHA-256-Unterstützung muss übergangsweise mit /sha1 signiert werden — eine zusätzliche Motivation, die Migration auf aktuelle Builds nicht weiter aufzuschieben.

Was Sie jetzt konkret tun sollten

Ein praktikabler Aktionsplan für die nächsten zwei Wochen sieht so aus. Zunächst Bestandsaufnahme: Welche .rdp-Dateien kursieren in der Umgebung, wer erstellt sie, wer verteilt sie? Häufig findet sich eine Mischung aus zentral abgelegten Vorlagen, individuell erzeugten Benutzer-Verknüpfungen und Tool-spezifischen Generaten (DATEV, Citrix StoreFront, ServiceDesk-Skripte). Parallel dazu klären, ob eine Code-Signing-fähige PKI existiert oder zumindest aufgebaut werden kann.

Im zweiten Schritt eine Test-Signierung in einer abgeschotteten Umgebung durchführen — ein typisches Stockholm-Setup mit Testbenutzer, signierter .rdp-Datei und temporär gesetzter GPO. Sobald die Signaturkette nachweisbar funktioniert, kann die GPO auf eine Pilotgruppe ausgerollt werden. Wenn die Pilotphase ohne Beanstandungen läuft — typischerweise nach ein bis zwei Wochen — folgt der breite Rollout, und der Registry-Workaround sollte überall dort, wo er als Übergangslösung eingesetzt wurde, durch die signierte Variante abgelöst werden.

Wer das Thema strukturell angeht, sollte den Vorfall zudem nutzen, um die RDP-Exposition insgesamt zu prüfen. Sind tatsächlich alle RDP-Ports nur über VPN oder RD-Gateway erreichbar? Ist Multi-Faktor-Authentifizierung auf dem Gateway aktiv? Welche Konten haben direkten RDP-Zugriff auf Domänen-Controller oder andere Tier-0-Systeme? Die neue Phishing-Härtung schließt einen einzelnen Vektor — sie ersetzt nicht die grundlegende Netzwerksegmentierung und Zugangskontrolle.

Lehre aus dem Vorfall: Patch-Management braucht Stresstests vor dem Rollout

Der eigentliche Lerneffekt liegt nicht in der RDP-Warnung selbst, sondern in der Schnelligkeit, mit der die Härtung auf Produktionssysteme durchgeschlagen ist. Viele Unternehmen rollen kumulative Sicherheitsupdates nahezu unmittelbar nach Veröffentlichung aus, vor allem nach der Erfahrung mit ungepatchten Schwachstellen aus den Vorjahren. Das ist sicherheitstechnisch richtig — aber es funktioniert nur, wenn der Patch-Prozess einen kurzen, definierten Pilotschritt enthält, in dem genau solche Verhaltensänderungen sichtbar werden, bevor sie 500 Endpunkte gleichzeitig treffen.

Eine kleine Pilot-Gruppe von 10 bis 20 Systemen, die einen Patch zwei bis drei Werktage vor dem Rest erhält, hätte den RDP-Warnungs-Effekt rechtzeitig sichtbar gemacht — und damit Zeit verschafft, um Signierung und GPO vorzubereiten oder zumindest die Anwender vorzubereiten. Wer diesen Pilotschritt heute nicht hat, sollte ihn als zweite Lehre aus dem April-Update mitnehmen.

Wir unterstützen bei der Umsetzung

Saubere Signatur statt riskanter Workaround. Wir bauen die Signierungs-Pipeline für Ihre .rdp-Dateien auf — vom passenden Code-Signing-Zertifikat über rdpsign.exe-Automatisierung bis zur Gruppenrichtlinie für vertrauenswürdige Herausgeber. Im Rahmen unseres Identity & Access Hardening prüfen wir parallel, ob Ihre RDP-Exposition nach aktuellen Standards abgesichert ist: Gateway-Architektur, MFA-Anbindung, Tier-Modell, Remote Credential Guard. Sie erhalten einen umsetzbaren Maßnahmenplan, eine funktionsfähige Signaturkette in Ihrer PKI und dokumentierte Betriebsanweisungen für den weiteren Betrieb.

Beratung zur RDP-Härtung anfragen.