Intune-App-Schutz in Sophos Mobile einrichten und Azure-Zertifikat erneuern

Intune-App-Schutz (MAM) beschränkt geschäftliche Daten in unterstützten Apps anhand der Benutzeridentität. Die Richtlinie gilt beim Geschäftskonto eines zugewiesenen Benutzers, nicht pauschal für dessen private Konten oder das ganze Gerät. Eine Sophos-Mobile-Geräteeinschreibung ist nicht erforderlich. MAM kann auch auf einem bereits verwalteten Gerät eingesetzt werden, ist aber selbst weder Intune-MDM-Einschreibung noch Sophos-Mobile-Geräterichtlinie. Auch der separate Intune-Mobile-Threat-Defense-Connector für Sicherheitsstatus von Sophos Intercept X for Mobile wird damit nicht eingerichtet.

Vor jeder Änderung: Tenant, Berechtigungen und Reichweite

Halten Sie den Sophos-Mobile-Tenant und den vorgesehenen Microsoft-Entra-/Intune-Tenant schriftlich fest. Bestimmen Sie eine berechtigte Sophos-Mobile-Administration, die verantwortliche Microsoft-App-/Intune-Administration und die Person, die eine tenantseitige Zustimmung erteilen darf. Beauftragen Sie die Microsoft-Seite, vor einer Registrierung den tatsächlich angezeigten Anwendungsnamen, Tenant, Application (client) ID, angeforderten API-Berechtigungen mit Berechtigungstyp und Reichweite, Zustimmungsstatus, erforderlichen Rollen und möglichen bestehenden App-Registrierungen zu prüfen und für genau diesen Tenant freizugeben. Sophos verlangt eine Azure-App-Registrierung, Anwendungs-ID, Zertifikatupload und erforderliche Berechtigungen, nennt in der Einrichtungsanleitung aber weder konkrete API-Scopes noch Zustimmungstyp oder erforderliche RBAC-Rollen. Auch bekannte Microsoft-Graph-Berechtigungsnamen sind deshalb keine bestätigten Sophos-Wizard-Anforderungen. Ohne Sichtung und Freigabe der echten Berechtigungsanforderung hier stoppen; keine Rechte auf Verdacht vergeben.
Sophos nennt Microsoft Entra ID P1 oder P2 und eine dem jeweiligen Entra-Konto zugewiesene Intune-Lizenz. Für Outlook müssen ein Exchange-Online-Postfach und eine passende Lizenz, für Word, Excel und PowerPoint eine Microsoft-365-Business- oder -Enterprise-Lizenz am Konto vorhanden sein. Prüfen Sie beim konkreten Abonnement auch das Nutzungsrecht für mobile Office-Apps. Eine sichtbare Sophos-Menüoption ersetzt keine Lizenz- oder Berechtigungsprüfung.
Legen Sie Android oder iOS/iPadOS, eine unterstützte Microsoft-365-App oder andere App mit integriertem Intune App SDK, bereits im Intune-App-Bestand des richtigen Tenants, und eine kleine Microsoft-Entra-ID-Sicherheitsgruppe fest. Dokumentieren Sie Geschäftskonto, Gruppenmitgliedschaft, vorhandene App-Schutzrichtlinien und beabsichtigte geschäftliche Datenwege. Bestehende überlappende Richtlinien und Conditional Access vor dem Pilot auf effektive Wirkung prüfen; nicht voraussetzen, dass die neue Sophos-Richtlinie allein Vorrang erhält.
Vor einem Pilot auf verwalteten Geräten mit der berechtigten Intune-Administration den tatsächlichen Einschreibungstyp, den App-Typ und das Ziel nach Geräteverwaltungsstatus prüfen (alle App-Typen oder gezielt verwaltete/nicht verwaltete Geräte). Bei Android Enterprise nennt Microsoft im Troubleshooting zur Richtlinienbereitstellung für das übliche persönliche Arbeitsprofil-Szenario persönliche Geräte mit Arbeitsprofil; diese Aussage nicht als Ausschluss dokumentierter Shared-Device-Mode-Sonderfälle lesen. Die Microsoft-Übersicht zum App-Schutz dokumentiert App-Schutzrichtlinien auch für Intune-verwaltete Android-Enterprise-Dedicated-Geräte mit Shared Device Mode und benutzerlose AOSP-Geräte mit Shared Device Mode; Dedicated-Geräte ohne diesen Modus sind nicht unterstützt. Bei Shared Device Mode nennt Microsoft eine Ausnahme, wenn PIN für den Zugriff oder Geschäfts-/Schulkonto-Anmeldedaten für den Zugriff erzwungen werden; bei Blockierung während des PIN-Resets muss die betroffene Person über Remove account entsperren. Daraus keine allgemeine Unterstützung anderer Einschreibungstypen oder jeder App-/Einstellungskombination ableiten: konkreten Gerätetyp, App, Einstellung und effektiv angewandte Richtlinie am Pilotgerät prüfen. Werden nur Intune-verwaltete iOS/iPadOS-Geräte adressiert, müssen zusätzlich zur App-Schutzrichtlinie die erforderlichen MDM-App-Konfigurationswerte für die betroffenen Apps wirksam vorliegen: IntuneMAMUPN und IntuneMAMOID für MDM-verwaltete Apps (Intune oder Drittanbieter-EMM), IntuneMAMDeviceID als Geräte-ID-Token für MDM-verwaltete Drittanbieter- und LOB-Apps. Nur DeviceID lässt Intune das Gerät für diesen Schutz als nicht verwaltet einstufen. Vorhandene Werte und wirksame Zuweisung je Pilot-App/-Gerät prüfen, keine Schlüssel oder weitreichende Zielzuweisung auf Verdacht setzen. Eine Sophos-Richtlinienanzeige oder Gruppenmitgliedschaft allein belegt keinen Schutz auf verwalteten Geräten.
Klären Sie die Anmeldevoraussetzungen je Plattform mit der Microsoft-Administration. Auf Android ist die Intune-Unternehmensportal-App für den Empfang der App-Schutzrichtlinie erforderlich. Für Microsoft-365-Apps verlangt Microsoft bei Android-MAM zusätzlich eine Microsoft-Entra-Geräteregistrierung; bei appbasiertem Conditional Access ist die Broker-App ebenfalls zu berücksichtigen. Auf iOS/iPadOS kann Microsoft Authenticator als Broker erforderlich sein. Broker-Installation oder Entra-Geräteregistrierung ist keine Intune-MDM- oder Sophos-Mobile-MDM-Einschreibung. Anmeldung, MFA und Conditional Access im Pilot beobachten statt eine universelle Gerätepflicht zu behaupten.
Für Word, Excel oder PowerPoint einen verwalteten Speicherort über die granulare Save-As-Funktion der Microsoft-Einstellung Save copies of org data vorsehen. Bei OneDrive als Speicherort die OneDrive-App ebenfalls dem Pilotbenutzer per App-Schutzrichtlinie zuweisen und das Geschäfts-/Schulkonto in der Office-App konfigurieren. Eine neue, nicht in einem geschäftlichen Speicherort gesicherte Datei kann als privat gelten; testen Sie mit einer nachweislich geschäftlichen Datei.

