BYOD-Onboarding: So richten Sie den Zugriff für Mitarbeiter und Gäste ein

Ein neuer Mitarbeiter trifft mit einem privaten Telefon ein, ein externer Dienstleister erscheint mit einem älteren Laptop und ein Gast benötigt WiFi vor Beginn eines Meetings. Wenn alle drei dasselbe gemeinsam genutzte Passwort erhalten, ist der Zugriff leicht zu gewähren, aber später nur schwer zu steuern. Das BYOD-Onboarding funktioniert besser, wenn Sie für jede Art von Gerät einen eigenen Pfad wählen und anschließend planen, was passiert, wenn jemand ein Gerät nicht registrieren kann oder möchte.

Der Schlüssel liegt darin, das Onboarding als Lebenszyklus zu betrachten. Eine Anmeldeseite kann zwar erfassen, wer sich verbunden hat, aber sie stellt nicht sicher, dass ein Gerät sicher ist, entscheidet nicht, was es erreichen kann, und stellt nicht sicher, dass sein Zugriff widerrufen werden kann.

Inhaltsverzeichnis

• Auswahl einer BYOD-Onboarding-Methode
  • Wählen Sie den Standard vor der Ausnahme
• Richten Sie das Captive Portal und die Anmeldung per SSO ein
  • Erstellen und testen Sie den Anmeldeablauf
• Stellen Sie EAP-TLS-Zertifikate über Ihr MDM aus
  • Machen Sie Vertrauenswürdigkeit von Geräten zum Bestandteil des Beitritts
• MDM-loses Onboarding und gerätespezifische Schlüssel für geteilte Geräte
  • Verwenden Sie einen Pass oder Schlüssel mit einem definierten Eigentümer
• Fallback-Routen für nicht unterstützte und teilweise verwaltete Geräte
  • Halten Sie die Ausnahme eng gefasst und dokumentiert
• Einwilligungs-, Datenschutz- und Offboarding-Regeln
• Bestätigen Sie die Routenreihenfolge und testen Sie sie zuerst im Pilotbetrieb
  • Legen Sie vor dem Start Pilotmaßnahmen fest

Auswahl einer BYOD-Onboarding-Methode

Methode	Geräteverwaltung erforderlich	Ausgestellte Anmeldeinformation	Ideal für	Wichtigste Einschränkung
Captive Portal mit SSO, Google, Apple, Facebook oder SMS	Keine	Browser-Sitzung mit erfasster Einwilligung	Gäste und gelegentliche Besucher	Portal-Anmeldung belegt nicht den Sicherheitsstatus des Geräts
Über MDM ausgestelltes EAP-TLS Zertifikat über SCEP	Registriertes MDM wie Intune oder Jamf Pro	Zertifikat pro Gerät	Verwaltete Smartphones und Laptops von Mitarbeitern	Nicht registrierte private Geräte können nicht beitreten
MDM-loser, per App installierter WiFi Pass	Installer-App, kein MDM	Pass pro Benutzer oder pro Gerät	Reinigungskräfte, Agenturpersonal, private Smartphones	Geringere Transparenz bezüglich des Gerätestatus
xPSK-Schlüssel pro Gerät	Keine auf dem Gerät	Eindeutiger Pre-Shared Key pro Gerät	Gemeinsam genutzte Kassen, IoT, Anwohner/Bewohner	Erfordert Schlüsselverwaltung und einen Widerrufsprozess
Passpoint- oder OpenRoaming-Profil	Auf dem Gerät installiertes Profil	Zertifikatsbasierte Identität	Wiederkehrende Gäste an verschiedenen Standorten	Nur Geräte, die Passpoint unterstützen

Diese Pfade eignen sich für unterschiedliche Vertrauensstufen und Nutzererwartungen. Ein Browser-Portal hält den Gastzugang einfach, kann aber den Sicherheitsstatus eines Telefons nicht überprüfen. Ein Zertifikat verleiht einem verwalteten Gerät beim Verbindungsaufbau eine stärkere Identität, erfordert jedoch eine Registrierung. Für Geräte, die kein MDM-Profil aufnehmen können, bietet ein Pass oder ein eindeutiger Schlüssel eine Alternative zu einem Passwort, das für einen gesamten Standort freigegeben ist.

