Warum Windows die Meldung „Der Computer wurde durch Windows geschützt“ anzeigt

SmartScreen, Codesignierung, EV-/OV-Zertifikate und die Verteilung über MSIX/Store, praxisnah eingeordnet

Wenn Sie eine Windows-App erstellen und verteilen, ist diese Warnung meist die erste Mauer, gegen die Sie laufen.

Der Computer wurde durch Windows geschützt
Von Microsoft Defender SmartScreen wurde der Start einer unbekannten App verhindert.

Wenn diese Warnung erscheint, werden Nutzer verunsichert. Auch Entwickler grübeln: „Es ist doch kein Virus — warum wird es blockiert?“ oder „Ich habe doch signiert — warum kommt die Warnung trotzdem noch?“

Dieser Artikel ordnet SmartScreen-Warnungen bei der Verteilung von Windows-Apps aus der Perspektive von Codesignierung, EV-/OV-Zertifikaten, MSIX, Microsoft Store, ClickOnce und interner Verteilung ein.

1. Dieser Artikel in einem Satz

Bei der Verteilung von Windows-Apps ist Codesignierung notwendig.
Codesignierung ist aber kein Zauberspruch, der SmartScreen-Warnungen sicher zum Verschwinden bringt.

Wichtig ist, drei Perspektiven getrennt zu betrachten.

Eine grobe Entscheidungshilfe sieht so aus:

2. SmartScreen ist nicht nur „Virenerkennung“

Erscheint eine SmartScreen-Warnung, denken Nutzer: „Ist diese App gefährlich?“

SmartScreen prüft aber nicht einfach nur, „ob es sich um einen Virus handelt“. Microsofts Erklärung zufolge betrachtet es bei heruntergeladenen Dateien vor allem folgende Rufinformationen.

Wichtig ist hier: Eine neu erstellte Datei hat noch keinen Ruf.

Auch wenn die App aus Ihrer Sicht korrekt ist, ist sie aus Sicht von Windows „eine zum ersten Mal gesehene Datei“. Selbst wenn sie signiert ist, kann eine SmartScreen-Warnung erscheinen, solange der Ruf des Datei-Hashs oder des Herausgebers noch nicht ausreicht.

Mit anderen Worten lässt sich die SmartScreen-Warnung so verstehen:

Es bedeutet nicht, dass die Datei als Malware eingestuft wurde.
Es bedeutet aber, dass Windows sie noch nicht für ausreichend vertrauenswürdig hält.

Versteht man diesen Unterschied nicht, führt das zu Missverständnissen wie „ich habe signiert, aber es hat sich nichts geändert“ oder „ich habe ein EV-Zertifikat gekauft, aber nichts hat sich geändert“.

3. Was Codesignierung tatsächlich garantiert

Codesignierung garantiert im Wesentlichen zwei Dinge:

1. Dass die Datei vom angezeigten Herausgeber signiert wurde
2. Dass die Datei seit der Signierung nicht manipuliert wurde

Umgekehrt garantiert sie direkt Folgendes nicht:

• Dass die App absolut sicher ist
• Dass die App keine Fehler enthält
• Dass niemals eine SmartScreen-Warnung erscheint
• Dass sie von Unternehmensrichtlinien immer erlaubt wird

Trotzdem ist Codesignierung nahezu unverzichtbar.

Ohne Signatur kann der Nutzer den Herausgeber nicht erkennen. In Unternehmensumgebungen können unsignierte Dateien durch App Control, EDR, Defender, Proxys oder E-Mail-Gateways blockiert werden. Auch beim Bau eines automatischen Updates wird die Signatur wichtig, um zu prüfen, ob die Update-Datei echt ist.

Mit anderen Worten: Codesignierung dient nicht nur „zum Verschwindenlassen der Warnung“, sondern ist die Grundlage für Verteilung, Updates, Auditierung und den Unternehmenseinsatz.

4. „Mit einem EV-Zertifikat verschwindet die Warnung von Anfang an“ ist ein veraltetes Verständnis

Früher war weithin verbreitet, dass ein EV-Codesignaturzertifikat bei SmartScreen bevorzugt behandelt wird.