Eng begrenzte MAM-Richtlinie erstellen und prüfen

Die folgenden englischen Menünamen stammen aus den Sophos-Anleitungen. Ihre aktuelle Konsole kann anders beschriftet sein; bei Abweichung die tatsächlichen Schritte mit der berechtigten Administration abgleichen und nicht einen ähnlich benannten MDM- oder Threat-Defense-Menüpunkt wählen.

Tenant verbinden und Richtlinie anlegen

In der von Sophos beschriebenen Oberfläche Setup > Sophos setup > Microsoft Azure und Microsoft Azure registration wizard öffnen. Der Assistent führt durch die Registrierung in beiden Portalen: Die berechtigte Microsoft-Administration erstellt im Microsoft-Azure-Portal eine Anwendung für Sophos Mobile. Deren Anwendungs-ID in Sophos Mobile eingeben und mit dem freigegebenen Tenant und der vorgesehenen Anwendung abgleichen. Anschliessend das Sophos-Mobile-Zertifikat in diese Azure-Anwendung hochladen. Angeforderte Berechtigungen mit der vorab genehmigten Liste abgleichen, nur die freigegebenen Berechtigungen gewähren und nur die genehmigte Zustimmung erteilen. Bei Abweichung vor der Rechtevergabe stoppen. Nach Abschluss nennt Sophos Policies > Intune app protection. Das Erscheinen des Menüs beweist weder effektive API-Rechte noch eine aktive Richtlinie.
Policies > Intune app protection öffnen. Beim Öffnen der Richtlinien- und Zuweisungsseiten kann Sophos auf eine Microsoft-Seite zur Authentifizierung weiterleiten. Auf der geprüften Microsoft-Seite meldet sich die berechtigte Administration mit dem vorgesehenen Microsoft-Azure-Administratorkonto für den richtigen Tenant an; dies ist nicht die spätere Anmeldung des Pilotbenutzers in der App. Auf Policies - Intune app protection über Add > Android policy oder Add > iOS policy die passende Pilotrichtlinie anlegen; Sophos verlangt getrennte Richtlinien für Android und iOS/iPadOS. Auf Edit policy die freigegebenen Einstellungen eingeben. App-Datenübertragung, Speichern unter, Zwischenablage, Kontakte und App-Zugriff anhand des Datenflusses freigeben und plattformspezifisch prüfen. Die englischen Sophos-Einstellungsseiten tragen das Datum 22. November 2022, die deutschen 3. März 2025; beide enthalten ältere Bezeichnungen wie Managed Browser. Weder diese Bezeichnung noch das Seitendatum belegt aktuelle Browser-Unterstützung. Datenübertragungen können Ausnahmen haben, und manche iOS-Apps ignorieren Einschränkungen für eingehende Daten. Kein pauschales Versprechen, dass alle Datenwege blockiert sind. Die folgenden Entscheidungen einschliesslich der Offline-Schwellen vor Save mit der berechtigten Intune-Administration festhalten.

