Microsoft hat in einer Mitteilung mit der Kennung MC1221927 angekündigt, dass Microsoft Defender für Android künftig
keine persönlichen Profile mehr auf registrierten (enrolled) Geräten unterstützen wird – die Änderung wird in der Mitte bis Ende März 2026 ausgerollt und soll sicherstellen, dass sich Defender auf den Schutz der Unternehmens‑ beziehungsweise Arbeitsprofile konzentriert.
Hintergrund / Übersicht
Die Ankündigung MC1221927 wurde von Microsoft am 23. Januar 2026 veröffentlicht und klassifiziert die Änderung als
Major change mit sowohl Nutzer‑ als auch Administrator‑Auswirkungen. Microsoft begründet den Schritt mit einer klaren Fokussierung auf eine
„enterprise‑first security strategy“: Ressourcen sollen primär zum Schutz von Unternehmensdaten im Arbeitsprofil fließen, während persönliche Profile auf registrierten Geräten künftig nicht mehr von Defender überwacht oder weiterentwickelt werden. Der Rollout beginnt Mitte März 2026 und ist Ende März 2026 abgeschlossen.
Diese Entscheidung betrifft speziell Szenarien, in denen Android‑Geräte über MDM‑Richtlinien (z. B. Intune) so verwaltet werden, dass sowohl ein Arbeitsprofil als auch ein persönliches Profil auf einem Gerät vorhanden sind. Funktionen und Schutz für das
Arbeitsprofil und für
nicht registrierte Geräte (unenrolled) bleiben laut Microsoft unverändert.
Warum das wichtig ist: Kurzfassung für IT‑Entscheider
- Was wegfällt: Schutz-, Überwachungs‑ und Feature‑Entwicklung für persönliche (personal) Profile auf registrierten Android‑Geräten.
- Was bleibt: Schutz für Arbeitsprofile (work profiles) und für Geräte, die nicht per MDM registriert sind; Defender‑Funktionen in anderen Plattformen sind nicht betroffen.
- Zeitplan: Rollout Mitte bis Ende März 2026; die Ankündigung erfolgte am 23. Januar 2026.
- Handlungsbedarf: Microsoft gibt an, dass keine administrativen Maßnahmen erforderlich sind — dennoch sollten Organisationen prüfen, ob ihre BYOD‑Strategie, Compliance‑Anforderungen und Erkennungsmechanismen dadurch tangiert werden.
Technischer Kontext: Android‑Profile, MDM und Defender‑Integration
Android Enterprise: Work Profile vs. Personal Profile
Android Enterprise trennt auf vielen Geräten explizit zwischen einem
Work Profile (das Unternehmens‑Apps und -Daten isoliert) und dem
Personal Profile (private Apps, Daten). Diese Trennung ist die Grundlage für BYOD‑Szenarien (Bring Your Own Device), bei denen Unternehmen nur das Arbeitsprofil verwalten und schützen, während das persönliche Profil dem Nutzer gehört.
Microsoft Defender für Endpoint kann in beiden Profilen eingesetzt werden: Administratoren können Defender über Intune in das Arbeitsprofil pushen und — bisher — auch Konfigurationen für die persönliche Umgebung vornehmen. Microsofts Dokumentation erklärt ausführlich die Optionen für die Bereitstellung und die App‑Konfigurationen für Android Enterprise, einschließlich MAM (App Protection Policies) und gerätebasiertem MDM‑Onboarding.
Wie Defender bisher Personal‑Profile adressierte
Administratoren konnten per Intune App‑Konfigurationsrichtlinien das Defender‑Verhalten im persönlichen Profil steuern; Features wie Web‑Protection, Network Protection oder bestimmte Risiko‑Signale ließen sich sowohl für das Arbeits‑ als auch für das persönliche Profil konfigurieren. Microsofts Learn‑Dokumentation beschreibt diese Mechanismen, inklusive details zu optionalen Berechtigungen, VPN‑Setup für Web‑Protection und wie MAM‑basierte Policies (App Protection Policies) verwendet werden, um Defender‑Funktionen in verwalteten Apps zu aktivieren.
Was Microsoft konkret sagt (Kernaussagen aus MC1221927)
- Ende‑März‑2026: Defender für Android endet die Unterstützung für persönliche Profile auf registrierten Geräten; der Fokus liegt danach ausschließlich auf Arbeitsprofilen.
- Kein administrativer Aufwand: Microsoft schreibt, dass keine Administrator‑ oder Benutzeraktionen erforderlich sind; die Änderung werde automatisch „on the back end“ angewendet. Dennoch empfiehlt Microsoft, die eigenen Szenarien zu prüfen.
- Begründung: Schwerpunktverlagerung hin zu Unternehmensschutz und Wahrung der Privatsphäre der Nutzer; Microsoft verweist auf die Plattform‑Trennung als ausreichend, um Unternehmensdaten zu schützen.
Diese Formulierungen hat Microsoft auch in der öffentlichen Nachrichten‑ und Admin‑Berichterstattung aufgegriffen; Fachblogs wie BornCity haben MC1221927 unmittelbar übernommen und zusammengefasst.
Kritische Analyse: Chancen, Stärken und Risiken
Stärken und Chancen
- Konzentration auf Corporate Security: Der Fokus auf das Arbeitsprofil erlaubt es Microsoft, begrenzte Entwicklungs- und Telemetrie‑Ressourcen gezielter für Unternehmensbedrohungen zu verwenden. Das kann Erkennungsqualität und Reaktionsfähigkeit in Unternehmen verbessern.
- Datenschutz für Nutzer: Indem Defender nicht mehr persönliche Profile auf verwalteten Geräten absichert, reduziert Microsoft potentielle Konflikte zwischen Unternehmens‑Telemetrie und persönlicher Privatsphäre, was regulatorisch vorteilhaft sein kann.
- Konsistenz mit Android Enterprise‑Sicherheitsprinzipien: Androids Plattform‑Isolation ist die Basis für diese Entscheidung; Microsoft argumentiert, dass das Arbeitsprofil genügend Schutz bietet, sofern die Umgebung korrekt konfiguriert ist.
Risiken und offene Fragen
- Schattenrisiken für BYOD‑Nutzer: Wenn persönliche Profile nicht mehr von Defender geschützt werden, entsteht eine Lücke im Schutz der privaten Daten und Apps auf registrierten Geräten. Nutzer, die kompromittierte persönliche Apps verwenden, könnten indirekt das Arbeitsprofil gefährden (z. B. über Social‑Engineering‑Angriffe oder Phishing). Microsoft nennt zwar die Plattform‑Trennung, betont aber gleichzeitig, dass aktuelle Forschung Cross‑Profile‑Attacken als minimal bewertet — das ist eine Annahme, die sich ändern kann.
- Compliance‑ und Audit‑Bedenken: Bestimmte Branchen verlangen Auditierbarkeit oder End‑to‑End‑Schutz auch auf Nutzergeräten. Die Abschaltung des persönlichen Profilschutzes könnte hier zusätzliche Kontrollen oder Ausnahmeregeln erforderlich machen.
- Erkennungs‑Blindheit: Teams, die bislang Alerts oder Telemetrie aus persönlichen Profilen zur Kontextanalyse genutzt haben, verlieren diese Datenquelle. Das kann die Incident‑Response erschweren, wenn Angriffe geräteübergreifend stattfinden.
- Kommunikationsaufwand: Microsoft sagt „keine Admin‑Maßnahmen erforderlich“, doch für viele Unternehmen sind Kommunikation, Dokumentation und Policy‑Anpassungen trotzdem nötig — speziell bei BYOD‑Programmen.
Zumindest historisch zeigt die Produktstrategie von Microsoft, dass einzelne Defender‑Funktionen bereits früher eingestellt wurden (z. B. die Privacy‑Protection/VPN‑Komponente der Defender‑App), was für IT‑Teams ein zusätzliches Argument ist, Abhängigkeiten zu prüfen und Alternativen vorzubereiten.
Praktische Auswirkungen: Was Admins jetzt prüfen müssen
Auch wenn Microsoft formal „keinen Handlungsbedarf“ nennt, sollten IT‑Teams systematisch prüfen und Maßnahmen planen. Eine empfohlene Checkliste:
- Prüfen Sie, ob Ihre Organisation Deployments hat, wo Defender in persönlichen Profilen auf registrierten Geräten aktiv ist. (Intune‑App‑Konfigurationsrichtlinien sind der erste Ort.)
- Dokumentieren Sie alle Abhängigkeiten: Werden persönliche‑Profil‑Telemetrie oder Alerts in SOC‑Prozessen genutzt? Gibt es Compliance‑Anforderungen, die persönlichen Schutz voraussetzen?
- Überarbeiten Sie BYOD‑Richtlinien: Entscheiden Sie, ob Sie stattdessen Work‑Profile‑Only‑Strategien, getrennte persönliche Schutzapps oder verpflichtende zusätzliche Schutzlösungen zulassen wollen.
- Schulen Sie Endanwender: Kommunizieren Sie die Änderung klar (Warum? Wann? Welche Auswirkungen hat das für die private Sicherheit?). Nutzer sollten wissen, wie sie persönliche Apps schützen können und welche Tools empfohlen werden.
- Testen Sie Incident‑Response‑Szenarien ohne persönliche Profil‑Telemetry, um sicherzustellen, dass die SOC‑Playbooks weiterhin funktionieren.
- Prüfen Sie, ob MAM‑Policies (App Protection Policies) oder andere Intune‑Konfigurationen bereits so aufgesetzt sind, dass Arbeits‑ und Privatdaten sauber getrennt bleiben.
Konkrete Handlungsempfehlungen — Schritt für Schritt
Für IT‑Administratoren (Priorität: hoch → niedrig)
- Inventarisierung (hoch): Erstellen Sie eine Liste der Nutzer/Gruppen mit Defender‑Onboarding im persönlichen Profil. Verwenden Sie hierzu Intune‑Berichte und die Defender‑Geräteinventarliste.
- Policy‑Review (hoch): Überprüfen Sie App‑Konfigurations‑Policies (Managed Apps vs. Managed Devices) und passen Sie Richtlinien an, damit notwendige Schutzfunktionen im Arbeitsprofil aktiviert sind.
- Kommunikation (mittel): Informieren Sie Endnutzer über die Änderung, geben Sie Empfehlungen für persönliche Schutzapps oder Verhaltensregeln.
- Ersetzen/Ergänzen (mittel): Falls notwendig, bieten Sie eine alternative, vom Unternehmen empfohlene Lösung für persönliches Gerätedispositiv an (z. B. ein kostenpflichtiges Antiviren‑ oder Sicherheitsangebot für Privatnutzung), oder regeln Sie per Policy, dass bestimmte Apps nicht im persönlichen Profil genutzt werden dürfen.
- Monitoring & Tests (hoch): Simulieren Sie Vorfälle, um zu sehen, wie sich die verringerte Telemetrie im persönlichen Profil auf Erkennungs‑ und Reaktionszeiten auswirkt. Passen Sie Playbooks entsprechend an.
- Compliance‑Review (hoch): Prüfen Sie regulatorische Anforderungen (z. B. Datenschutz, Aufbewahrungs‑ und Auditpflichten). Wenn Anforderungen persönlichen Schutz verlangen, planen Sie Ausnahmen oder zusätzliche Kontrollen.
Für Endanwender (Empfehlungen)
- Erhalten Sie Awareness: Nutzen Sie sichere Passwörter, Zwei‑Faktor‑Authentifizierung und vertrauenswürdige App‑Quellen.
- Verwenden Sie für sensible persönliche Aktivitäten vertrauenswürdige Apps mit aktuellem Schutz (z. B. Browser mit Phishing‑Blocker, Passwortmanager).
- Wenn das Unternehmen eine Empfehlung für private Schutzlösungen ausspricht, prüfen und installieren Sie diese freiwillig, wenn Sie möchten.
Mögliche technische Gegenmaßnahmen und Alternativen
- MAM (App Protection Policies): Wenn Geräte das Arbeitsprofil schützen, lassen sich viele Risiken durch strikte App‑Schutzrichtlinien minimieren (Datenexport‑Kontrolle, Kopier‑/Einfügeverbote, Verschlüsselung der App‑Daten). Das reduziert die Angriffsfläche, auch wenn das persönliche Profil ungeschützt bleibt.
- Sicherheits‑Apps für das persönliche Profil: Organisationen können, falls gewünscht, Nutzern kostenfreie oder vergünstigte Drittanbieter‑Sicherheitslösungen anbieten — jedoch ist dabei auf Datenschutz, Nutzerakzeptanz und Support‑Aufwand zu achten.
- Conditional Access + Zero Trust: Stärken Sie Zugriffskontrollen so, dass kompromittierte Geräte oder signifikante Anomalien den Zugriff einschränken, unabhängig von der Profil‑Schutzzone.
- Endpoint Detection and Response (EDR) im Unternehmensnetz: Mehr Kontext im Datacenter kann helfen, Angriffe zu erkennen, auch wenn Endpoint‑Telemetrie reduziert ist.
Warum IT‑Teams trotzdem aufmerksam bleiben sollten
Microsofts Ankündigung ist eindeutig, aber die reale Angriffslandschaft verändert sich ständig. Aussagen wie „aktuelle Forschung zeigt geringe Cross‑Profile‑Risiken“ sind momentbezogen und können sich durch neue Exploits, Android‑Plattformänderungen oder Angreiferstrategien ändern. Organisationen sollten daher:
- die Implementierung beobachten, sobald das Rollout Mitte März 2026 beginnt,
- SOC‑ und MDE‑Teams instruieren, nach unerwarteten Änderungsmustern in der Telemetrie zu suchen,
- und regelmäßig die Microsoft 365 Message Center‑Nachrichten (MC‑IDs) prüfen — MC1221927 ist der direkte Referenzpunkt für diese Änderung.
Kontext: Microsofts Produktstrategie und frühere Rückzüge
Microsoft hat in den letzten Jahren wiederholt Funktionen überprüft und eingestellt, die wenig Adoption oder begrenzten Nutzerwert hatten (ein Beispiel war die Einstellung der Privacy‑Protection/VPN‑Funktion in Defender für Einzelanwender im Jahr 2025). Solche Entscheidungen sind Teil einer Strategie, Produktkomplexität zu reduzieren und Ressourcen auf prioritäre Bereiche zu konzentrieren. Diese historischen Entscheidungen zeigen, warum IT‑Teams Abhängigkeiten von einzelnen „bundled“ Funktionen bewerten sollten, statt sich ausschließlich darauf zu verlassen.
Fazit: Ein strategischer Schritt mit operationalem Anpassungsbedarf
Microsofts MC1221927 ist in technischer Hinsicht ein klarer, begründeter Schritt: Defender für Android richtet sich künftig ausschließlich an die Absicherung von Arbeitsprofilen auf registrierten Geräten. Das hat Vorteile für Unternehmensschutz und Nutzerprivatsphäre, bringt aber auch operative Folgen mit sich — insbesondere für BYOD‑Programme, Compliance‑Anforderungen und SOC‑Abläufe.
IT‑Teams sollten die Ankündigung nicht als rein „passives Ereignis“ behandeln, nur weil Microsoft „keine administrativen Maßnahmen“ fordert. Stattdessen empfiehlt sich ein pragmatischer Ansatz:
- Inventarisieren, dokumentieren und kommunizieren.
- Playbooks und Monitoring‑Sichtbarkeit anpassen.
- BYOD‑Richtlinien und MAM/MDM‑Konfigurationen evaluieren.
- Endnutzer informieren und bei Bedarf alternative Schutzoptionen anbieten.
Die offizielle Nachricht (MC1221927) ist die primäre Referenz für diese Änderung; ergänzende Erläuterungen und Einschätzungen finden sich in Fachblogs wie BornCity und diversen M365‑Aggregatoren. Prüfen Sie die Microsoft‑Dokumentation zur Deployment‑ und App‑Konfiguration für Microsoft Defender für Android, um die passenden technischen Schritte in Intune abzubilden.
Bleiben Sie wachsam: Wenn Ihr Unternehmen stark auf mobile Endgeräte und BYOD setzt, ist jetzt der Zeitpunkt, eine kurze, gezielte Überprüfung Ihrer mobilen Sicherheitsstrategie durchzuführen — bevor die Änderung Mitte März 2026 flächendeckend live geht.
Source: BornCity
MC1221927: Microsoft Defender for Android - Supportende für persönliche Profile