Heute ist es jedoch zumindest riskant, ein EV-Zertifikat allein zur Umgehung von SmartScreen zu kaufen. Microsofts Entwicklerdokumentation SmartScreen reputation for Windows app developers hält ausdrücklich fest: „EV-Zertifikate umgehen SmartScreen nicht mehr“ und „es ist nicht mehr gerechtfertigt, allein zur Vermeidung der SmartScreen-Warnung einen Aufpreis für EV zu zahlen“. In der Tabelle nach Zertifikatstyp auf derselben Seite werden OV und EV in derselben Zeile „gültiges Zertifikat (OV/EV)“ zusammengefasst, und das Verhalten beim ersten Download wird als „Warnung, bis sich Ruf aufgebaut hat“ beschrieben. Auch mit EV signierte Dateien müssen, genau wie bei OV-Zertifikaten, mit einem Ruf rechnen, der sich erst aufbaut.

Das heißt nicht, dass EV-Zertifikate überhaupt keinen Sinn hätten.

• Die strengere Identitätsprüfung wird bei der Unternehmensbeschaffung honoriert
• Die Sicherheitsprüfung eines Geschäftspartners verlangt EV
• Man besitzt bereits ein EV-Zertifikat und möchte es weiter nutzen

Liegen solche Gründe vor, spricht nichts gegen die Nutzung.

Nur zu diesem Zweck sollte man ein EV-Zertifikat aber nicht kaufen:

Ein EV-Zertifikat kaufen, weil die SmartScreen-Warnung von Anfang an verschwinden soll

Ist das das Ziel, sollte man zuerst Verteilungsweg, Signaturmethode, Kommunikation an frühe Nutzer, Update-Frequenz und die Möglichkeit einer Store-Verteilung überprüfen.

5. Optionen für die Signierung

Hier eine Zusammenfassung der bei der Verteilung von Windows-Apps gängigen Signatur- und Verteilungsoptionen.

Microsoft Store / MSIX

Für die Verteilung an Endanwender lohnt es sich, zuerst den Microsoft Store zu prüfen.

Besonders die Kombination aus MSIX und Store-Verteilung ist bei Zertifikatsverwaltung und SmartScreen-Warnungen im Vorteil. Ein an den Store übermitteltes MSIX-Paket wird von Microsoft erneut signiert, wodurch auch der Aufwand für Entwickler sinkt, Zertifikate einzeln zu kaufen und zu erneuern.

Allerdings ist nicht jede Windows-App für MSIX geeignet.

• Tiefe Nutzung von Windows-Diensten
• Ein Treiber wird benötigt
• Shell-Erweiterungen sind vorhanden
• Alte COM-Registrierungen oder ActiveX-Bestände sind vorhanden
• Bei der Installation sind komplexe Systemänderungen nötig

In solchen Fällen kann MSI oder ein klassischer Installer natürlicher sein als MSIX.

Azure Artifact Signing

Azure Artifact Signing ist ein von Microsoft bereitgestellter cloudbasierter Codesignaturdienst. Früher hieß der Dienst Trusted Signing, der offizielle Name lautet heute Azure Artifact Signing (Artifact Signing). Auch Microsofts Produktseite schreibt „Artifact Signing (formerly Trusted Signing)“. Da viele Artikel und interne Dokumente noch den alten Namen verwenden, sollten Sie bei der Suche nach beiden Namen suchen. Die offizielle Dokumentation finden Sie unter Microsoft Learn: What is Artifact Signing? und Azure: Artifact Signing (formerly Trusted Signing).

Der Reiz liegt darin, dass kein physischer USB-Token nötig ist und sich der Dienst leicht in CI/CD integrieren lässt. Er ist eine starke Signaturoption für die Verteilung außerhalb des Stores, unterliegt aber Bedingungen bezüglich Region und Konto.

Nach Microsofts Unterlagen mit Stand 2026 sind für Organisationen die USA, Kanada, die EU und Großbritannien vorgesehen, für einzelne Entwickler die USA und Kanada. Bei Nutzung durch japanische Unternehmen oder Einzelpersonen müssen Sie die Nutzungsbedingungen unbedingt prüfen. Ist die Nutzung nicht möglich, wird ein klassisches OV-Codesignaturzertifikat zur realistischen Alternative.