Datenwege vor Save festlegen

Die folgenden Auswahlwirkungen sind in den englischen Sophos-Einstellungsseiten vom 22. November 2022 beschrieben. Sie dienen zur Planung des Pilots, nicht als Nachweis heutiger Konsolenfelder oder App-Unterstützung. Jede gewählte Funktion muss zur tatsächlichen Konsole, App und Geräteart passen.

Übertragung nach aussen und Empfang getrennt wählen: Allow app to transfer data to other apps betrifft Ziele, Allow app to receive data from other apps die Herkunft der Daten. Für Android und iOS/iPadOS bedeutet Policy-managed apps jeweils nur andere durch eine Intune-Richtlinie verwaltete Apps; All apps lässt jede App zu, No apps sperrt die jeweilige Richtung. Die dokumentierten Übertragungsausnahmen bleiben zu berücksichtigen; manche iOS-Apps lassen trotz Empfangsbeschränkung alle eingehenden Daten zu. Für iOS/iPadOS beschreibt Sophos bei ausgehender Übertragung mit Policy-managed apps oder No apps zusätzlich eine Sperre der Siri-Suche nach Daten innerhalb der App.
Zwischenablage separat begrenzen: Unter Restrict cut, copy, and paste with other apps sperrt Blocked Ausschneiden, Kopieren und Einfügen zwischen Apps; Policy-managed apps erlaubt dies nur zwischen richtlinienverwalteten Apps. Policy-managed with paste in erlaubt Ausschneiden oder Kopieren nur zwischen diesen Apps, lässt aber Inhalte aus jeder App in die geschützte App einfügen. All apps beschränkt die Zwischenablage in keiner Richtung. Gerade die Paste-in-Variante schützt ausgehende Daten anders als eingehende Inhalte.
Speicherorte als zusammenhängende Entscheidung behandeln: Prevent “Save As” deaktiviert laut Sophos die Save-As-Funktion. Wird diese Option gewählt, bleiben unter Storage locations ausgewählte Ziele für geschäftliche Daten erlaubt, andere Ziele werden gesperrt. Dies ergänzt die oben beschriebene Office-Speicherplanung; die älteren Sophos-Feldnamen sind nicht als identische aktuelle Microsoft-Einstellung Save copies of org data zu verstehen. OneDrive-Zuweisung und Geschäftskonto bleiben Voraussetzungen des entsprechenden Office-Pilots.
Kontaktexport bewusst wählen: Disable contacts sync verhindert laut beiden Plattformseiten, dass die App Daten in der Kontakte-App speichert. Das belegt keine nachträgliche Löschung bereits exportierter Kontakte. Für iOS/iPadOS zusätzlich festhalten, ob Prevent iTunes and iCloud backups App-Datensicherungen zu diesen Zielen verhindern und Disable printing das Drucken in der App unterbinden soll. Nicht pauschal alle Optionen aktivieren; nur die freigegebenen Datenwege prüfen.
iOS/iPadOS-Verschlüsselung einordnen: Encrypt app data verwendet laut Sophos die Geräteverschlüsselung, keine davon unabhängige App-Verschlüsselung. Die Auswahl When device is locked schützt App-Daten im gesperrten Zustand; When device is locked and there are open files nimmt Daten gerade geöffneter Dateien davon aus. When device restart beschreibt den Schutz nach einem Neustart bis zum ersten Entsperren, Use device settings richtet sich nach den Geräteeinstellungen. Die für das Pilotgerät zutreffende Auswahl und ihre Grenzen mit der Administration dokumentieren, keine aktuelle Standardeinstellung unterstellen.

