BYOD und Zugriff für Auftragnehmer: Absicherung nicht verwalteter Geräte über den Browser

Ein Beratungsunternehmen benötigt 200 freiberufliche Mitarbeiter, die für einen sechsmonatigen Einsatz Zugriff auf interne SharePoint- und Salesforce-Systeme erhalten sollen. Auf deren privaten Laptops lassen sich keine Endpunkt-Agenten installieren, eine MDM-Registrierung kommt für Geräte, die die freiberuflichen Mitarbeiter auch für Online-Banking und Familienfotos nutzen, nicht in Frage, und die Einrichtung einer VDI-Umgebung für eine vorübergehende Nutzergruppe würde das Projektbudget sprengen. Der Browser – die Anwendung, die auf jedem dieser Laptops bereits geöffnet ist – ist der praktischste Ansatzpunkt, der Ihnen zur Verfügung steht. Dieser Leitfaden führt Sicherheitsverantwortliche durch einen schrittweisen Ansatz zur Absicherung des BYOD- und Auftragnehmerzugriffs mittels browserbasierter Kontrollen, von den Voraussetzungen bis hin zu messbaren Erfolgskriterien.

Voraussetzungen: Was Sie benötigen, bevor Sie beginnen

Bevor Sie browserbasierte Zugriffskontrollen für BYOD- und Auftragnehmer-Benutzer konfigurieren, stellen Sie sicher, dass diese Grundlagen vorhanden sind. Das Überspringen dieser Schritte ist der häufigste Grund für ins Stocken geratene Implementierungen.

Die Identitätsinfrastruktur muss externe Benutzer unterstützen. Ihr IdP muss föderierte Identitäten nicht nur für Mitarbeiter, sondern auch für Auftragnehmer verarbeiten können. Stellen Sie sich folgendes Szenario in einer Beratungsfirma vor: Der Projektmanager sendet an einem Montag Onboarding-Anweisungen an 200 Auftragnehmer. Wenn Ihr IdP keine bereichsbezogenen, zeitlich begrenzten Identitäten ausstellen kann, die an eine externe Domäne gebunden sind, werden Sie diese Woche damit verbringen, Konten manuell einzurichten – und vergessen, diese nach Beendigung des Auftrags wieder zu deaktivieren. NIST SP 800-46 Rev. 2 befasst sich ausdrücklich mit den Sicherheitsanforderungen für BYOD sowie für von Auftragnehmern, Geschäftspartnern und Lieferanten kontrollierte Client-Geräte und betont dabei die Bedeutung der Sicherung sensibler Informationen, die auf diesen Geräten gespeichert sind und über diese übertragen werden.

Anwendungsbestandsaufnahme nach Zugriffsmethode. Erstellen Sie eine Übersicht darüber, welche Anwendungen Auftragnehmer benötigen, unabhängig davon, ob es sich um SaaS-Anwendungen (zugänglich über Forward- oder Reverse-Proxy), interne Webanwendungen (zugänglich über ZTNA) oder ältere Thick-Client-Anwendungen (für die möglicherweise weiterhin VDI erforderlich ist) handelt. Die meisten Arbeitsabläufe von Auftragnehmern sind SaaS-zentriert – SharePoint, Salesforce, ServiceNow –, was eine browserbasierte Durchsetzung für die Mehrheit der Sitzungen praktikabel macht.

Datenklassifizierung für die Zuordnung von DLP-Richtlinien. Wenn Sie nicht festgelegt haben, welche Daten in den Anwendungen, auf die Auftragnehmer zugreifen, als sensibel gelten, werden DLP-Richtlinien entweder zu viele Daten blockieren oder gar nichts erfassen. Legen Sie zumindest Richtlinienauslöser für personenbezogene Daten, Finanzdaten und geistiges Eigentum fest.

Entscheidung zur Netzwerkarchitektur. NIST SP 800-46 empfiehlt Organisationen, den Einsatz von Lösungen zur Netzwerkzugangskontrolle in Betracht zu ziehen, die den Sicherheitsstatus eines Client-Geräts überprüfen, bevor diesem die Nutzung eines internen Netzwerks gestattet wird, sowie die Nutzung eines separaten Netzwerks für alle externen Client-Geräte, einschließlich BYOD-Geräten und von Dritten kontrollierten Geräten, in Betracht zu ziehen. Für den browserbasierten Zugriff bedeutet dies, den gesamten Datenverkehr von nicht verwalteten Geräten über Ihre SSE-Plattform zu leiten, anstatt direkten Netzwerkzugang zu gewähren.

