Was das Device-Modul täglich abdeckt
Geräte sind die Endpunkte, an denen Daten konkret leben. Verschlüsselte Notebooks, Compliance-konforme Smartphones, gepatchte Workstations - das ist der Unterschied zwischen einem zertifizierten Setup und einem schlafenden Sicherheitsrisiko. Microsoft Intune bietet die technische Plattform, um das zu erzwingen. Was Intune nicht von selbst tut: Geräte-Hygiene tagesaktuell zusammenfassen, Recovery-Keys einfach auffindbar machen, und Auto-Reports an die IT-Leitung schicken, bevor Probleme eskalieren.
Das Device-Modul von clarios schließt diese operativen Lücken. Es liest Compliance-Status, Device-Inventar, Recovery-Keys und Aktivitäts-Logs aus Entra ID und Intune, korreliert sie zu einem einheitlichen Geräte-Bild und liefert für vier typische Tagesthemen eine konkrete Cockpit-Sicht.
Szenario 1 - Zwölf Notebooks ohne Lebenszeichen seit 90 Tagen
Trigger
12 Notebooks wurden seit 90+ Tagen nicht gesehen.
Der Hintergrund
Stale Devices sind die unscheinbarste, aber häufigste Schwachstelle in mittelständischen M365-Tenants. Mitarbeiter verlassen das Unternehmen, ihr Notebook bleibt in einem Schrank, der HR-Prozess war zwar sauber für Lizenz-Reduktion und Account-Deaktivierung, aber das Gerät selbst wurde nie aus Intune ausgetragen. Nach drei Jahren hat ein typischer Tenant 10 bis 20 Prozent „Geister-Geräte” im Bestand: nicht mehr genutzt, aber technisch noch joined, mit potenziell veralteter Konfiguration und teils erweiterten Zugriffsrechten auf Unternehmensdaten.
Das Problem ist doppelt: Erstens wird die Angriffsfläche unnötig groß (jedes joined Gerät ist potenziell ein Einfallstor, wenn jemand es zurückbekommt und reaktiviert). Zweitens stimmt die Lizenz-Bilanz nicht - Intune-Lizenzen werden für nicht mehr existente Geräte gehalten, was über die Zeit echtes Geld kostet.
Was clarios konkret macht
clarios listet alle Geräte mit letztem Sign-In älter als ein konfigurierbarer Schwellwert (Default: 90 Tage) und reichert sie an mit den verfügbaren Metadaten: Hostname, letzter primärer User, letzter Sign-In-Zeitpunkt, OS-Version, Compliance-Status zum Zeitpunkt der letzten Aktivität. Die Ansicht ist filterbar nach OS, User-Domain und Joined-Type.
Für jedes Gerät bietet der Workflow drei Pfade an: Erstens eine automatisierte Mail an den letzten User („Nutzt du dieses Gerät noch?”), die nach einer Frist als Antwort/Nicht-Antwort gewertet wird. Zweitens eine Disable-Empfehlung mit Audit-Spur, die das Gerät in Intune als „Retired” markiert. Drittens eine Vollarchivierung, die den Recovery-Key gesichert ablegt, bevor das Gerät komplett aus dem Tenant entfernt wird.
Das Ergebnis
Die Angriffsfläche reduziert sich messbar (oft 10 bis 25 Prozent weniger Geräte im aktiven Inventar nach der ersten Bereinigung). Lizenz-Allokation wird sauber. Und Sie haben für jeden Schritt der Bereinigung eine Audit-Spur, die im Schadensfall oder bei einer Versicherungs-Anfrage als Nachweis dient.
Szenario 2 - BitLocker-Recovery in unter 90 Sekunden
Trigger
Mitarbeiter bringt verschlüsseltes Notebook ohne Passwort zurück.
Der Hintergrund
Ein verschlüsseltes Notebook ohne funktionierendes Login-Passwort ist eines der häufigsten Tickets im IT-Support. Mitarbeiter vergisst Passwort nach Urlaub, Profil-Schaden nach Windows-Update, ein PIN-Code wurde dreimal falsch eingegeben und sperrt das TPM - die Ursachen sind banal, die Konsequenz immer dieselbe: ohne BitLocker-Recovery-Key kommt niemand mehr an die Daten.
Der Recovery-Key liegt im Entra-Portal. Theoretisch braucht ein Admin nur drei Minuten, um ihn herauszusuchen. In der Praxis sind es eher fünfzehn bis dreißig Minuten: das Gerät über Hostname identifizieren (manchmal verwechselt mit gleichnamigen Modellen anderer Mitarbeiter), zwei oder drei Portal-Klicks, Recovery-Key kopieren, dem Mitarbeiter telefonisch durchgeben. Und während dieser Zeit steht der Mitarbeiter und sein Tag steht still.
Was clarios konkret macht
Das clarios-Cockpit hat eine Such-Box, die nach Hostname, Seriennummer, Asset-Tag oder primärem User filtert. Innerhalb von Sekunden findet der Admin das richtige Gerät - auch wenn der Mitarbeiter selbst nicht weiß, wie sein Notebook in Intune heißt, aber die Seriennummer vom Aufkleber ablesen kann.
Der Recovery-Key wird direkt im Cockpit angezeigt (klick zur Anzeige, audit-protokolliert: wer hat wann den Key abgerufen, ggf. mit Begründungstext). Die Anzeige ist read-only, der Key bleibt verschlüsselt im Storage. Optional kann der Key direkt aus dem Cockpit an eine vorab definierte interne Adresse gemailt werden - ohne dass der Admin ihn per Hand kopieren und über andere Kanäle weitergeben muss.
Das Ergebnis
Recovery-Vorgang reduziert sich von ~20 Minuten auf ~90 Sekunden. Mitarbeiter ist schneller wieder arbeitsfähig. Audit-Spur ist sauber. Bei späteren Diskussionen („Wer hatte Zugriff auf den Key?”) gibt es eine eindeutige Antwort.
Szenario 3 - LAPS-Rotation ist heimlich stehen geblieben
Trigger
Lokale Admin-Passwörter wurden seit 60+ Tagen nicht rotiert.
Der Hintergrund
LAPS (Local Administrator Password Solution) ist Microsofts Mechanismus, lokale Admin-Passwörter auf Windows-Endgeräten regelmäßig automatisch zu rotieren und sicher in Entra ID zu hinterlegen. Modern, sinnvoll, faktisch unverzichtbar für Geräte-Sicherheit. Wenn es funktioniert.
Wenn es nicht funktioniert, fällt das in der Regel monatelang niemandem auf. Es gibt keine prominente UI-Anzeige im Intune-Portal, die sagt: „Bei diesen 15 Geräten ist die LAPS-Rotation seit zwei Monaten stehen geblieben.” Die Ursachen sind vielfältig: Policy-Konflikt zwischen mehreren Intune-Profilen, Netzwerk-Connectivity-Probleme zwischen Gerät und Entra, GPO-Konflikt in Hybrid-Setups, oder schlicht ein Gerät, das die meiste Zeit offline ist.
Was clarios konkret macht
clarios prüft täglich für jedes Gerät, wann der LAPS-Account zuletzt rotiert wurde, und meldet jedes Gerät, dessen Rotation länger als ein konfigurierbarer Schwellwert (Default: 30 Tage über dem Soll-Intervall) zurückliegt. Für jedes betroffene Gerät versucht clarios eine Ursachen-Analyse: gibt es einen Policy-Konflikt im Intune (zwei Profile setzen widersprüchliche LAPS-Einstellungen)? War das Gerät in den letzten 30 Tagen überhaupt online? Gibt es im Event-Log Fehler-Codes, die auf bekannte LAPS-Probleme hinweisen?
Die Befunde sind nach Kategorie sortiert: „Technischer Konflikt” (braucht IT-Eingriff), „Connectivity” (Gerät zu selten online, evtl. Stale-Device-Kandidat), „Erfolgreich nach Re-Sync” (clarios konnte mit einer Maßnahme die Rotation wieder anstoßen). Für jeden Eintrag ist die nächste sinnvolle Aktion verlinkt.
Das Ergebnis
LAPS-Rotation bleibt mess- und nachweisbar. In Audit-Situationen können Sie konkret zeigen: 98 Prozent der Geräte haben in den letzten 30 Tagen rotiert, die übrigen 2 Prozent sind als „bewusst akzeptiert” oder „in Bearbeitung” dokumentiert. Cyber-Versicherer und Auditoren akzeptieren das in der Regel als gut implementiertes LAPS-Setup.
Szenario 4 - Acht Geräte „Not Compliant” - und niemand merkt es
Trigger
8 Geräte sind „Not Compliant” in Intune, aber niemand merkt’s.
Der Hintergrund
Intune-Compliance-Status ist eine binäre Aussage pro Gerät: compliant oder not compliant. Was als „compliant” gilt, definieren Sie über Compliance-Policies (Mindest-OS-Version, BitLocker-Status, definierte Sicherheits-Einstellungen, etc.). Der Status fließt in Conditional Access ein - non-compliant Devices können beispielsweise vom Zugriff auf Unternehmensdaten ausgeschlossen werden.
Das Problem in der Praxis: Compliance-Status ändert sich kontinuierlich, oft aus Gründen, die mit Sicherheit wenig zu tun haben. Ein Geräte-Reset, ein OS-Upgrade, eine vorübergehende Netzwerk-Trennung - und plötzlich ist ein Gerät als „Not Compliant” gelistet, ohne dass das ein echtes Sicherheitsrisiko wäre. Wenn niemand regelmäßig hinschaut, sammelt sich über Wochen ein zweistelliger Wert an Non-Compliance-Findings an, die zwar als kosmetisches Problem starten, aber irgendwann in einer Compliance-Drift münden, die im Audit auffällt.
Was clarios konkret macht
clarios generiert wöchentlich (oder in einem von Ihnen definierten Rhythmus) einen Auto-Report an die hinterlegten Empfänger - typischerweise IT-Leitung und Geschäftsführung. Der Report listet alle non-compliant Devices, gruppiert nach Compliance-Reason (z.B. „Encryption Off”, „OS-Version below minimum”), und zeigt den Trend der letzten vier Wochen.
Zusätzlich definieren Sie Schwellwerte für Eskalation: „Wenn mehr als 5 Prozent der Geräte über 7 Tage non-compliant sind, geht eine SMS an die IT-Leitung.” Solche Eskalations-Regeln sind im Cockpit konfigurierbar und werden als Teil der NIS2-Dokumentation versioniert.
Für jede Compliance-Reason gibt es Lösungsvorschläge: „Encryption Off” wird mit einem Link auf das Intune-Profil verbunden, das BitLocker konfiguriert. „OS below minimum” wird mit der nächsten geplanten Update-Welle verknüpft.
Das Ergebnis
Compliance-Drift wird sichtbar, lange bevor sie zum Problem wird. Reports an die Geschäftsführung schaffen Aufmerksamkeit für Geräte-Hygiene als Dauerthema, nicht als sporadisches Audit-Vorbereitungs-Sprint. Bei NIS2-Berichtspflichten haben Sie einen versionierten Compliance-Verlauf, der zeigt: wir arbeiten kontinuierlich an Geräte-Sicherheit, nicht erst wenn der Auditor klingelt.