App-Zugriff und Fristen festlegen

Auch hier gelten die beschriebenen Wirkungen der datierten Sophos-Seiten, nicht eine bereits geprüfte Wirkung auf dem Pilotgerät. Zugriffsmethode und Fristen vor dem Speichern freigeben lassen:

PIN oder Geschäftspasswort: Require PIN for access fordert laut Sophos bei der ersten Geschäftskonto-Anmeldung zum Einrichten einer PIN auf. Android-Apps unter Intune-Verwaltung teilen laut Android-Seite dieselbe PIN; bei iPhone und iPad gilt dies nur für Apps desselben Herausgebers. Require corporate credentials for access verlangt stattdessen das Geschäftspasswort und hat Vorrang vor den anderen PIN-Anforderungen. Die oben genannte Shared-Device-Mode-Ausnahme bleibt bestehen; nicht jede Geräteart unterstützt jede Zugriffseinstellung.
Bei iOS/iPadOS-PIN-Nutzung: Unter Password type zwischen Numeric (nur Ziffern) und Passcode (mindestens ein Buchstabe, Sonderzeichen oder Symbol der englischen Tastatur) entscheiden; manche Apps unterstützen Passcode nicht. Mindestlänge, Verbot einfacher PINs, Schwelle fehlgeschlagener Anmeldungen bis zum PIN-Reset und Zulässigkeit von Touch ID/Face ID festhalten. Forbid simple PIN verlangt bei Passcode mindestens eine Ziffer, einen Buchstaben und ein Sonderzeichen oder Symbol. Forbid fingerprint beziehungsweise Forbid facial recognition untersagen laut Quelle Touch ID beziehungsweise Face ID als PIN-Ersatz. Die Reset-Schwelle betrifft einen PIN-Reset, keinen Daten-Wipe; Zahlenwerte und verfügbare biometrische Alternativen müssen zur freigegebenen Pilot-App und zum Testgerät passen; die Quelle liefert keine Standardwerte.
Zugriff erneut prüfen: Access requirements timeout ist ein Zeitraum in Minuten, nach dem die Anforderungen beim App-Start erneut geprüft werden. Innerhalb dieses Zeitraums beschreibt Sophos nach einmaliger PIN-Eingabe eine Nutzung anderer Intune-verwalteter Apps ohne weitere PIN-Eingabe: bei Android plattformweit, bei iOS/iPadOS nur für denselben Herausgeber. Dieser Timer ist weder die Offline-Kulanzfrist noch das Offline-Löschintervall. Den genehmigten Wert und die erwartete erneute Abfrage für die ausgewählte App dokumentieren.
Zulässige Geräte und Versionen: Für iOS/iPadOS festhalten, ob Block managed apps from running on jailbroken devices die Geschäftskonto-Nutzung auf solchen Geräten sperren soll. Erforderliche Mindestversionen für iOS/iPadOS, App und gegebenenfalls Intune-App-Schutz-SDK von empfohlenen Mindestversionen für Betriebssystem und App unterscheiden. Required ist eine Zugangsvoraussetzung, Recommended löst laut Quelle eine wegklickbare Meldung aus; ein leeres Versionsfeld ignoriert diese Bedingung. Falls der Android-Pilot Versionsgrenzen verwendet, gilt diese Unterscheidung dort für Betriebssystem, App und Sicherheitspatch-Stand; das Patch-Datum hat das Format YYYY-MM-DD. Aktivierte und bewusst ungenutzte Grenzen festhalten; konkrete Mindestversionen anhand der freigegebenen Anforderungen und App-Kompatibilität wählen. Die Quelle liefert dafür keine Standardwerte. Eine beobachtete Warnung ist kein Beleg für eine Zugriffssperre.