Phase 1: Schaffung von Transparenz und Festlegung von Basisrichtlinien mithilfe von CASB und SWG

Beginnen Sie damit, die grundlegendste Frage zu beantworten: Was machen nicht verwaltete Geräte heute eigentlich in Ihren SaaS-Anwendungen?

Setzen Sie CASB im Reverse-Proxy-Modus ein, um Sitzungen von nicht verwalteten Geräten abzufangen, die auf genehmigte SaaS-Anwendungen zugreifen. Ein Reverse-Proxy erfordert keinen Agenten – der Auftragnehmer authentifiziert sich lediglich über Ihren IdP und wird transparent über den CASB-Durchsetzungspunkt weitergeleitet. Im Szenario der Beratungsfirma erkennt der CASB, wenn sich ein Auftragnehmer von einem privaten MacBook aus bei Salesforce anmeldet, die Sitzung, stuft das Gerät aufgrund des fehlenden Client-Zertifikats als nicht verwaltet ein und wendet Ihre Richtlinie für nicht verwaltete Geräte an: Lesezugriff auf Opportunity-Datensätze, kein Massenexport und Wasserzeichen auf Bildschirmdarstellungen.

Leiten Sie gleichzeitig den Webdatenverkehr dieser Benutzer über Ihr SWG, um Richtlinien zur akzeptablen Nutzung durchzusetzen, den Zugriff auf risikoreiche Kategorien zu blockieren und Downloads auf Malware zu überprüfen. Das SWG ist Ihre erste Verteidigungslinie gegen einen Auftragnehmer, der in einem privaten E-Mail-Tab auf einen Phishing-Link klickt, während er gleichzeitig bei Ihrem unternehmensinternen SharePoint angemeldet ist.

Was in dieser Phase gemessen werden sollte:

Anzahl der täglich erkannten Sitzungen auf nicht verwalteten Geräten

SaaS-Anwendungen, auf die über nicht verwaltete Geräte zugegriffen wird (Erkennung von „Shadow-SaaS“)

Verstöße gegen die Richtlinien wurden blockiert (Massen-Downloads, unbefugter Zugriff auf Apps)

Durchschnittliche Zeit vom Antrag auf Einbindung eines Auftragnehmers bis zum produktiven Zugriff

Diese Phase liefert Ihnen die Telemetriedaten, mit denen Sie Investitionen in nachfolgende Phasen begründen können. Sollte Ihr CASB aufdecken, dass Auftragnehmer jede Woche Kundenlisten auf ihre privaten Geräte herunterladen, ergibt sich der Business Case für Phase 2 von selbst.

Phase 2: Einführung Remote Browser Isolation besonders sensible Sitzungen

Sobald die Transparenz hergestellt ist, besteht der nächste Schritt darin, den Endpunkt als Bedrohungsvektor für Ihre sensibelsten Anwendungen vollständig zu eliminieren. Hier kommt remote browser isolation zur wirksamsten Kontrollmaßnahme für nicht verwaltete Geräte wird.

Betrachten Sie ein praktisches Szenario: Ein Auftragnehmer in der Beratungsfirma muss Kundendaten in Salesforce einsehen, die personenbezogene Daten enthalten – Namen, Adressen, Geschäftswerte. Mit RBI läuft die Salesforce-Sitzung in einem cloudbasierten Container. Der Auftragnehmer sieht die Anwendung und interagiert mit ihr wie gewohnt in seinem Chrome- oder Safari-Browser, doch keine Anwendungsdaten, Sitzungstoken oder Seiteninhalte gelangen jemals auf das lokale Gerät. Sollte der private Laptop des Auftragnehmers mit einem Keylogger oder einem Info-Stealer infiziert sein, kann die Malware nichts Brauchbares erfassen, da die Sitzung niemals lokal ausgeführt wird.

RBI ermöglicht zudem eine detaillierte Datenkontrolle innerhalb der isolierten Sitzung. Sie können das Kopieren und Einfügen deaktivieren, das Drucken blockieren, das Herunterladen von Dateien verhindern und dynamische Wasserzeichen anwenden, die die Identität des Benutzers in Screenshots einbetten. Nach Beendigung der Sitzung wird der Container gelöscht, sodass auf dem nicht verwalteten Gerät keinerlei Datenrückstände zurückbleiben.