Auch bei Signierung mit Azure Artifact Signing wird das SmartScreen-Vertrauen nicht sofort gewährt. Wie bei OV-Zertifikaten baut sich der Ruf entsprechend der Verteilungshistorie auf.

OV-Codesignaturzertifikate

Für japanische Entwickler und Unternehmen, die Windows-Apps außerhalb des Stores verteilen, bleibt das OV-Codesignaturzertifikat auch heute eine realistische Wahl.

Mit einem OV-Zertifikat wird dem Nutzer der Herausgebername angezeigt — das ist eindeutig besser als keine Signatur. Bei neuen Apps oder neuen Dateien können jedoch weiterhin SmartScreen-Warnungen erscheinen.

Bei der Nutzung eines OV-Zertifikats sollte man auf Folgendes achten:

• Den Herausgebernamen dauerhaft beibehalten
• Jedes Mal als derselbe Herausgeber signieren
• Die Datei nach der Signatur nicht mehr verändern
• Einen Zeitstempel setzen
• Nicht nur die EXE, sondern auch DLLs, MSI und den Updater prüfen
• Einen Migrationsplan für die Zertifikatserneuerung bereithalten

Selbstsignierte Zertifikate

Selbstsignierte Zertifikate sind praktisch für Entwicklung und Tests.

Für die öffentliche Verteilung sind sie jedoch grundsätzlich nicht geeignet. Aus Sicht des Windows-Systems des Nutzers ist dieses Zertifikat nicht vertrauenswürdig.

Selbstsignierte Zertifikate lassen sich in solchen Umgebungen einsetzen:

• Der lokale PC des Entwicklers
• Die Testumgebung eines Testers
• Interne Endgeräte, auf denen vertrauenswürdige Zertifikate per Intune oder GPO verteilt werden können
• Abgeschottete Umgebungen, in denen die Gerätekonfiguration vollständig verwaltet wird

Auch bei der Nutzung eines selbstsignierten Zertifikats muss man verwalten, „wann es entfernt wird“, „wer es als vertrauenswürdig eingetragen hat“ und „ob es sich nicht mit der Produktionsumgebung vermischt“.

6. Was in der Praxis signiert werden sollte

„Ich habe die EXE signiert, also fertig“ — so einfach ist es nicht.

Bei der Verteilung von Windows-Apps sollte man alle Signaturziele der Reihe nach prüfen.

Bei Verwendung von SignTool sind mit dem aktuellen Windows SDK die Optionen /fd und /td wichtig. Typischerweise gibt man SHA256 an.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

Die Bedeutung der einzelnen Optionen ist wie folgt:

Als URL des Zeitstempeldienstes verwenden Sie die vom Zertifikatsherausgeber angegebene. In den Beispielen von Microsofts SignTool-Dokumentation wird http://timestamp.digicert.com verwendet, in den Signaturschritten von Artifact Signing https://timestamp.acs.microsoft.com. Setzt man einen Zeitstempel, wird festgehalten, dass das Zertifikat zum Zeitpunkt der Signierung gültig war, sodass die Signatur auch nach Ablauf des Zertifikats weiter nutzbar bleibt.

Die Art der Zertifikatsangabe wählt man je nach Umgebung:

Leicht übersehen wird, dass SignTool ohne /sm nur den persönlichen Speicher des ausführenden Benutzers durchsucht. Das führt häufig zu „Zertifikat nicht gefunden“ — etwa weil das Zertifikat zwar im Speicher „Lokaler Computer“ liegt, /sm aber nicht angegeben wurde, oder weil der Build unter einem Dienstkonto läuft, das Zertifikat aber im persönlichen Speicher eines anderen Benutzers liegt. Legen Sie bei der Signierung in CI zuerst fest, in welchem Speicher welches Kontos das Zertifikat liegt.

Ob die Signatur erfolgreich war, prüft man anhand dieser drei Punkte:

• signtool verify /pa /v .\MyApp.exe muss erfolgreich sein
• Der Exit-Code dieses Befehls muss 0 sein (unter PowerShell direkt danach $LASTEXITCODE prüfen)
• Im Explorer die Dateieigenschaften öffnen: Im Tab „Digitale Signaturen“ müssen Herausgeber und Zeitstempel angezeigt werden