Offline-Kulanzfrist (Minuten) zur erneuten Zugriffsprüfung vom separat konfigurierbaren Offline-Intervall vor dem Löschen geschäftlicher App-Daten (Tage) unterscheiden: Nach Ablauf der jeweiligen Frist verlangt die App eine Netzwerkverbindung und erneute Authentifizierung. Beim Intervall vor dem Löschen werden nur bei fehlgeschlagener Authentifizierung geschäftliche App-Daten gelöscht. Die tatsächlichen Schwellen im Pilot prüfen, statt eine feste Reihenfolge vorauszusetzen. Die beiden datierten Sophos-Plattformseiten beschreiben für Outlook ausdrücklich, dass beim Löschen der App-Daten auch in der Kontakte-App gespeicherte Daten entfernt werden; dies ist hier nicht mit einer aktuellen App-Version im Tenant getestet. Das ist kein automatischer Geräte-Wipe allein durch Zeitablauf. Destruktive Schwellen und Kontakte-Synchronisierung nur nach Freigabe und mit nicht produktivem Testkonto erproben, nicht an produktiven Kontakten testen.

Speichern, zuweisen und im Pilot prüfen

Die freigegebenen Richtlinienwerte auf Edit policy mit Save speichern. Zurück auf Policies - Intune app protection das blaue Dreieck neben der vorgesehenen Richtlinie öffnen und Assign apps wählen. Nur die vorgesehenen Apps der passenden Plattform auswählen und diese App-Zuweisung mit Save speichern. Die Liste enthält laut Sophos Apps, die dem Microsoft-Intune-Konto bereits hinzugefügt wurden.
Auf derselben Richtlinienliste erneut das blaue Dreieck neben dieser Richtlinie öffnen und Assign user groups wählen. Die Microsoft-Entra-ID-Sicherheitsgruppen getrennt von den Apps zuweisen: Include schliesst Mitglieder ein, Exclude hat auch bei gleichzeitiger Include-Mitgliedschaft Vorrang; Not assigned schliesst Mitglieder nicht aus, die über eine andere Gruppe eingeschlossen sind. Nach Auswahl der Gruppen und ihrer Zustände die Benutzergruppenzuweisung separat mit Save speichern. Nur Mitglieder mit zugewiesener Intune-Lizenz sind betroffen. App-Zuweisung und wirksame Benutzerzuweisung sind beide nötig; weder Sophos-Gerätegruppen noch eine Geräte-MDM-Zuweisung sind hier der Zielmechanismus.
Die gespeicherte Richtlinie sowie App- und Benutzerzuweisung laut Sophos im Microsoft-Azure-Portal ansehen und mit der vorgesehenen Plattform und dem Pilotumfang abgleichen. Bei veralteter Anzeige kann eine erneute Anmeldung am Portal erforderlich sein. Sophos nennt hierfür keinen aktuellen Untermenüpfad; die tatsächliche Portalansicht mit der berechtigten Microsoft-Administration abgleichen. Dann mit einem lizenzierten Pilotkonto die unterstützte App im Geschäftskontext öffnen, Broker-/Anmeldeanforderungen abschliessen und eine nicht destruktive Einschränkung sowie einen geschäftlichen Speicherort beobachten; privates Konto getrennt prüfen. Sind verwaltete Geräte im Zielumfang, den zuvor geprüften Einschreibungstyp, iOS-App-Konfigurationsstatus und die effektiv angewandte App-Schutzrichtlinie am konkreten Pilotgerät in der Ziel-App zusätzlich kontrollieren. Erfassen Sie Tenant, App, Plattform, Konto, Gruppen, Richtlinie und beobachtetes Ergebnis. Eine sichtbare Richtlinie allein ist kein Nachweis für Durchsetzung. Bei Abweichung Rollout stoppen und Berechtigungen/Zustimmung, Zertifikat, Lizenz, App-Unterstützung, Broker/Conditional Access und effektive Gruppenmitgliedschaft prüfen.