Dieser Ansatz steht in direktem Einklang mit den Zero-Trust-Prinzipien. In der NIST-Richtlinie SP 800-207 wird ausdrücklich anerkannt, dass Geräte im Netzwerk möglicherweise nicht im Besitz des Unternehmens sind oder von diesem konfiguriert werden können und dass vertraglich vereinbarte Dienste auch Ressourcen umfassen können, die nicht dem Unternehmen gehören und die für die Erfüllung ihrer Aufgaben Netzwerkzugang benötigen. RBI ist die praktische Umsetzung dieses Grundsatzes: Sie gewähren Anwendungen Zugriff, ohne dem Gerät zu vertrauen.

Wann sollte man RBI anstelle eines Standard-CASB-Proxys einsetzen:

Wann sollte man RBI anstelle eines Standard-CASB-Proxys einsetzen?

Phase 3: Erweiterung von ZTNA auf private Anwendungen

SaaS-Anwendungen sind nur ein Teil des Gesamtbildes. Bei vielen Aufträgen für Auftragnehmer ist der Zugriff auf interne Webanwendungen erforderlich – maßgeschneiderte Portale, interne Wikis, Entwicklungsumgebungen –, die nicht mit dem Internet verbunden sind.

Ein herkömmliches VPN gewährt Auftragnehmern einen Tunnel auf Netzwerkebene in Ihre Umgebung, was gegen jeden Grundsatz des Zero-Trust-Konzepts verstößt. Sollte einer dieser 200 Auftragnehmer Malware auf seinem privaten Laptop haben und Sie ihm VPN-Zugriff gewährt haben, kann die Malware Ihr internes Netzwerk scannen, seitliche Ausbreitung versuchen und Systeme erreichen, die weit über den vorgesehenen Zugriffsbereich des Auftragnehmers hinausgehen.

ZTNA / Private Access das VPN durch einen Zugriff auf Anwendungsebene. Der Auftragnehmer authentifiziert sich, die Policy-Engine bewertet seine Identität, den Gerätekontext und die Risikosignale und gewährt ihm ausschließlich Zugriff auf die spezifischen internen Anwendungen, die für seine Rolle autorisiert sind – und auf nichts anderes. Der Auftragnehmer sieht das zugrunde liegende Netzwerk zu keinem Zeitpunkt und greift auch nicht darauf zu.

Die Reifegrade des CISA Zero-Trust-Reifegradmodells ermöglichen es Organisationen, die Investitionen zu bewerten, zu planen und aufrechtzuerhalten, die erforderlich sind, um auf dem Weg zum Zero-Trust-Ansatz in fünf Säulen voranzukommen: Identität, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten. Der Wechsel von VPN zu ZTNA für den Zugriff von Auftragnehmern stellt sowohl in der Säule „Geräte“ als auch in der Säule „Netzwerke“ einen messbaren Schritt vom Reifegrad „Traditionell“ zum Reifegrad „Anfänglich“ dar.

Im Szenario der Beratungsfirma bedeutet ZTNA, dass die Auftragnehmerin Jane von ihrem privaten Laptop zu Hause aus auf das interne Projektverfolgungsportal zugreifen kann, jedoch weder das Netzwerk scannen noch den Domänencontroller erreichen noch auf die Finanzanwendung zugreifen kann. Wenn ihr Auftrag am Freitag endet, wird ihr Zugriff auf Anwendungsebene widerrufen – es müssen keine VPN-Zertifikate zurückverfolgt und keine Firewall-Regeln bereinigt werden.

Warum VDI und MDM für BYOD und den Zugriff von Auftragnehmern nicht ausreichen

Sicherheitsverantwortliche prüfen häufig zunächst VDI- und MDM-Lösungen, bevor sie browserbasierte Kontrollmaßnahmen in Betracht ziehen. Beide Lösungen haben berechtigte Anwendungsfälle, doch keine von beiden eignet sich gut für vorübergehend eingesetzte, große Bestände an nicht verwalteten Geräten.