Entscheidend ist, das finale Artefakt zu signieren.

Wird die EXE nach der Signatur noch verändert, werden Dateien im ZIP ausgetauscht, oder werden nach dem Erstellen des Installers eingebettete Dateien verändert, kann die Signatur beschädigt werden oder das Prüfergebnis von der Erwartung abweichen.

In der Build-Pipeline sollte diese Reihenfolge festgelegt werden:

Build
  ↓
Abhängige Dateien sammeln
  ↓
Installer / Paket erstellen
  ↓
Signieren
  ↓
Signatur prüfen
  ↓
Hash protokollieren
  ↓
Verteilen

7. Überlegungen je Verteilungsmethode

MSI-/EXE-Installer

Bei der Verteilung über einen MSI- oder EXE-Installer signieren Sie unbedingt die Datei, die der Nutzer zuerst ausführt.

Zusätzlich sollten auch die nach der Installation platzierten EXE- und DLL-Dateien als Signaturziele überprüft werden. Ist nur der Installer signiert, kann ein danach platzierter unsignierter Updater oder Hilfsprozess in Unternehmensumgebungen blockiert werden.

Die zu klärenden Punkte sind weitgehend festgelegt:

• Den Installer selbst signieren
• Auch die darin enthaltenen EXE-/DLL-Dateien signieren
• Vorgänge, die eine UAC-Erhöhung benötigen, auslagern
• Updater und Service-Hilfsprozesse gesondert auditieren
• Die URL der Download-Seite stabil halten
• Frühen Nutzern den Herausgebernamen mitteilen

MSIX

MSIX ist eine Methode mit starker Konsistenz auf Paketebene.

Ist eine Store-Verteilung möglich, wird der Umgang mit SmartScreen-Warnungen und Zertifikatsverwaltung deutlich einfacher. Bei internem Sideloading oder Verteilung außerhalb des Stores müssen dagegen Paketsignatur und Zertifikatsvertrauen von MSIX sorgfältig gestaltet werden.

Hier einige Hinweise:

• Für Entwicklung und Tests genügt eine Selbstsignierung
• Für die Produktionsverteilung eine öffentlich vertrauenswürdige Signaturmethode verwenden
• Den Publisher im appxmanifest mit dem Subject des Zertifikats abgleichen
• Bei Verteilung außerhalb des Stores mit möglichen SmartScreen-Warnungen rechnen
• Vorab prüfen, ob keine für MSIX ungeeignete OS-Integration vorliegt

ClickOnce

ClickOnce eignet sich gut, um .NET-Fachanwendungen (WinForms/WPF usw.) an Standardnutzer zu verteilen.

Allerdings verschwindet das SmartScreen-Problem nicht allein dadurch, dass ClickOnce verwendet wird. Relevant sind der Weg, über den Nutzer die Datei herunterladen und starten, die Manifestsignatur, die Verteilungsquelle sowie Dateiänderungen bei Updates.

Bei ClickOnce sollte Folgendes geprüft werden:

• Signatur des Anwendungsmanifests und des Bereitstellungsmanifests
• Verwaltung der Verteilungs-URL oder des Freigabeordners
• Umgang mit Zertifikatswechseln bei Updates
• Ob interne Proxys oder Defender blockieren
• Nutzerhinweise bei der Erstinstallation

Die Stärke von ClickOnce ist die einfache Verteilung — wird aber nicht auch das Vertrauen des Herausgebers und der Verteilungsweg mitgestaltet, bleibt es in der Praxis hängen.

xcopy-/ZIP-Verteilung

Eine Verteilung, bei der nur ein Ordner abgelegt oder ein ZIP entpackt wird, ist einfach.

In abgeschotteten Umgebungen und für interne Tools kann das funktionieren. Bei der Web-Verteilung an Endanwender ist es aber auch die Methode, die am stärksten von SmartScreen, Defender und dem Mark of the Web betroffen ist.