Für die nicht destruktive Prüfung ein nicht produktives, lizenziertes Testkonto und eine als geschäftlich erkannte Testdatei verwenden. Vorab das erwartete Ergebnis pro Datenweg notieren:

Übertragung und Kopieren aus der Ziel-App zu einer vorgesehenen richtlinienverwalteten App mit einem nicht freigegebenen privaten Ziel vergleichen. Mit synthetischen Geschäftsdaten testen, nicht mit vertraulichen Produktivdaten. Eingehendes Einfügen separat prüfen, insbesondere bei Policy-managed with paste in und bei iOS-Apps, die Empfangsbeschränkungen ignorieren können.
Die Testdatei an einem erlaubten und einem gemäss Pilotrichtlinie gesperrten Speicherort zu speichern versuchen. Nur eine neue private Datei zu verwenden, wäre kein belastbarer Test des Geschäftsdaten-Schutzes.
Die erwartete erste PIN- oder Passwortabfrage und die erneute Zugriffsprüfung beim App-Start nach dem genehmigten Timeout beobachten. Keine Fehlanmeldungen erzwingen, um einen PIN-Reset auszulösen; er ist laut Quelle die Folge der konfigurierten Fehlversuchsschwelle, nicht der Nachweis einer Datenlöschung. Falls Versionsgrenzen gewählt wurden, Warnung und Zugangsvoraussetzung getrennt bewerten. Geräte nicht eigens rooten oder jailbreaken.
Weitere freigegebene iOS-Datenwege wie Backup, Kontakte oder Drucken nur im vereinbarten Testumfang kontrollieren. Bei unerwartet erlaubtem Datenfluss die betreffende Kombination aus App, Gerät und Richtlinie nicht für den Rollout freigeben; mit der Administration eingrenzen und nach gezielter Korrektur erneut prüfen.

Zertifikat vor Ablauf erneuern