BYOD wurde zu einer Anforderung an die Zugriffskontrolle, als persönliche Geräte Einzug in den Arbeitsalltag hielten. In einer Cisco IBSG-Umfrage unter 600 US-amerikanischen IT- und Unternehmensführern aus dem Jahr 2012 gaben 95 % an, dass ihre Unternehmen mitarbeitereigene Geräte in irgendeiner Form gestatteten, und 84 % erlaubten nicht nur persönliche Geräte, sondern boten auch zumindest eine gewisse Unterstützung (Cisco's BYOD-Studie von 2012). Dieser Unterschied ist wichtig: Ein Gerät im WiFi zu erlauben, ist nicht dasselbe wie es zu unterstützen, ihm angemessenen Zugriff zuzuweisen oder seine Anmeldedaten für die Entfernung vorzubereiten.

Wählen Sie den Standardwert vor der Ausnahme

Beginnen Sie damit, jeder Geräteklasse eine Standardroute zuzuweisen. Verwaltete Mitarbeitergeräte sollten Zertifikate nutzen; Gäste sollten ein Portal verwenden; Geräte ohne MDM sollten einen per App installierten Pass oder einen eindeutigen Schlüssel erhalten, kein gemeinsames Passwort. Für wiederkehrende Gäste eignen sich möglicherweise Passpoint oder OpenRoaming, sofern ihre Geräte das Profil unterstützen.

Prüfen Sie anschließend, ob Ihr gewählter Standard etwas erfordert, das ein Benutzer nicht bereitstellen möchte, wie z. B. die Erlaubnis zur Verwaltung eines privaten Telefons. Senden Sie nur diese Ausnahmen an die Ausweichrouten, anstatt den Standard für alle zu lockern. Eine WiFi Übersicht zur Zugriffskontrolle kann Teams dabei helfen, die Authentifizierung der Zugriffsrichtlinie zuzuordnen, aber Ihre Geräteklassen und Netzwerkberechtigungen sollten die finale Wahl bestimmen.

Richten Sie das Captive Portal und die SSO-Anmeldung ein

Ein Captive Portal ist ein praktischer Standard für Gäste, da sie sich anmelden können, ohne ein Verwaltungsprofil zu installieren. Es ist auch nützlich, wenn Sie die Zustimmung erfassen oder Besuchern die Authentifizierung über ein bereits vorhandenes Konto ermöglichen müssen. Die wichtige Designentscheidung ist, wohin das Portal jeden Benutzer nach der Anmeldung weiterleitet: Die Authentifizierung sollte in das richtige Netzwerk führen und nicht standardmäßig umfassenden Zugriff gewähren.

Anmeldeflow erstellen und testen

1. Erfassen Sie das Netzwerk und wählen Sie einen Standort für den Pilotbetrieb. Ordnen Sie in einer Design-Session Access Points, SSIDs, Verzeichnisgruppen und Geräteklassen offenen, sicheren und xPSK Netzwerken zu. Ein Netzwerktechniker sollte dem Team einen Plan und einen Pilotstandort an die Hand geben, damit die Konfiguration die physische Infrastruktur widerspiegelt und kein idealisiertes Diagramm.

2. Registrieren Sie eine Identitätsanwendung. Richten Sie eine Anwendung in Entra ID, Google Workspace oder Okta ein und gewähren Sie den für die Anmeldung erforderlichen Verzeichniszugriff. Verwenden Sie zunächst eine Registrierung für den Pilotbetrieb, damit Sie die Berechtigungen und das Anmeldeerlebnis prüfen können, bevor Sie die Bereitstellung ausweiten.

3. Fügen Sie die Portal- und RADIUS-Details zum Controller hinzu. Konfigurieren Sie den RADIUS-Server und die Splash-URL. Sobald die App-Registrierung besteht, dauert die Einrichtung auf Kundenseite unter 15 Minuten, einschließlich dieser Controller-Änderungen.

4. Wählen Sie Anmeldemethoden für die jeweiligen Zielgruppen. Verwenden Sie SSO für Mitarbeiter, die eine Unternehmensidentität benötigen, Google oder Apple für persönliche Konten und Facebook dort, wo Besucher es erwarten. SMS-Einmal-Passcodes bieten Besuchern ohne passendes Konto einen alternativen Weg.

5. Gestalten Sie das Portal im Corporate Design und gestalten Sie die Zustimmung transparent. Formulieren Sie den Einwilligungstext in verständlicher Sprache und zeichnen Sie jeden Anmeldevorgang auf. Platzieren Sie den Hinweis so, dass der Benutzer ihn vor der Zustimmung lesen kann, und nicht unterhalb der zu drückenden Schaltfläche.

6. Testen Sie reale Geräte im Gästenetzwerk. Verbinden Sie ein persönliches iPhone, ein Android-Smartphone und ein Windows-Laptop. Bestätigen Sie, dass jeder Benutzer auf dem Gäste-VLAN landet und dass die Client-Isolierung verhindert, dass Gäste-Geräte untereinander eine Verbindung herstellen.

Die üblichen Fehler bei Pilotprojekten sind eine Splash-URL, die auf den falschen Controller zeigt, unter der Anmeldeschaltfläche verborgener Einwilligungstext und das Testen ausschließlich mit Unternehmensgeräten. Jeder dieser Punkte kann dazu führen, dass ein Portal in einem eng gefassten Test erfolgreich erscheint, aber für die eigentlichen Benutzer fehlschlägt. Teams, die Okta nutzen, können bei der Planung der Identitätsanbindung auch diesen Leitfaden zur Okta WiFi Authentifizierung zu Rate ziehen.

Stellen Sie EAP-TLS-Zertifikate über Ihr MDM aus

Bei verwalteten Mitarbeitergeräten verknüpft ein zertifikatsbasierter Beitritt den Netzwerkzugriff mit einem registrierten Gerät, anstatt sich auf ein geteiltes WiFi Passwort zu verlassen. Das Gerät weist seine Identität während der Verbindung nach, und eine Benutzeridentität kann bestimmen, welche Netzwerkberechtigungen gelten. NIST beschreibt ein bereitgestelltes Zertifikat als eine Möglichkeit, ein mobiles Gerät am Verbindungspunkt zu identifizieren und zu authentifizieren, und merkt an, dass die Kombination mit Benutzeranmeldedaten eine Zwei-Faktor-Authentifizierung bieten kann (NIST-Leitfaden zur Sicherheit mobiler Geräte).

Skalierung ist hier selten das Problem. Die Bereitstellung von Zertifikaten über SCEP dauert einmalig fünf bis zehn Minuten für die gesamte Organisation. In der Umstellungsnacht erhalten verwaltete Laptops und Smartphones ihr Zertifikat vom MDM und verbinden sich automatisch. Die schwierigere Aufgabe besteht darin, zu entscheiden, welche Prüfungen ein Gerät bestehen muss, bevor diesem Zertifikat vertraut wird.

Gerätevertrauen zum Bestandteil des Beitritts machen

1. Authentifizieren Sie den Benutzer. Beginnen Sie mit SSO oder einem anderen genehmigten Faktor, damit das Netzwerk ein Gerät einer bekannten Person oder einem bekannten Konto zuordnen kann.

2. Überprüfen Sie Registrierung und Status. Bestätigen Sie, dass das Gerät registriert ist und die Mindestanforderungen der Organisation an Betriebssystem und Sicherheit erfüllt. Behandeln Sie ein persönliches Gerät als potenziell nicht vertrauenswürdig, bis es diese Prüfungen besteht.

3. Stellen Sie ein gerätegebundenes Zertifikat aus. Verwenden Sie das MDM, um das Zertifikat über SCEP bereitzustellen. Ein gerätegebundenes Anmeldeauthentifizierungsmittel ist einfacher zu verwalten als ein gemeinsam genutztes Geheimnis, da es an einen einzelnen registrierten Endpunkt gebunden und widerrufen werden kann, ohne andere Komponenten zu beeinträchtigen.

4. Stellen Sie eine Verbindung über EAP-TLS her. Konfigurieren Sie den Client und das Netzwerk so, dass die relevanten Zertifikate validiert werden. Benutzeranmeldedaten und das Gerätezertifikat bieten dann zum Verbindungszeitpunkt getrennte Identitätsprüfungen.

5. Weisen Sie den Zugriff nach Gruppen zu. Ordnen Sie Verzeichnisgruppen VLANs mit minimalen Zugriffsrechten zu, sodass die Rolle eines Mitarbeiters bestimmt, welche Dienste die Sitzung erreichen kann. Eine erfolgreiche Authentifizierung sollte nicht automatisch Zugriff auf jeden internen Dienst bedeuten.

6. Überprüfen Sie die Compliance fortlaufend. Beschränken Sie die Richtlinienauswertung nicht auf die Erstregistrierung. Bewerten Sie den Gerätestatus erneut und entziehen Sie den Zugriff, wenn ein Gerät den Anforderungen nicht mehr entspricht oder das dahinterstehende Konto deaktiviert wird.

Zu den häufigsten Ursachen für Helpdesk-Anfragen gehören nicht unterstützte OS-Versionen, abgelaufene Zertifikate, eine falsche Systemzeit, fehlende Trust-Chain-Zertifikate, die Randomisierung privater MAC-Adressen und Nutzer, die Verwaltungsberechtigungen ablehnen. Verfolgen Sie Fehler nach Gerätemodell und OS-Version, da eine insgesamt gute Registrierungsrate wiederholte Ausfälle auf einer einzelnen Plattform verbergen kann.

• Nicht unterstütztes Betriebssystem: Bieten Sie einen genehmigten Upgrade-Pfad an oder leiten Sie das Gerät zu einem beschränkten Zugriff weiter.
• Abgelaufenes Zertifikat: Automatisieren Sie die Verlängerung frühzeitig genug, um Ausfälle beim Ablauf von Anmeldedaten zu vermeiden.
• Falsche Uhrzeit oder fehlende Vertrauenskette: Überprüfen Sie die Geräteurzeit und die Zertifikatsinstallation, bevor Sie die Netzwerkrichtlinie ändern.
• Private MAC-Randomisierung: Bestätigen Sie, ob die Richtlinie des Netzwerks von einer stabilen Geräteadresse abhängt, und stellen Sie plattformspezifische Einrichtungsanweisungen bereit.
• Abgelehnte Verwaltungsberechtigungen: Erklären Sie, was die Verwaltung einsehen kann, und bieten Sie einen Ausweichpfad an, anstatt umfassenden Zugriff zu gewähren.

Die Compliance-Baseline selbst bleibt einfach. Geräte sollten Sicherheitsupdates umgehend und regelmäßig erhalten, eine Bildschirmsperre nutzen, Apps nur aus autorisierten Quellen installieren und vom Zugriff ausgeschlossen werden, wenn sie gerootet oder gejailbreakt sind. Ein Gerät, das diese Statusprüfungen nicht besteht, gehört in ein isoliertes Netzwerk mit geringen Rechten und nicht in das Unternehmensnetzwerk.

Die Sequenz ist leichter zu verstehen, wenn Sie den Zertifikatsfluss im Kontext sehen. Das folgende Video bietet eine visuelle Ergänzung zu den Onboarding-Schritten.

MDM-freies Onboarding und gerätespezifische Schlüssel für gemeinsam genutzte Geräte

Manche Geräte können die MDM-Registrierung nicht abschließen. Dazu gehören ein privates Telefon, dessen Besitzer keine Verwaltung erlaubt, eine gemeinsam genutzte Kasse oder ein Kiosk sowie ein IoT-Sensor ohne geeignete Registrierungsschnittstelle. Die Lösung besteht nicht darin, sie alle in das Mitarbeiternetzwerk aufzunehmen. Nutzen Sie einen eingeschränkten Pfad, der jedem Gerät eindeutige Anmeldedaten und einen klaren Eigentümer zuweist.

Verwenden Sie einen Pass oder Schlüssel mit einem definierten Eigentümer

1. Bestätigen Sie, dass das Gerät unverwaltet oder nicht unterstützt wird. Prüfen Sie, dass es den Zertifikatsweg nicht nutzen kann und dass der Eigentümer einer Installer-App zustimmt. Dadurch wird verhindert, dass eine Ausnahme nur deshalb zum Standard wird, weil die Registrierung unbequem ist.

2. Einen per App installierten WiFi Pass für private Smartphones bereitstellen. Der Benutzer meldet sich an und installiert den Pass, ohne das gesamte Smartphone im MDM zu registrieren. Für einen verwalteten Rollout können private Smartphones am Abend der Umstellung mit zwei Taps einen WiFi Pass aus der Purple-App installieren.

3. Geben Sie jedem gemeinsam genutzten Terminal einen eigenen xPSK Schlüssel. Weisen Sie der Kasse oder dem Kiosk eine eigene VLAN zu, mit einer für die jeweilige Aufgabe passenden Bandbreitenbegrenzung. Ein eindeutiger Schlüssel verhindert, dass sich ein einzelnes Passwort über alle Kassen verteilt.

4. Passen Sie die Lebensdauer des Schlüssels an die Nutzung an. Stellen Sie sie so ein, dass sie zur Buchung, zum Vertrag oder zum Schichtmodell passt. Eine temporäre Anmeldeinformation sollte nicht mehr nutzbar sein, nachdem die Person oder das Gerät keinen Zugriff mehr benötigt.

5. Erfassen Sie, wer die einzelnen Schlüssel hält. Verknüpfen Sie einen Geräte- oder Benutzereigentümer mit den Anmeldeinformationen, damit das Support-Personal identifizieren kann, welcher Zugriff widerrufen werden muss, wenn ein Gerät verloren geht oder ein Mitarbeiter das Unternehmen verlässt.

6. Widerrufen Sie den Schlüssel und testen Sie das Ergebnis. Entfernen Sie den Zugriff beim Ausscheiden und bestätigen Sie, dass das Gerät die Verbindung zum Netzwerk verliert. Der Widerruf ist Teil des Onboarding-Designs und keine Aufgabe, die erst nach einem Problem erfunden werden sollte.

Diese Routen bieten weniger Einblick in den Gerätestatus als ein Zertifikat. Halten Sie sie daher in beschränkten Netzwerken und nicht im Mitarbeiter-VLAN. Der betriebliche Kompromiss ist einfach: Ein gerätespezifischer Schlüssel erfordert mehr Sorgfalt bei der Ausstellung und Nachverfolgung, schränkt aber die Reichweite kompromittierter Anmeldedaten ein.

Fallback-Routen für nicht unterstützte und teilweise verwaltete Geräte

Der Support ist nicht beständig genug, um „Registrieren oder Zugriff verlieren“ zu einer praktikablen Richtlinie für jeden Mitarbeiter zu machen. Ein Verizon Mobile Security Report von 2025 ergab, dass 15 % der befragten Unternehmen vollständigen Support für alle Mobilgerädetypen boten, während 32 % Ad-hoc-Support anboten, 27 % nur bestimmte Modelle unterstützten und 23 % keinerlei Support bereitstellten. Diese Lücke betrifft Personen, die ältere Geräte nutzen, externe Auftragnehmer, Mitarbeiter mit Kundenkontakt sowie Angestellte, die einer umfassenden Überwachung eines privaten Smartphones nicht zustimmen.

Gerätefall	Onboarding-Weg	Netzwerkzugriff	Prüfung vor Erteilung
Vollständig verwaltetes, unterstütztes Betriebssystem	MDM-Zertifikat über EAP-TLS	Sicheres Netzwerk nach Verzeichnisgruppe	Compliance-Status und Zertifikatsablauf
Persönliches Smartphone, keine Verwaltungsberechtigung	Captive Portal oder App-WiFi-Pass	Gäste-VLAN mit Client-Isolierung	Einwilligung erfasst, kein Unternehmens-VLAN
Nicht unterstützte Betriebssystemversion	Reiner Browserzugriff auf benannte Apps	Isoliertes Netzwerk mit geringen Privilegien	Upgrade-Datum und Liste genehmigter Apps
Gemeinsam genutzte Kasse oder Kiosk	Gerätespezifischer xPSK-Schlüssel	Eigenes VLAN mit Bandbreitenbegrenzung	Schlüsselinhaber und Widerrufsweg
Externer Dienstleister oder temporäre Arbeitskraft	Zeitlich begrenzter Gäste-Login oder Leihgerät	Gäste-VLAN, läuft bei Vertragsende ab	Vertragsenddatum und benannter Sponsor
Barrierefreiheit oder Anfrage für ältere Geräte	Manuelle Überprüfung mit einem Leihgerät	Beschränkt auf genehmigte Apps	Überprüfungsdatum und benannter Eigentümer

Halten Sie die Ausnahme eng gefasst und dokumentiert

Geben Sie jedem Gerät nur den Mindestzugriff, der für die Aufgabe erforderlich ist. Ein privates Smartphone, das nur Browserzugriff auf einen bestimmten Dienst benötigt, braucht keine Route zu internen Anwendungen oder zum Unternehmens-VLAN. Eine gemeinsam genutzte Kasse benötigt die ihr zugewiesenen Dienste, und ihre Anmeldedaten benötigen einen benannten Eigentümer sowie einen Widerrufspfad.

Veröffentlichen Sie eine Geräte-Kompatibilitätsmatrix, damit die Mitarbeiter vor ihrer Ankunft an einem Standort prüfen können, ob ihr Betriebssystem und ihr Gerät registriert werden können. Führen Sie ein Inventar der nicht unterstützten Betriebssysteme und Anwendungen und halten Sie fest, welcher Ausweichpfad für welche Option gilt. Für externe Dienstleister und Besucher hilft ein zeitlich begrenzter Netzwerkpfad dabei, Ablauf und Sponsoring explizit zu gestalten.

Eine starre Regel kann die Sicherheit verschlechtern, wenn sie Mitarbeiter zu persönlichen Hotspots, geteilten Passwörtern oder anderen unverwalteten Umgehungslösungen treibt. Eine eingeschränkte, dokumentierte Route ist oft sicherer als das Verweigern des Zugriffs ohne Alternative.

Einwilligungs-, Datenschutz- und Offboarding-Regeln

„Kann ich BYOD ablehnen, und was genau wird mein Arbeitgeber sehen oder löschen können?“ Stellen Sie die Antwort im Onboarding-Hinweis bereit, bevor ein Mitarbeiter aufgefordert wird, ein Profil zu akzeptieren oder eine App zu installieren. Eine technische Authentifizierung zeigt nicht, dass jemand die Bedingungen verstanden hat oder sich frei zu einer Entscheidung gefühlt hat.

In einer Umfrage im Pflegesektor nutzten 50 % der Anbieter BYOD, aber nur die Hälfte davon hatte eine BYOD-Richtlinie; nur 40 % der Mitarbeiter, die private Geräte nutzten, erinnerten sich daran, eine Richtlinie oder Anleitung unterzeichnet zu haben. Eine separate Umfrage aus dem Jahr 2025 ergab, dass 70 % der Mitarbeiter vom Unternehmen bereitgestellte Geräte bevorzugten (der BYOD-Bericht für die Erwachsenensozialpflege 2025). Diese Ergebnisse stellen die Annahme infrage, dass der Zugriff über private Geräte für Arbeitnehmer automatisch günstiger oder praktischer ist.

Der Hinweis sollte in einfacher Sprache Folgendes enthalten:

• Welche Sicherheitstelemetrie erfasst wird und welche persönlichen Inhalte die Organisation nicht sehen kann.
• Was entfernt werden kann, einschließlich der Bestätigung, dass das Entfernen eines Arbeitsprofils keine persönlichen Inhalte löscht.
• Wer für berufsbezogene mobile Daten und Geräteverschleiß aufkommt, mit Erstattungsregeln für das jeweilige Land.
• Was die Alternative ist, wenn der Mitarbeiter die Verwaltung des privaten Geräts ablehnt.

Ein Kontrollkästchen ist keine gewichtige Einwilligung, wenn die Teilnahme effektiv obligatorisch ist. Bieten Sie ein Leihgerät oder einen anderen Zugangsweg an und bitten Sie erneut um Einwilligung, wenn sich die Überwachung oder Datennutzung ändert. Bei Check-in-Prozessen für Besucher können Teams auch Anleitungen nutzen, um Gast-IDs vor dem Check-in zu überprüfen - als Anstoß zu prüfen, welche Identitätsinformationen erforderlich sind und wie diese gehandhabt werden sollten.

Beim Offboarding müssen das Zertifikat, das Verwaltungsprofil, gecachte Token und alle mit dem Gerät verknüpften xPSK-Schlüssel entfernt werden. Eine Demo zu Purple Access kann einem Techniker zeigen, wie ein Schlüssel in einem Live-Netzwerk für die Geräte einer Wohnung ausgestellt und widerrufen wird: ein Schloss, ein Thermostat, der Laptop eines Gastes und das Diensthandy eines Kundenmitarbeiters.

1. Stellen Sie einen Schlüssel auf einem aktiven Gerät aus.
2. Widerrufen Sie ihn.
3. Messen Sie die Zeit, bis der Zugriff stoppt.
4. Erfassen Sie das Ergebnis als Kriterium für den erfolgreichen Widerruf des Pilots.

Bestätigen Sie die Routenreihenfolge und führen Sie zuerst einen Pilotversuch durch

Rollen Sie die Routen in einer Reihenfolge aus, die verhindert, dass Ausnahmen das gesamte Netzwerk definieren. Jede Geräteklasse erhält einen Standardwert, während der Pilotversuch bestätigt, dass die Route mit den Identitäten, Controllern und Geräten an einem realen Standort funktioniert.

1. Beginnen Sie mit verwalteten Mitarbeiter-Geräten im EAP-TLS. Nutzen Sie den Zertifikats-Pfad für registrierte Laptops und Smartphones, wobei der Zugriff an Verzeichnisgruppen und einen getesteten Widerrufspfad gebunden ist.

2. Fügen Sie das Gäste-Portal hinzu. Gestalten Sie das Anmeldeerlebnis übersichtlich und erfassen Sie die Einwilligung bei jeder Gäste-Sitzung.

3. Übertragen Sie private und nicht verwaltete Mitarbeiter-Smartphones auf einen WiFi Pass. Dies bietet Benutzern eine Option, die keine vollständige Geräteregistrierung erfordert.

4. Versehen Sie gemeinsam genutzte Kassen, Kiosksysteme und IoT-Geräte mit eindeutigen xPSK Schlüssel. Weisen Sie jedem Gerät seine eigene Zugriffsrichtlinie zu und erfassen Sie, wer Eigentümer der Anmeldedaten ist.

5. Wenden Sie Ausweichpfade nur bei Ausnahmen an. Nutzen Sie reinen Browser-Zugriff, ein Gäste- oder Auftragnehmer-Netzwerk, ein Leihgerät oder eine manuelle Überprüfung, wenn der Standardpfad nicht möglich ist.

Legen Sie vor dem Start Pilotmaßnahmen fest

Wählen Sie einen Pilotstandort aus und definieren Sie Erfolgskriterien, bevor jemand mit der Registrierung beginnt. Messen Sie den Registrierungsabschluss, die erste erfolgreiche Authentifizierung, die Helpdesk-Kontakte pro 100 Registrierungen und die Zeit bis zum Entzug des Zugriffs. Wenn Sie die Schwellenwerte erst nach dem Pilotprojekt festlegen, ist die Gefahr groß, ein schwaches Ergebnis als akzeptabel zu bezeichnen, nur weil der Standort bereits live ist.

Buchen Sie eine Design-Session und bringen Sie Ihre SSID-Liste, den Access-Point-Anbieter, das Verzeichnis und das MDM mit. Ein Netzwerkingenieur kann diese Details den offenen, sicheren und xPSK Netzwerken zuordnen und den Plan vor dem Rollout am Pilotstandort validieren. Die Demo-Anfrage erfasst die Organisation und die Kontaktdaten sowie die derzeit auf dem WiFi des Kunden ausgeführten Komponenten, einschließlich SSIDs, Access-Point-Anbieter, Verzeichnis und MDM.

---

Purple Access unterstützt Captive-Portal-Anmeldung und -Zustimmung, EAP-TLS-Zertifikate über MDM sowie gerätespezifische Schlüssel für nicht verwaltete Geräte. Besuchen Sie Purple Access, um eine Demo zu vereinbaren und Ihre Geräte- und Netzwerkdetails in die Design-Sitzung einzubringen.