Das hier erwähnte Mark of the Web (MOTW) ist ein alternativer Datenstrom namens Zone.Identifier, den Browser und E-Mail-Programme heruntergeladenen Dateien anheften. Es ist ein Vermerk „diese Datei stammt aus dem Internet“ und wird für die SmartScreen-Prüfung, die Makroblockierung in Office und die Beurteilung der PowerShell-Ausführungsrichtlinie (RemoteSigned) verwendet. Entfernen lässt sich der Vermerk, indem man im Explorer die Dateieigenschaften öffnet und im Bereich „Sicherheit“ das Kästchen „Zulassen“ aktiviert, oder über das PowerShell-Cmdlet Unblock-File. Ob der Vermerk beim Entpacken eines ZIP an die enthaltenen Dateien weitergegeben wird, hängt vom verwendeten Entpackwerkzeug ab. Näheres dazu finden Sie im Kapitel „Zone.Identifier (Mark of the Web) und Unblock-File“ des Artikels PowerShell-Ausführungsrichtlinie und Skriptsignatur.

Setzen Sie auf xcopy-Verteilung, sollten Sie hierauf achten:

• EXE-/DLL-Dateien signieren
• Sich nicht allein auf das ZIP verlassen, sondern die enthaltenen Dateien prüfen
• Die Verteilungsquelle festlegen
• Version, Hash und Änderungsverlauf klar angeben
• Wird ein automatisches Update nachträglich hinzugefügt, eine Signaturprüfung einbauen

Statt „es ist einfach, weil wir keinen Installer bauen“ sollte man denken: „wir übernehmen selbst die Verantwortung, die sonst ein Installer trägt“.

Eigene Updater

Ein eigener Updater ist praktisch, stellt aber selbst eine Sicherheitsgrenze dar.

Ein Updater lädt neue Dateien herunter und ersetzt bestehende. Mitunter läuft er mit Administratorrechten. Bricht hier etwas, ist das gefährlicher als die App selbst.

Mindestens sollte Folgendes geprüft werden:

• Update-Metadaten signieren
• In die Metadaten Version, Hash, Größe, Kanal und Ablaufdatum aufnehmen
• Nach dem Download Hash und Signatur prüfen
• Bei fehlgeschlagener Prüfung fail-closed abbrechen
• Ein Rollback-Verfahren bereithalten
• Festlegen, wie der Updater selbst aktualisiert wird
• Den Produktions-Signaturschlüssel von der Entwicklungsumgebung trennen

Dieses Thema lässt sich gut zusammen mit dem bestehenden Artikel „Sicherheitsdesign für automatische Updates“ betrachten.

8. Bei interner Verteilung reicht ein Blick auf SmartScreen allein nicht

Bei internen Apps besteht ein verbreitetes Missverständnis:

Wird nur intern genutzt, also brauchen wir keine Signatur

Das ist gefährlich.

In internen Umgebungen spielen neben SmartScreen mehrere weitere Mechanismen eine Rolle.

Besonders in Umgebungen mit App Control for Business geht es nicht nur darum, „ob signiert wurde“, sondern auch darum, „ob dieser Herausgeber erlaubt ist“, „ob es über einen Managed Installer kam“ und „ob Hash oder Pfad erlaubt sind“.

Auch Microsofts Bereitstellungsleitfaden beschreibt den Ansatz, Richtlinienänderungen bei App Control zunächst im Überwachungsmodus auszurollen, zu prüfen, ob die Blockierungsereignisse wie erwartet ausfallen, und erst danach in den Erzwingungsmodus zu erweitern.

Bei interner Verteilung ist es realistisch, in dieser Reihenfolge vorzugehen:

1. Zielgeräte aufteilen
   - Entwickler
   - Tester
   - Einzelne Abteilungen
   - Gesamtes Unternehmen

2. Verteilungsweg festlegen
   - Intune
   - GPO + Dateifreigabe
   - Internes Portal
   - VDI / RemoteApp
   - Manuelle Verteilung in abgeschotteten Umgebungen

3. Vertrauensregeln festlegen
   - Herausgeberregeln
   - Zertifikatsverteilung
   - Managed Installer
   - Hash-Freigaben
   - Pfad-Freigaben