Sophos gibt ein Jahr Gültigkeit für das Microsoft-Azure-Zertifikat der Integration an. Ohne rechtzeitige Erneuerung funktioniert Intune-App-Schutz in Sophos Mobile nicht mehr. Schon der Start der Erneuerung unterbricht laut Sophos die Intune-App-Schutzintegration vorübergehend bis zum Upload des neuen Zertifikats. Ob bereits an Apps zugestellte Richtlinien währenddessen unverändert durchgesetzt werden, ist damit nicht nachgewiesen. Wartungsfenster und verantwortliche Personen für beide Portale festlegen; Tenant, Application (client) ID, alten Fingerabdruck und Ablaufdatum vorab protokollieren. Nicht starten, wenn Upload und unmittelbare Prüfung nicht möglich sind.

Sophos beschreibt für die Erneuerung folgenden Ablauf; auch hier die tatsächlichen Konsolenbeschriftungen vor der Änderung abgleichen:

Fusion > My Products > Mobile > Setup > Sophos setup > Microsoft Azure öffnen. Unter Certificate information > Expiration date das Ablaufdatum prüfen. Renew certificate wählen und den Bestätigungsdialog mit OK bestätigen. Sophos erstellt ein neues Zertifikat und aktualisiert Thumbprint, Start date und Expiration date. Diese Werte protokollieren; sie belegen noch keinen Upload oder eine wiederhergestellte Integration. Über Download certificate die neue Zertifikatdatei herunterladen.
Mit dem freigegebenen Azure-Administratorkonto am Microsoft-Azure-Portal im richtigen Tenant anmelden. Nach App registrations suchen, den Dienst öffnen und die Sophos-Mobile-Anwendung mit derselben Application (client) ID auswählen. Unter Certificates & secrets > Upload certificate genau die neue, aus Sophos Mobile heruntergeladene Datei auswählen und den Upload mit Add abschliessen. Für diese Erneuerung keine neue Anwendung registrieren.
Neuen Fingerabdruck in beiden Portalen vergleichen und Integration sowie eine bestehende Pilotrichtlinie erneut lesen und am Geschäftskonto prüfen. Alten Zertifikatseintrag erst nach dem Fingerabdruckvergleich und einer freigegebenen Funktionsprüfung entfernen: Im Microsoft-Azure-Portal in der bestehenden Sophos-Mobile-Anwendung unter Certificates & secrets über Delete neben dem alten Zertifikat. Nicht die App-Registrierung oder das neue Zertifikat löschen. Bei falscher App-ID, fehlgeschlagenem Upload oder unerwartetem Ausfall den alten Eintrag nicht vorsorglich löschen, Änderung anhalten und eskalieren. Eine automatische Rückkehr zum alten Zertifikat oder eine Wiederherstellung nach Ablauf ist nicht belegt.

Sicherer Rückzug und Freigabestatus

Bei einem fehlgeschlagenen Pilot vorherige Einstellungen und andere Richtlinien festhalten, dann mit den berechtigten Intune-Verantwortlichen nur die Pilot-App oder Pilotgruppe beziehungsweise die problematische Einstellung gezielt zurücknehmen. Effektive Richtlinie und Geschäftskonto erneut prüfen; keine sofortige Wiederherstellung versprechen. Weder Gerät aus MDM entfernen noch Threat-Defense-Connector abschalten. Eine aufgehobene Zuweisung oder entfernte Azure-App-Registrierung ist kein nachgewiesener sofortiger selektiver Daten-Wipe. Das Löschen von Zertifikat oder App-Registrierung reicht über den Pilot hinaus und erfordert eigene Freigabe.

Status: Deutscher redaktioneller Entwurf, ausstehende unabhängige DE-Freigabe. Exakte aktuelle Sophos-Wizard-Scopes, Zustimmung und Rollen sowie tenantseitige Wirkung, Zertifikatswiederherstellung und Datenfolgen sind nicht praktisch verifiziert; keine Freigabe für produktive Änderungen.