Sicherheitsupdate: Microsoft verbannt ActiveX aus Office-Apps

Ende einer Ära: ActiveX verschwindet aus Microsoft 365

Microsoft streicht in Microsoft 365 ab April 2025 die Ausführung von ActiveX‑Steuerelementen. Word, Excel, PowerPoint und Visio lassen die betagten Komponenten ab Version 2504 (Build 18730.20030) nicht mehr starten, ohne die Nutzer zu warnen. Das Ziel ist ein höheres Sicherheitsniveau, weil ActiveX in den vergangenen Jahrzehnten immer wieder zum Einfallstor für Malware wurde. Wer das Risiko bewusst eingehen möchte, kann die Funktion zwar manuell im Trust Center reaktivieren; Administratoren behalten jedoch die Hoheit, diesen Schritt zentral zu unterbinden. Damit endet ein langes Kapitel Windows‑Geschichte.

Historischer Rückblick auf ActiveX

ActiveX entstand Mitte der 1990er‑Jahre als COM‑basierte Erweiterungstechnologie für Windows‑Anwendungen. Sie ermöglichte es Entwicklern, kompilierten Maschinencode in Form sogenannter Controls bereitzustellen, die sich nahtlos in Browser – primär den Internet Explorer – und in Anwendungen wie Visual Basic oder VBA integrieren ließen. Viele Organisationen nutzten ActiveX Data Objects (ADO) für Datenbankzugriffe oder setzten die Technologie ein, um interaktive Formulare in Office‑Dokumenten zu realisieren. In dieser Blütezeit galt ActiveX als Schlüsselkomponente für webbasierte Installationsroutinen, Microsoft‑Updates und sogar Hotmail‑Funktionen.

Doch die starke Integration brachte einen gravierenden Nachteil: Ein Control lief nicht in einer Sandbox, sondern erhielt dieselben Rechte wie die aufrufende Anwendung. Sobald ein Dokument oder eine Webseite ein bösartig präpariertes Control lud, konnte Schadcode praktisch unbegrenzt auf lokale Ressourcen zugreifen. Schon 2003 stellten Sicherheitsforscher fest, dass ein „sicheres ActiveX‑Control“ kaum realisierbar ist.

Warum Microsoft jetzt handelt

Seit mehr als zwanzig Jahren müht sich Microsoft, ActiveX durch verschärfte Dialoge, Kill‑Bits und Richtlinien zu zähmen. Dennoch gelang es Angreifern immer wieder, Anwender zur Aktivierung manipulierter Controls zu verleiten. Die geringe Hemmschwelle lag darin, dass eine harmlose Nachfrage‑Schaltfläche oft reichte, um den Code freizuschalten. In modernen Angriffsszenarien reicht dagegen bereits ein Social‑Engineering‑Trick, um das Opfer zum Öffnen eines Office‑Dokuments zu bewegen. Danach nutzt Schadsoftware die tief verankerte COM‑Architektur, um Dateien zu löschen, Passwörter auszulesen oder Hintertüren einzubauen.

Zusätzlich hat Microsoft mit der Umstellung auf Chromium‑basierte Browser‑Technologien im Edge‑Umfeld kaum noch Gründe, das veraltete Plug‑in‑Modell zu pflegen. Die Abschaltung ist also nicht nur ein Sicherheits‑, sondern auch ein Modernisierungsschritt, der die Pflege von Legacy‑Code reduziert und die Angriffsfläche verringert.

Was ändert sich konkret in Microsoft 365?

Sobald Ihr System das April‑Update erreicht, interpretiert Microsoft 365 sämtliche ActiveX‑Steuerelemente als passives Objekt. Das bedeutet: Das Control bleibt gegebenenfalls als statisches Bild sichtbar, reagiert jedoch nicht mehr auf Klicks oder Skripte. Makros, die auf ActiveX‑Methoden zugreifen, brechen mit einer Laufzeitfehlermeldung ab. Der neue Standard entspricht der bestehenden Gruppenrichtlinie „DisableAllActiveX“; er wird in alle Update‑Kanäle ausgerollt, beginnend mit dem Beta Channel und anschließend im Current Channel.

Wenn Sie Dokumente besitzen, die zwingend auf ActiveX angewiesen sind, müssen Sie in das Trust Center wechseln, die Voreinstellung „Alle Steuerelemente ohne Benachrichtigung deaktivieren“ auf eine weniger restriktive Option setzen und das Dokument erneut öffnen. In verwalteten Umgebungen legen Administratoren diese Option zentral fest, wodurch einzelne Nutzer sie nicht überstimmen können.

Auswirkungen auf Administratoren und Unternehmen

Administratoren stehen vor der Aufgabe, Bestände an Makros, Formularen und Vorlagen zu prüfen, die ActiveX verwenden. Besonders kritisch sind Eigenentwicklungen, die Datenbanken über ADO ansprechen oder spezialisierte Geräte via proprietärer Controls steuern. Die Abschaltung erfordert einen Migrationsplan, weil betroffene Dokumente im schlimmsten Fall Produktionsabläufe blockieren.

Hilfreich ist eine Inventarisierung über Skripte oder Telemetrie, um die Verbreitung von ActiveX‑Objekten in Dateispeichern und SharePoint‑Bibliotheken sichtbar zu machen. Anschließend legen Sie in einer Gruppenrichtlinie fest, ob ActiveX für definierte Übergangsphasen aktiviert bleibt.

Wichtig ist dabei eine klare Kommunikation mit Endanwendern: Nur wer versteht, warum das Feature verschwindet, akzeptiert den Wechsel und meldet auftretende Probleme frühzeitig. Parallel sollten Sie Testumgebungen einrichten, um alternative Technologien wie Office‑Add‑Ins auf Basis von JavaScript zu erproben.

Empfohlene Vorgehensweise für den Übergang

Entwickler und Power‑User sollten bestehende VBA‑Makros auf native Form‑Controls oder modernere Office.js‑Add‑Ins umstellen. Diese Lösungen laufen in einer isolierten Laufzeit und genügen heutigen Sicherheitsanforderungen, ohne Benutzerrechte zu eskalieren. Prüfen Sie zudem, ob veraltete Web‑Anwendungen noch ActiveX‑Download‑Prompts ausliefern; hier bietet sich eine vollständige Ablösung durch HTML5‑ oder Progressive‑Web‑App‑Techniken an. Dokumentieren Sie jede Umstellung transparent, um Audit‑Nachweise zu erhalten.

Für unvermeidbare Ausnahmen empfiehlt sich ein abgestuftes Freigabeverfahren, bei dem ein ActiveX‑Dokument nur innerhalb eines kontrollierten Netzsegments ausgeführt wird. Abschließend sollten Sie Schulungen anbieten, die das Bewusstsein für clientseitige Risiken schärfen und den korrekten Umgang mit Makro‑Sicherheit erläutern. So stellen Sie sicher, dass Ihr Unternehmen von Microsofts Schritt profitiert, ohne die eigene Produktivität zu gefährden.