VDI (Virtual Desktop Infrastructure): VDI schafft eine zentralisierte Desktop-Umgebung auf einem Server und überträgt eine visuelle Sitzung auf das Gerät des Benutzers. Diese Lösung eignet sich hervorragend für stark regulierte Umgebungen, in denen Thick-Client-Anwendungen erforderlich sind. Für 200 Auftragnehmer, die sechs Monate lang auf SaaS-Anwendungen zugreifen, ist VDI jedoch überdimensioniert. Cloud-basierte VDI-Lösungen kosten in der Regel mehrere Dutzend Dollar pro Benutzer und Monat, und eine lokal betriebene VDI erfordert erhebliche Investitionen in Server, Netzwerkausrüstung und Virtualisierungssoftware. Bei einem Projekt mit 200 Auftragnehmern können allein die Gesamtkosten für das VDI-Abonnement über sechs Monate mehrere Zehntausend Dollar erreichen – noch bevor Infrastruktur-, Lizenz- und Supportkosten berücksichtigt werden. Darüber hinaus führt VDI zu Latenzzeiten, Sitzungsunterbrechungen und langen Einarbeitungszeiten, was die Benutzer frustriert und die Produktivität mindert.

MDM (Mobile Device Management): MDM erfordert die Installation eines Verwaltungsprofils auf dem privaten Gerät des Auftragnehmers, wodurch das Unternehmen die Kontrolle über die Geräteeinstellungen, die Möglichkeit zur Fernlöschung von Daten sowie Einblick in die installierten Anwendungen erhält. Die meisten Auftragnehmer werden dies ablehnen. Ihr Gerät ist ihr persönliches Eigentum; sie nutzen es für Bankgeschäfte, private E-Mails und Familienfotos. Die Aufforderung an einen Auftragnehmer, sich bei MDM anzumelden, führt zu rechtlichen Konflikten, Einwänden hinsichtlich des Datenschutzes und verzögert die Einarbeitung um Tage oder Wochen.

Browserbasierte Kontrollmechanismen (CASB + RBI + SWG + ZTNA): Keine Agenten, keine Geräteregistrierung, keine zu skalierende Infrastruktur. Der Auftragnehmer öffnet seinen Browser, authentifiziert sich über Ihren IdP, und die Sicherheitsrichtlinien werden auf der Sitzungsebene durchgesetzt. Die Einrichtungszeit verkürzt sich von Tagen auf Minuten. Der BYOD-Sicherheitsmarkt spiegelt diesen Wandel wider: Der Markt wurde im Jahr 2025 auf 60,64 Milliarden US-Dollar geschätzt und soll bis 2032 bei einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von 10,28 % 120,36 Milliarden US-Dollar erreichen (GII Research, 2026).

Tabelle 2: VDI im Vergleich zu MDM und browserbasierten Kontrollmechanismen

Integrationspunkte: So lassen Sie die Browsersicherheit mit Ihrer bestehenden Infrastruktur zusammenarbeiten

Browserbasierte BYOD-Kontrollmaßnahmen funktionieren nicht isoliert. Ihr Nutzen vervielfacht sich, wenn sie in Ihre bestehende Sicherheitsinfrastruktur integriert werden.

IdP und bedingter Zugriff: Ihr IdP (Azure AD, Okta, Ping) fungiert als Gatekeeper. Konfigurieren Sie Richtlinien für den bedingten Zugriff, die nicht verwaltete Geräte erkennen – in der Regel anhand des Fehlens eines Client-Zertifikats oder eines Konformitätssignals – und leiten Sie diese Sitzungen automatisch über den CASB-Reverse-Proxy oder RBI weiter. Wenn sich ein Auftragnehmer von einem nicht registrierten Gerät aus bei SharePoint anmeldet, sollte der IdP automatisch den strengeren Zugriffspfad durchsetzen, ohne dass ein manueller Eingriff erforderlich ist.

Vereinheitlichung der DLP-Richtlinien: Dieselben DLP-Richtlinien, die Daten auf verwalteten Endgeräten schützen, sollten auch für Browsersitzungen von nicht verwalteten Geräten gelten. Wenn Ihre DLP-Richtlinie den Massenexport von Kundendatensätzen durch Mitarbeiter blockiert, muss sie diesen auch für Auftragnehmer blockieren, die über RBI darauf zugreifen. Der IBM-Bericht „Cost of a Data Breach“ (2024) beziffert das Risiko: Die weltweiten Durchschnittskosten einer Datenpanne beliefen sich im Jahr 2024 auf 4,88 Millionen US-Dollar – ein Anstieg von 10 % gegenüber dem Vorjahr und der stärkste Anstieg seit Beginn der Pandemie. Eine konsequente Durchsetzung der DLP-Richtlinien bei verwaltetem und nicht verwaltetem Zugriff verringert die Wahrscheinlichkeit, Teil dieser Statistik zu werden.