4. Im Überwachungsmodus prüfen
   - Was blockiert wird
   - Welche DLLs oder Hilfsprozesse übersehen wurden
   - Ob Updates als andere Datei behandelt werden

5. Stufenweise ausrollen
   - Klein anfangen
   - Protokolle beobachten
   - Freigaberegeln anpassen
   - Ausweiten

Der Kern der internen Verteilung ist nicht die Umgehung von SmartScreen, sondern einen Verteilungsweg zu schaffen, den sich Windows erklären lässt.

9. Häufige Missverständnisse und die richtige Sichtweise

10. Wie man Nutzern beim Erstrelease die Situation erklärt

Bei einer neuen App können in den ersten Wochen und bei frühen Nutzern SmartScreen-Warnungen erscheinen.

Nutzern dabei einfach zu sagen, „führen Sie es trotz Warnung aus“, ist keine gute Praxis. Eine sichere Erklärung enthält Informationen, die man selbst prüfen kann.

Diese Punkte sollten in den Hinweis aufgenommen werden:

• Die offizielle Download-URL
• Der angezeigte Herausgebername
• Der Dateiname
• Die Versionsnummer
• Das Veröffentlichungsdatum
• Bei Bedarf der SHA-256-Hash
• Wie man prüft, dass die Datei signiert ist
• Der Hinweis, Dateien aus unbekannten Quellen nicht auszuführen

Für die interne Nutzung ist zum Beispiel dieser Hinweis sicher:

Diese App wird ausschließlich über folgende Seite im internen Portal verteilt.
Prüfen Sie, dass der angezeigte Herausgebername „XY GmbH“ lautet.
Führen Sie keine EXE-Dateien aus, die per E-Mail-Anhang oder Chat weitergeleitet wurden.
Erscheint eine SmartScreen-Warnung, teilen Sie Ihren Bildschirm mit der IT-Abteilung.

Für Endanwender priorisieren Sie entweder die Verteilung über den Microsoft Store, oder Sie platzieren auf der Download-Seite eine Erklärung zur Herausgeberprüfung.

Was Nutzer im Warnbildschirm tun müssen

Im Hinweismaterial sollte auch stehen, worauf Nutzer tatsächlich klicken müssen. Im SmartScreen-Warndialog ist im Anfangszustand nur die Schaltfläche „Nicht ausführen“ anklickbar. Um die App auszuführen, sind folgende Schritte nötig:

Dialog „Der Computer wurde durch Windows geschützt“
  → „Weitere Informationen“ wählen
  → Der App-Name (Dateiname) und der Herausgeber werden angezeigt
  → Die Schaltfläche „Trotzdem ausführen“ drücken

Auch Microsofts Entwicklerdokumentation erklärt zu unsignierten Dateien, dass man „Trotzdem ausführen“ wählen muss, um die App zu starten. Im Hinweistext sollte man zusätzlich zu diesen zwei Schritten darauf hinweisen, dass der dabei angezeigte Herausgebername mit dem eigenen Unternehmensnamen übereinstimmen muss. Erscheint als Herausgebername „Unbekannter Herausgeber“, bedeutet das, dass die Datei nicht signiert ist oder die Signatur beschädigt ist.

Je nach Unternehmensrichtlinie kann außerdem genau diese Schaltfläche „Trotzdem ausführen“ deaktiviert sein, sodass man nicht weiterkommt. Bei internen Hinweisen sollte auch die Kontaktstelle für diesen Fall angegeben werden.

Anhaltspunkte, bis die Warnung verschwindet

Häufig wird gefragt, „wie viel muss man verteilen, bis die Warnung verschwindet“, aber Microsoft veröffentlicht keinen konkreten Schwellenwert. Die Entwicklerdokumentation erklärt lediglich, dass es keinen exakten Schwellenwert gibt, aber unter Umständen einige Wochen und mehrere hundert saubere Installationen bei breiter Nutzerschaft nötig sind. Ergänzend wird auch Folgendes festgehalten:

• Für Endanwendergeräte gibt es keinen Mechanismus, um eine Datei manuell zur Rufprüfung einzureichen — der Ruf baut sich über die Download-Historie auf
• IT-Administratoren in Unternehmen können Dateien über das Microsoft-Security-Intelligence-Portal einreichen. Bei interner Verteilung oder verwalteten Geräten kann sich dadurch der Vertrauensgewinn beschleunigen
• Signiert man dauerhaft mit demselben Zertifikat, wächst der Ruf des Zertifikats mit, sodass bei neuen Versionen seltener Warnungen erscheinen. Bei unsignierten Dateien beginnt der Aufbau bei jedem Update wieder bei null

Kurz gesagt: Für das Erstrelease sollte man Hinweise unter der Annahme vorbereiten, dass „vorerst Warnungen erscheinen“, und die Verteilung realistischerweise mit unverändertem Zertifikat und Herausgebernamen fortsetzen.

11. Entscheidungsablauf

Bei der Wahl der Verteilungsmethode hilft folgende Reihenfolge, um nicht ins Schwanken zu geraten.

flowchart TD
    A[Eine Windows-App verteilen] --> B{Für Endanwender?}
    B -->|Ja| C{Kann sie in den Microsoft Store?}
    C -->|Ja| D[Store / MSIX bevorzugen]
    C -->|Nein| E[Mit OV-Zertifikat oder Artifact Signing signieren]
    B -->|Nein, intern| F{Gibt es Geräteverwaltung?}
    F -->|Intune/GPO vorhanden| G[Signatur + Zertifikatsverteilung + App-Control-Audit]
    F -->|Keine Verwaltung| H[Feste Verteilungsquelle + Signatur + Nutzerhinweis]
    E --> I[Anfängliche SmartScreen-Warnungen einplanen]
    G --> J[Stufenweiser Rollout ab dem Überwachungsmodus]
    H --> J

Die erste Wahl in der Praxis lässt sich so zusammenfassen:

12. Die Mindest-Checkliste

Checklistenpunkte vor der Veröffentlichung und Verteilung einer Windows-App.

Signatur

• Die EXE ist signiert
• Die DLLs sind signiert
• MSI oder Installer-EXE ist signiert
• Der Updater ist signiert
• Ein Zeitstempel ist gesetzt
• Die Datei wurde nach der Signatur nicht verändert
• Die Prüfung erfolgt mit signtool verify

Verteilung

• Die offizielle Verteilungs-URL ist festgelegt
• Der Herausgebername wird auf der Download-Seite angezeigt
• Versionsnummer und Veröffentlichungsdatum werden angezeigt
• Mit anfänglichen SmartScreen-Warnungen wird gerechnet
• Eine Verteilung über den Microsoft Store wurde geprüft
• Bei Verteilung außerhalb des Stores wurden OV-Zertifikat oder Artifact Signing geprüft

Updates

• Auch Update-Dateien sind signiert
• Bei eigenem Updater sind die Metadaten signiert
• Hash, Größe und Version werden geprüft
• Bei Fehlschlag wird fail-closed abgebrochen
• Ein Rollback-Verfahren existiert

Interne Verteilung

• Das Vorhandensein von Intune / GPO / App Control wurde geprüft
• Die Methode der Zertifikatsverteilung ist festgelegt
• Blockierungsereignisse wurden im Überwachungsmodus geprüft
• Die Zielabteilungen werden für einen stufenweisen Rollout getrennt
• Es wurde geprüft, dass Updates nicht erneut blockiert werden

13. Zusammenfassung

Eine Windows-App ist mit dem Bauen nicht fertig — die verteilte Datei muss aus Sicht von Windows, Nutzern und Unternehmensrichtlinien „in vertrauenswürdiger Form“ vorliegen.

Diese Punkte sollten Sie im Kopf behalten:

• SmartScreen betrachtet den Ruf von Dateien und Herausgebern
• Codesignierung ist notwendig, garantiert aber keine null Warnungen
• EV-Zertifikate nicht zur sofortigen SmartScreen-Umgehung wählen
• Bei allgemeiner Verteilung zuerst Microsoft Store / MSIX in Betracht ziehen
• Bei Verteilung außerhalb des Stores OV-Zertifikate oder Artifact Signing nutzen und anfängliche Warnungen einplanen
• Bei interner Verteilung nicht nur SmartScreen, sondern auch Intune, GPO und App Control betrachten
• Den Updater nicht als Verteilungsfunktion, sondern als Sicherheitsgrenze des Produkts gestalten