SIEM- und UEBA-Integration: Leiten Sie Sitzungsprotokolle aus CASB, RBI und ZTNA in Ihr SIEM weiter, um Verhaltens-Baselines für die Aktivitäten von Auftragnehmern zu erstellen. Wenn ein Auftragnehmer, der normalerweise täglich auf 20 Salesforce-Datensätze zugreift, plötzlich 2.000 exportiert, sollte diese Anomalie einen Alarm auslösen. Transparenz und Analytik sind eine der drei übergreifenden Fähigkeiten im CISA Zero-Trust-Reifegradmodell, und die Telemetrie auf Sitzungsebene aus Browserkontrollen stellt eine praktische Umsetzung dieser Fähigkeit dar.

Automatisierung des Offboardings: Wenn das Vertragsverhältnis mit einem Auftragnehmer endet, deaktivieren Sie dessen IdP-Identität. Da der Zugriff sitzungsbasiert ist und auf der Proxy- oder RBI-Ebene durchgesetzt wird, müssen keine VPN-Zertifikate widerrufen, keine Endpunkt-Agenten deinstalliert und keine Geräteprofile entfernt werden. Der Zugriff besteht einfach nicht mehr.

Kennzahlen und Erfolgskriterien

Messen Sie, worauf es ankommt. Diese Kennzahlen zeigen, ob Ihre browserbasierten BYOD- und Zugriffskontrollen für Auftragnehmer funktionieren und weitere Investitionen rechtfertigen.

Betriebskennzahlen:

Durchschnittliche Zeit bis zur Zugangsgewährung für Auftragnehmer: Von der Identitätsbereitstellung bis zur ersten produktiven Sitzung. Ziel: unter 30 Minuten. Sollten Sie diesen Wert in Tagen messen, muss der Prozess optimiert werden.

Anzahl der Sitzungen von nicht verwalteten Geräten: Gesamtzahl der Sitzungen pro Woche von Geräten, die als nicht verwaltet eingestuft wurden. Mit zunehmender Verbreitung ist ein Aufwärtstrend zu erwarten; ein Abwärtstrend bei gleichbleibender Anzahl von Auftragnehmern deutet auf eine Umgehung hin.

Rate der Richtlinienverstöße: Anzahl der blockierten Aktionen (Downloads, Kopieren und Einfügen, unbefugter Zugriff auf Apps) pro 1.000 Sitzungen. Eine anhaltend hohe Rate kann darauf hindeuten, dass die Richtlinien zu restriktiv sind oder dass die Kommunikation mit den Nutzern unzureichend ist.

Sicherheitskennzahlen:

Vorfälle ohne Datenrückstände: Anzahl der Vorfälle, bei denen Daten offengelegt wurden und die auf ein nicht verwaltetes Gerät zurückgeführt werden können. Das Ziel liegt bei null für RBI-geschützte Sitzungen.

Erkennungsrate für „Shadow SaaS“: Anzahl der nicht genehmigten SaaS-Anwendungen, auf die von nicht verwalteten Geräten aus zugegriffen wird und die von CASB erkannt wurden. Diese Kennzahl sollte im Laufe der Zeit sinken, wenn Sie die SWG-Richtlinien verschärfen.

Vorfälle von Zugangsdaten-Diebstahl durch nicht verwaltete Geräte: Angriffe unter Verwendung von Zugangsdaten machten 16 % aller Sicherheitsverletzungen aus und dauerten mit fast 292 Tagen am längsten, bis sie erkannt und eingedämmt werden konnten (IBM, 2024). Die Sitzungsisolierung von RBI dürfte den Diebstahl von Zugangsdaten durch browserbasierte Angriffe nahezu auf Null reduzieren.

Kostenkennzahlen:

Kosten pro Benutzerzugang: Vergleichen Sie die Gesamtkosten für SSE-Lizenzen bei nicht verwalteten Gerätesitzungen mit den entsprechenden VDI-Kosten. Die Differenz dient Ihnen als Begründung für die Verlängerung.

Helpdesk-Ticketvolumen im Zusammenhang mit dem Zugriff von Auftragnehmern: Browserbasierte Steuerungslösungen sollten weniger Support-Tickets verursachen als VDI oder MDM, da keine Client-Software vorhanden ist, bei der Fehler behoben werden müssen.

Häufige Fehler

Alle nicht verwalteten Geräte gleich behandeln. Ein Auftragnehmer, der auf nicht sensible Projektunterlagen zugreift, benötigt nicht dieselben Sicherheitsmaßnahmen wie einer, der mit personenbezogenen Daten von Kunden umgeht. Die übermäßige Anwendung von RBI auf jede Sitzung erhöht die Kosten und die Latenz. Setzen Sie eine risikobasierte Abstufung ein: CASB-Proxy für Anwendungen mit geringer Sensibilität, RBI für Anwendungen mit hoher Sensibilität.

Das Problem der Datenübertragung zwischen Anwendungen wird dabei oft außer Acht gelassen. Sie haben den Zugriff auf Salesforce mit RBI eingeschränkt, doch der Auftragnehmer kann weiterhin einen Kundennamen aus Salesforce kopieren, ihn in ein generatives KI-Tool in einem benachbarten Tab einfügen und eine Antwort erhalten, die angereicherte Daten enthält. Kombinieren Sie RBI mit SWG-Richtlinien, die den Zugriff auf generative KI-Tools von nicht verwalteten Gerätesitzungen aus einschränken – oder leiten Sie den Zugriff auf KI-Tools ebenfalls über eine Isolationsumgebung um. Skyhigh beschreibt in seinen Leitlinien zum Schutz von Cloud-Anwendungen vor nicht verwalteten Geräten weitere Kontrollmaßnahmen für dieses Szenario.

Der Offboarding-Prozess wird übersprungen. Die Bereitstellung steht im Mittelpunkt der Aufmerksamkeit; die Entziehung der Zugriffsrechte wird nur mit einem Haftnotizzettel vermerkt. Automatisieren Sie Offboarding-Auslöser, die an die Enddaten der Beschäftigungsverhältnisse in Ihrem Personal- oder Beschaffungssystem gekoppelt sind. Ein Auftragnehmer, der drei Monate nach Projektende weiterhin Zugriffsrechte besitzt, stellt eine interne Bedrohung dar – unabhängig davon, ob dies beabsichtigt ist oder nicht.

Ignorieren der Kommunikation mit den Nutzern. Auftragnehmer, die zum ersten Mal mit RBI in Berührung kommen, berichten möglicherweise, dass sich „die Anwendung anders anfühlt“ oder dass das Kopieren und Einfügen nicht funktioniert. Ohne proaktive Kommunikation, in der erklärt wird, warum diese Kontrollen bestehen und welche Verhaltensweisen sie einschränken, kommt es zu inoffiziellen Umgehungslösungen – beispielsweise senden Auftragnehmer Daten per E-Mail an private Konten, um Download-Beschränkungen zu umgehen.

Bereitstellung von Browser-Kontrollen ohne DLP. Browser-Isolation ohne data loss prevention eine verschlossene Tür mit offenem Fenster. RBI verhindert, dass Daten auf das Gerät gelangen, doch DLP stellt sicher, dass Daten innerhalb der Sitzung nicht über genehmigte Kanäle abgezogen werden können – etwa durch Hochladen in einen privaten Cloud-Speicher, Versenden per E-Mail an eine nicht unternehmensinterne Adresse oder Ausdrucken als lokale PDF-Datei. IBM stellte fest, dass 35 % der Sicherheitsvorfälle „Schattendaten“ betrafen – also Informationen, die in nicht verwalteten Datenquellen gespeichert waren (IBM, 2024) –, was verdeutlicht, wie unkontrollierte Datenbewegungen Kosten und Risiken verursachen.

Die Annahme, dass ein einziges Bereitstellungsmodell für alle geeignet ist. Bestimmte Nutzergruppen könnten von einer schlanken Browsererweiterung auf verwalteten Geräten profitieren, während externe Mitarbeiter agentenloses RBI nutzen. Passen Sie die Kontrollmaßnahmen an den Gerätestatus und den Nutzertyp an, anstatt einen einheitlichen Ansatz für Ihre gesamte Belegschaft vorzuschreiben.