Kurz zusammengefasst:

Die Verteilung einer Windows-App ist keine Frage von „wo man sie ablegt“, sondern die Gestaltung von „wie man das Vertrauen von Windows gewinnt“.

Verwandte Artikel

• Leitfaden zur Wahl der Verteilungsmethode für Windows-Apps
• ClickOnce-Einführung: Verteilung, Updates und Auswahlkriterien
• Sicherheitsdesign für automatische Updates
• Mindest-Checkliste für Sicherheit bei der Windows-App-Entwicklung
• Wann sind Windows-Administratorrechte wirklich nötig?
• Grenzen und Praxis der Windows-Einzelbinärverteilung

Referenzlinks

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? - Überblick über Azure Artifact Signing (früher Trusted Signing) und den aktuellen offiziellen Namen.
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum erscheint die Meldung „Der Computer wurde durch Windows geschützt“?

Weil Microsoft Defender SmartScreen die Datei noch nicht als ausreichend vertrauenswürdig einstuft. SmartScreen prüft nicht einfach nur, ob etwas ein Virus ist, sondern betrachtet den Ruf des Herausgebers, den Ruf des Datei-Hashs, das Vorhandensein einer Signatur und den Verteilungsweg. Eine neu erstellte Datei ist aus Sicht von Windows „zum ersten Mal gesehen“ — selbst wenn sie signiert ist, kann eine Warnung erscheinen, solange sich noch kein Ruf aufgebaut hat. Das bedeutet nicht, dass die Datei als Malware eingestuft wurde, wohl aber, dass Windows sie noch nicht für ausreichend vertrauenswürdig hält.

Verschwindet die SmartScreen-Warnung, wenn man den Code signiert?

Nicht zwangsläufig. Codesignierung garantiert im Wesentlichen zwei Dinge: dass die Datei vom angezeigten Herausgeber signiert wurde und dass sie seit der Signierung nicht verändert wurde — eine Garantie für null Warnungen ist das nicht. Auch bei signierten Dateien können Warnungen erscheinen, solange der Ruf der Datei oder des Herausgebers noch nicht ausreicht. Trotzdem ist Codesignierung nahezu unverzichtbar als Grundlage für Verteilung, Updates, Auditierung und den Unternehmenseinsatz. Ohne Signatur können unternehmensseitig App Control, EDR oder Defender die Datei blockieren.

Verschwindet die SmartScreen-Warnung mit einem EV-Zertifikat schon beim ersten Download?

Das ist ein veraltetes Verständnis. Microsofts aktuelle Dokumentation beschreibt kein Verhalten mehr, bei dem EV-Zertifikate die SmartScreen-Warnung beim ersten Download automatisch umgehen — auch mit EV signierte Dateien müssen, genau wie bei OV-Zertifikaten, erst Ruf aufbauen. Ein EV-Zertifikat kann sinnvoll sein, wenn Beschaffungsanforderungen des Unternehmens oder die Sicherheitsprüfung eines Geschäftspartners es verlangen, aber ein EV-Zertifikat allein zur Umgehung von SmartScreen zu kaufen, ist nicht zu empfehlen. Für dieses Ziel sollte man zuerst Verteilungsweg, Signaturmethode und die Möglichkeit einer Store-Verteilung überprüfen.

Wie sollte man verteilen, um SmartScreen-Warnungen zu reduzieren?

Für die breite Verteilung an Endanwender sollte zuerst Microsoft Store / MSIX in Betracht gezogen werden. Ein an den Store übermitteltes MSIX-Paket wird von Microsoft erneut signiert, was der Weg ist, der bei SmartScreen am stabilsten läuft. Ist eine Store-Verteilung nicht möglich, signiert man mit einem OV-Zertifikat oder Azure Artifact Signing und geht davon aus, dass anfänglich Warnungen auftreten können — dabei sollte man den Nutzern die offizielle Download-URL, den Herausgebernamen, die Version und den Hash mitteilen. Bei interner Verteilung braucht es zusätzlich zur Signatur ein Design des Verteilungswegs, das Intune, GPO und App Control einschließt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.