RFP-Anforderungen für Gäste-WiFi: Was Sie für Onboarding, Sicherheit und Analysen festlegen sollten

Eine RFP für Gäste-WiFi sollte messbare Anforderungen in fünf Bereichen festlegen. Onboarding: Captive Portal, Erfassung von Einwilligungen und Barrierefreiheit nach WCAG 2.2. Sicherheit: IEEE 802.1X, RADIUS, Passpoint und WPA3. Hardware: namentlicher Support für Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und Ubiquiti UniFi. Compliance: GDPR, PCI DSS v4.0 und schützendes DNS. Analysen: exportierbare First-Party-Daten. Bewerten Sie Bieter anhand von Nachweisen.

Was muss eine RFP für Gäste-WiFi tatsächlich spezifizieren?

Eine RFP für Gäste-WiFi verwandelt ein vages Briefing wie "kostenloses WiFi für Gäste" in Anforderungen, die ein Bieter erfüllen oder verfehlen kann. Sie definiert, wie Personen beitreten, wie der Datenverkehr gesichert wird und auf welcher Hardware die Plattform laufen muss. Zudem legt sie fest, wie personenbezogene Daten verarbeitet werden und welche Berichte Sie erhalten.

Schwache RFPs scheitern meist auf dieselbe Weise. Sie listen Funktionen statt Standards auf, sodass jeder Bieter mit "Ja" antwortet und die Rückmeldungen identisch aussehen. Die Lösung besteht darin, jeder Zeile einen benannten Standard, den von Ihnen erwarteten Nachweis und einen Pilot-Test zuzuordnen.

Für einen Standortverbund mit mehreren Objekten legt die RFP auch Ihr Betriebsmodell für die Gesamtdauer des Vertrags fest. Ein Captive Portal ist die Webseite, die ein Gerät sieht, bevor es Internetzugang erhält. Sie können ein einziges Captive Portal und einen einzigen Einwilligungssatz über alle Standorte hinweg betreiben. Die Alternative ist eine unterschiedliche Einrichtung für jeden Hardware-Anbieter. Das spätere Entwirren eines fragmentierten Standorts verursacht weit höhere Kosten als die sofortige Spezifikation einer einheitlichen Lösung.

Dieser Leitfaden bietet Ihnen Anforderungsformulierungen, eine Bewertungsmatrix und Pilot-Tests. Nutzen Sie ihn als Vorlage für eine Gäste-WiFi-RFP, die Sie für Hotels, Einzelhandel, Gesundheitswesen, Züge, Stadien und Veranstaltungsorte des öffentlichen Sektors anpassen können.

Was benötigen Sie, bevor Sie die RFP für Gäste-WiFi verfassen?

Sammeln Sie vor dem ersten Entwurf fünf Eingaben. Jede einzelne beugt einer häufigen Ursache für Änderungsanträge nach der Auftragsvergabe vor.

• Ein Hardware-Inventar pro Veranstaltungsort. Erfassen Sie den Access Point (AP)-Anbieter, das Modell, die Verwaltungsplattform und die Firmware an jedem Standort. Notieren Sie, ob jeder Standort ein Cloud-Dashboard oder einen On-Premises-Controller nutzt. Unser Leitfaden Was ist ein WLC (Wireless LAN Controller) und benötigen Sie noch einen? erklärt den Unterschied.
• Eine Standortliste nach Typ. Gruppieren Sie Standorte nach Branchen und Größe, da ein Stadion-Umlauf und eine Hotel-Lobby ein unterschiedliches Onboarding erfordern. Benennen Sie die Personen, die jeder Standort bedient: Gäste, Käufer, Passagiere, Fans, Patienten oder Besucher.
• Eine Datenkarte. Entscheiden Sie, wer als Datenverantwortlicher fungiert, welche Systeme WiFi-Daten empfangen und wie lange Sie diese aufbewahren. Ihr Datenschutzbeauftragter sollte dies vor dem Versenden der RFP genehmigen.
• Ihre Zahlungsbereichsgrenzen. Listen Sie jede Website auf, die Kartenzahlungen akzeptiert. Notieren Sie, ob Zahlungsgeräte Switches oder Schaltkreise mit dem Gästeverkehr teilen. Dies definiert Ihren PCI-DSS-Umfang.
• Erfolgsmaßstäbe. Vereinbaren Sie die Zahlen, die Sie berichten werden, z. B. Anmeldungen, Opt-in-Rate, wiederkehrende Besucher und Support-Tickets. Bieter können dann zeigen, wie ihre Berichterstattung jedes einzelne Ergebnis erzeugt.

Binden Sie IT, Sicherheit, Datenschutz, Marketing und den Betrieb vor Ort von Anfang an ein. Gäste-WiFi betrifft alle fünf Teams. Eine Anforderung, die von einem Team geschrieben wurde, blockiert oft ein anderes.

Wie verfassen Sie Anforderungen für eine Gäste-WiFi-Ausschreibung (RFP) Abschnitt für Abschnitt?

Schreiben Sie jede Anforderung mit "muss" oder "sollte" gemäß der Konvention in RFC 2119. Ein "muss" ist ein Kriterium zum Bestehen oder Nichtbestehen. Ein "sollte" wird bewertet. Bitten Sie die Bieter, jede Zeile mit Nachweisen zu beantworten: einem Dokument, einem Zertifikat, einer Referenzseite oder einer Live-Demonstration.

Anforderungen an Onboarding und Captive Portal

Das Onboarding ist der Punkt, an dem Gäste Ihr Netzwerk beurteilen und an dem Ihre Einwilligungsnachweise erstellt werden. Diese Captive-Portal-RFP-Checkliste deckt die wesentlichen Punkte ab.

• Anmeldemethoden. Die Plattform muss E-Mail, Social Login, SMS und Zugangscodes unterstützen, konfigurierbar pro Standort.
• Opt-ins nach bewusster Entscheidung. Die Marketing-Einwilligung muss eine separate, nicht angekreuzte Option sein und darf niemals mit der Zustimmung zu den AGB gebündelt werden. GDPR Artikel 7 verlangt, dass die Einwilligung nachweisbar und ebenso einfach zu widerrufen wie zu erteilen sein muss.
• Barrierefreiheit. Das Captive Portal muss WCAG 2.2 Stufe AA erfüllen.
• Zuverlässige Portal-Erkennung. Die Plattform sollte die Captive Portal API (RFC 8908) und die DHCP-Captive-Portal-Option (RFC 8910) unterstützen. Beide helfen modernen Geräten, die Anmeldeseite ohne Umleitungsschleifen zu finden.
• Wiedererkennung wiederkehrender Besucher. iOS 14 und Android 10 ff. verwenden standardmäßig zufällige MAC-Adressen. Fragen Sie die Bieter, wie sie einen wiederkehrenden Gast erkennen, ohne sich auf die Hardware-Adresse des Geräts zu verlassen.
• Zentrale Steuerung. Die Zentrale muss Branding, AGB und Einwilligungstexte zentral verwalten, mit lokalen Anpassungsmöglichkeiten für jeden Standort.

Purple Gäste-WiFi integriert Opt-ins nach bewusster Entscheidung in das Captive Portal und verwaltet es zentral über den gesamten Standortbestand hinweg.

Anforderungen an Authentifizierung, RADIUS und Passpoint

RADIUS ist das Protokoll, mit dem ein AP einen zentralen Server fragt, ob ein Gerät zugelassen werden soll. Es ist in RFC 2865 definiert. Das in RFC 2866 definierte RADIUS-Accounting erfasst Sitzungsstart, Sitzungsende und Datennutzung. Für einen Bestand mit mehreren Standorten geben Sie Folgendes an.

• Cloud-RADIUS mit Redundanz. Die Authentifizierung muss auch beim Ausfall eines Rechenzentrums weiterhin funktionieren. Fordern Sie die Architektur und die gemessene Verfügbarkeit der letzten 12 Monate an.
• Verschlüsselter RADIUS-Transport. Wenn RADIUS das öffentliche Internet quert, fordern Sie RadSec (RADIUS über TLS, RFC 6614) oder einen verschlüsselten Tunnel.
• Dynamische Autorisierung. Die Plattform sollte CoA-Nachrichten (RFC 5176) senden, um eine Sitzung zu beenden oder zu ändern, ohne eine erneute Verbindung zu erzwingen.
• Segmentierung. Gast-Traffic muss auf einem eigenen VLAN liegen, einem logischen Netzwerksegment, das von Mitarbeitenden und Zahlungssystemen isoliert ist. Die Client-Isolierung muss verhindern, dass Gastgeräte einander erreichen.
• Verschlüsselung in offenen Netzwerken. Erfordern Sie WPA3, einschließlich Enhanced Open (Opportunistic Wireless Encryption, RFC 8110). Dies verschlüsselt jede Verbindung ohne ein gemeinsames Passwort.
• Individuelle Schlüssel bei Bedarf. iPSK (identity pre-shared key) gibt jeder Person oder jedem Gerät ein eigenes WiFi-Passwort in einem gemeinsam genutzten Netzwerk. Dies eignet sich für Langzeitgäste, Aussteller und Event-Crews. Purple stellt dies über SecurePass bereit.

Passpoint, auch Hotspot 2.0 genannt, baut auf IEEE 802.11u auf. Es ermöglicht Geräten, ein Netzwerk automatisch zu finden und ihm beizutreten, ohne Captive Portal. Die Authentifizierung läuft über IEEE 802.1X, den Standard für portbasierte Netzwerkzugriffskontrolle, sodass die Anmeldedaten verschlüsselt bleiben. OpenRoaming, betrieben von der Wireless Broadband Alliance, ist ein Verbund, der auf Passpoint basiert. Es ermöglicht Personen, teilnehmenden Netzwerken mit einer bereits vorhandenen Identität beizutreten.

Geben Sie Passpoint und OpenRoaming in Phase eins als Soll-Anforderungen mit einer kalkulierten Roadmap an. Purple unterstützt OpenRoaming, sodass sich wiederkehrende Gäste an Ihren Standorten automatisch verbinden können.

Wenn die Ausschreibung (RFP) auch Mitarbeiter-WiFi abdeckt, fordern Sie die Integration mit Microsoft Entra ID, Okta und Google Workspace. Dadurch bleiben Neueinstellungen, Rollenwechsel und Abgänge synchron mit dem Netzwerkzugriff, ganz ohne manuelle Passwortänderungen.

Hardware-neutrale AP-Kompatibilität

"Kompatibel mit führender Enterprise-Hardware" kann nicht bewertet werden. Nennen Sie jede Plattform, die Sie betreiben oder während der Vertragslaufzeit einführen könnten. Fordern Sie dann dieselben fünf Funktionen auf jeder Plattform.

1. Unterstützung für externe Captive Portals.
2. RADIUS-Authentifizierung und -Accounting.
3. Walled Garden: Die Allowlist an Domains vor dem Login, die das Portal und der Social Login benötigen.
4. CoA-Unterstützung oder eine dokumentierte Alternative zum Beenden von Sitzungen.
5. Ein veröffentlichter Integrationsleitfaden und mindestens eine Live-Referenz auf dieser Plattform.

Anbieter	Im RFP zu nennende Verwaltungsplattform	Zu fordernder Mindestnachweis
Cisco Meraki	Meraki Dashboard	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
HPE Aruba	HPE Aruba Networking Central oder Mobility Controller	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
Ruckus	RUCKUS SmartZone oder RUCKUS One	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
Juniper Mist	Juniper Mist Cloud	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
Ubiquiti UniFi	UniFi Netzwerk-Anwendung	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
Cambium	cnMaestro	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
Extreme	ExtremeCloud IQ	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware
Fortinet	FortiGate integrierter Wireless-Controller	Integrationsleitfaden, Live-Referenz, Pilotprojekt auf Ihrer Firmware

Bitten Sie jeden Bieter, die von ihm unterstützten Firmware-Bereiche anzugeben, und testen Sie diese anschließend gegen Ihre eigenen. Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf allen acht Plattformen. Es ist kein Austausch bestehender Hardware erforderlich. Der kommerzielle Anwendungsfall wird in Warum Ihr nächstes WiFi-Upgrade keine neue Hardware erfordert beschrieben. Für Ruckus-Bestände siehe Ruckus SmartZone und RUCKUS One Gäste-WiFi vs. externe Captive Portal-Plattformen.

Erforderliche GDPR-Klauseln

Gäste-WiFi erfasst personenbezogene Daten in großem Umfang, daher muss der Vertrag folgende Klauseln enthalten:

• Eine Vereinbarung zur Auftragsverarbeitung, die Artikel 28 der GDPR entspricht und Zweck, Sicherheit, Unterauftragnehmer sowie Löschung abdeckt.
• Einwilligungsnachweise, die Zeitstempel, Version des Wortlauts und den Kanal für jede Einwilligung zeigen und auf Anfrage exportierbar sind.
• Konfigurierbare Aufbewahrungsfristen mit automatischer Löschung gemäß dem Grundsatz der Speicherbegrenzung in Artikel 5 Abs. 1 lit. e.
• Werkzeuge für betroffene Personen, um die Daten einer Einzelperson zu finden, zu exportieren und zu löschen. Anfragen müssen gemäß Artikel 12 Abs. 3 innerhalb eines Monats beantwortet werden.
• Benachrichtigung bei Verletzungen durch den Auftragsverarbeiter ohne schuldhaftes Zögern, wie in Artikel 33 Abs. 2 vorgeschrieben. Sie haben dann 72 Stunden Zeit, um die Aufsichtsbehörde gemäß Artikel 33 Abs. 1 zu informieren.
• Internationale Datenübermittlungen. Der Bieter muss angeben, wo die Daten gespeichert werden, sowie den Übermittlungsmechanismus für jede Verarbeitung außerhalb des Vereinigten Königreichs oder des EWR nennen.
• Sicherheitsnachweise für Artikel 32, idealerweise eine ISO 27001-Zertifizierung.

Purple ist ISO 27001-zertifiziert sowie konform mit GDPR, CCPA und Cyber Essentials.

Erforderliche PCI DSS-Klauseln

Gäste-WiFi sollte sich niemals innerhalb Ihrer Karteninhaber-Datenumgebung (CDE) befinden. Die CDE umfasst die Systeme, die Kartendaten speichern, verarbeiten oder übertragen. PCI DSS v4.0 ermöglicht Ihnen eine Reduzierung des Geltungsbereichs durch Segmentierung, Sie müssen jedoch nachweisen, dass diese funktioniert.

• Der Bieter muss schriftlich bestätigen, dass der Gäste-Datenverkehr niemals die CDE durchquert, und das Design dokumentieren.
• Das Design muss Ihren Penetrationstest zur Segmentierung unterstützen, der gemäß Anforderung 11.4.5 mindestens alle 12 Monate erforderlich ist.
• Auf dem Captive Portal dürfen keine Kartendaten eingegeben werden. Jeder kostenpflichtige Zugang muss über einen PCI DSS-konformen Zahlungsanbieter erfolgen, dessen Konformitätsbescheinigung (Attestation of Compliance) vorzulegen ist.
• Ihre vierteljährlichen Prüfungen auf unautorisierte Wireless Access Points gemäß Anforderung 11.2.1 decken weiterhin Gästebereiche ab.

Erforderliche Protective DNS-Klauseln

Protective DNS verhindert, dass Geräte Domänen auflösen, von denen bekannt ist, dass sie Malware, Phishing oder Command-and-Control-Server hosten. Das UK National Cyber Security Centre (NCSC) bietet öffentlichen Stellen einen Protective DNS-Dienst an. Machen Sie folgende Vorgaben:

• Bedrohungs-Feeds. Der Bieter muss seine Quellen für Bedrohungsinformationen und deren Aktualisierungsfrequenz angeben.
• Kategorienfilterung pro Standort, z. B. das Blockieren von Inhalten für Erwachsene in Bibliotheken und Familienbereichen.
• Eine gecustomizte Sperrseite, die dem Besucher mitteilt, warum eine Website blockiert wurde.
• Richtlinie für verschlüsseltes DNS. Legen Sie fest, wie der Dienst mit DNS over HTTPS (RFC 8484) und DNS over TLS (RFC 7858) umgeht, da diese die Filterung umgehen können.
• Protokollaufbewahrung abgestimmt auf Ihren GDPR-Plan. DNS-Protokolle, die mit einer angemeldeten Identität verknüpft sind, stellen personenbezogene Daten dar.
• Monatliches Reporting blockierter Bedrohungen pro Standort.

Die Sicherheits-Add-ons von Purple sind SecurePass, Verify und Shield. Fordern Sie eine Demonstration für jedes Add-on im Hinblick auf die oben genannten Klauseln an.

Anforderungen an Analytics und Integration

Bei der Beschaffung von Gäste-WiFi für Unternehmen werden Analysen oft unterbewertet, obwohl Sie genau hier Ihre Rendite erzielen. Spezifizieren Sie Folgendes:

• Metriken pro Standort und Gesamtbestand: Eindeutige Besucher, neue im Vergleich zu wiederkehrenden Besuchern, Verweildauer, Besuchshäufigkeit und Stoßzeiten.
• Dashboards und terminierte Berichte mit rollenbasierter Zugriffskontrolle, sodass Standortmanager nur ihren eigenen Standort sehen.
• Integrationen mit Ihren CRM- und Marketingplattformen über API oder native Konnektoren. Der Einwilligungsstatus muss mit jedem Datensatz übermittelt werden.
• Dateneigentum. Die First-Party-Daten gehören Ihnen. Ein vollständiger Export im CSV- oder JSON-Format muss jederzeit und beim Ausstieg ohne Zusatzkosten verfügbar sein.

Purple WiFi Analytics weist diese Metriken pro Standort aus und lässt sich in CRM- sowie Marketingplattformen integrieren.

Service-Levels und Zertifizierungen

• Verfügbarkeit. Fordern Sie ein monatliches Betriebszeit-SLA mit Gutschriften. Die Plattform von Purple läuft mit einer Verfügbarkeit von 99,999 %.
• Support. Spezifizieren Sie Zeiten, Reaktionszeiten nach Schweregrad und einen benannten Eskalationskontakt.
• Zertifizierungen. Setzen Sie ISO 27001 voraus. Verträge der zentralen britischen Regierung, in denen personenbezogene Daten verarbeitet werden, erfordern gemäß Procurement Policy Note 09/14 die Zertifizierung Cyber Essentials.
• Skalierungsreferenzen. Fordern Sie Referenzen Ihrer Größenordnung an. Purple betreibt über 80.000 aktive Standorte in mehr als 90 Ländern und hat im Jahr 2024 insgesamt 440 Millionen Anmeldungen verarbeitet (eigene Daten von Purple).

Bewertungsmatrix für Anforderungen

Bereich	Anforderung	Priorität	Anzufordernder Nachweis
Onboarding	Separates, nicht vorausgewähltes Marketing-Opt-in	Must	Portal-Screenshots und ein Beispiel für einen Einwilligungsexport
Onboarding	Captive Portal nach WCAG 2.2 AA	Must	Unabhängiger Prüfbericht zur Barrierefreiheit
Authentifizierung	Cloud-RADIUS mit Failover	Must	Architekturdiagramm und Verfügbarkeitsdaten der letzten 12 Monate
Authentifizierung	RadSec oder verschlüsselter RADIUS-Tunnel	Must	Designdokument
Authentifizierung	Passpoint und OpenRoaming	Should	Live-Referenzstandort
Verschlüsselung	WPA3 und Enhanced Open	Should	Pilottest auf Ihren APs
Hardware	Benannter Support für jede von Ihnen genutzte Plattform	Must	Integrationsleitfaden und Testergebnis des Pilots
GDPR	Auftragsverarbeitungsvertrag nach Art. 28 DSGVO und Kontrollen zur Aufbewahrung	Must	Unterzeichneter AVV und Demo der Aufbewahrungseinstellungen
PCI DSS	Gästedatenverkehr außerhalb der CDE	Must	Segmentierungsdesign und Nachweis zur Unterstützung von Tests
Protective DNS	Bedrohungs- und Kategorienfilterung mit Sperrseite	Must für den öffentlichen Sektor, Should für andere Bereiche	Live-Sperrtest und monatlicher Beispielbericht
Analysen	Vollständiger Datenexport bei Beendigung	Muss	Vertragsklausel und Muster-Exportdatei
Service	Uptime-SLA mit Service-Guthaben	Muss	SLA-Anhang

Wie überprüfen Sie, ob ein Anbieter liefern kann?

Evaluieren Sie in zwei Stufen: zuerst auf dem Papier, dann in einem Pilotprojekt. Jedes nicht erfüllte „Muss“-Kriterium führt zum Ausschluss des Anbieters in der Papierphase. Gewichten Sie die verbleibenden „Soll“-Kriterien entsprechend Ihren Prioritäten. Eine typische Aufteilung ist: Sicherheit und Compliance 30 %, Onboarding 20 %, Hardware 15 %, Analysen 15 %, Service 10 % und kaufmännische Aspekte 10 %.

Führen Sie ein 30-tägiges Pilotprojekt an zwei oder mehr Standorten auf unterschiedlichen Hardwareplattformen durch. Testen Sie jeden der folgenden Punkte und dokumentieren Sie das Ergebnis (bestanden / nicht bestanden).

• Das Captive Portal erscheint beim ersten Versuch auf iOS, Android, Windows und macOS.
• Ein wiederkehrender Gast wird beim zweiten Besuch erkannt.
• Ein Einwilligungsexport zeigt Zeitstempel und Version des Wortlauts an.
• Eine Löschaufforderung entfernt die Person von der Plattform und aus Ihrem verbundenen CRM.
• Die Authentifizierung läuft während eines simulierten Failovers von RADIUS weiter.
• Eine CoA-Nachricht beendet eine Sitzung ohne erneute Verbindung.
• Eine bekannte Testdomäne wird blockiert und Ihre Markenseite wird angezeigt.
• Ein Verbindungsversuch vom Gäste-VLAN zum Zahlungsnetzwerk schlägt fehl.

Testen Sie Durchsatz und Abdeckung getrennt von der Plattform. WiFi für das Internet: Funktionsweise und Prüfpunkte deckt die Grundlagen ab.

Wie sieht das in der Praxis aus?

Die drei folgenden Szenarien sind anschauliche Fallbeispiele, die aus allgemeinen Beschaffungsmustern abgeleitet wurden. Es handelt sich nicht um Kunden-Fallstudien.

Eine Gruppe mit 45 Hotels auf zwei Hardwareplattformen

Ausgangslage. Die Gruppe betrieb Cisco Meraki in 30 Hotels und HPE Aruba an 15 übernommenen Standorten. Jedes Portfolio verfügte über ein eigenes Captive Portal. An den 15 übernommenen Standorten wurde die Marketing-Einwilligung zusammen mit der Zustimmung zu den AGB eingeholt.

Maßnahme. Die Ausschreibung definierte beide Plattformen als „Muss“-Anforderungen. Sie forderte ein einziges Portal, einen zentralen Einwilligungsdatensatz und getrennte Opt-ins. Das Pilotprojekt umfasste jeweils ein Hotel pro Plattform.

Ergebnis. Zwei von fünf Anbietern erhielten keinen Zuschlag bei den Hardware-Kriterien, da sie nur eine Plattform unterstützten. Die siegreiche Overlay-Lösung ermöglichte es, alle 15 Aruba-Standorte auf ihren bestehenden APs zu belassen. Die gekoppelte Einwilligung wurde vor dem Go-live an allen 15 Standorten entfernt.

Eine Einzelhandelskette mit 120 Filialen im PCI-DSS-Geltungsbereich

Ausgangslage. Zahlungsterminals teilten sich in älteren Filialen die Switches mit den Gäste-APs. Das Gäste-WiFi lag daher innerhalb der PCI-DSS-Bewertung der Kette.

Maßnahme. Die Ausschreibung forderte ein dokumentiertes Segmentierungskonzept und die schriftliche Unterstützung für den Penetrationstest nach 11.4.5. Zudem wurde die Eingabe von Kartendaten auf dem Captive Portal untersagt.

Ergebnis. Der jährliche Segmentierungstest wurde in allen 120 Filialen bestanden. Das Gäste-WiFi fiel aus dem PCI-DSS-Geltungsbereich, was die Anzahl der vom Auditor zu prüfenden Systeme reduzierte.

Eine Kommunalverwaltung mit 25 Bibliotheken und Freizeitzentren

Ausgangslage. Die Verwaltung benötigte ein sicheres öffentliches WiFi für Familien, Cyber Essentials und eine barrierefreie Anmeldeseite.

So wurde es umgesetzt. Protective DNS war Voraussetzung, inklusive Kategorienfilterung für Kinderbereiche und einer verschlüsselten DNS-Richtlinie. DNS-Protokolle wurden gemäß dem Aufbewahrungsplan des Rats 90 Tage lang gespeichert.

Ergebnis. Drei von sieben Bietern erfüllten die WCAG 2.2-Kriterien nicht. Im Pilotprojekt wurde die Filterung eines in die engere Wahl gezogenen Bieters über DNS over HTTPS umgangen, was zu dessen Ausschluss führte.

Welche Fehler treten bei der Beschaffung von Gäste-WiFi auf und wie lassen sie sich beheben?

Jeder Bieter antwortet mit „Ja“

Ursache: Anforderungen beschreiben Funktionen statt Standards. Lösung: Nennen Sie für jede Zeile den jeweiligen RFC-, IEEE-Standard oder GDPR-Artikel und fordern Sie Nachweise ein.

Das Captive Portal wird nicht angezeigt

Ursache: Unvollständiges Walled Garden oder schwache Erkennung des Captive Portals. Lösung: Fordern Sie Unterstützung für RFC 8908 und RFC 8910 und testen Sie vier Betriebssysteme im Pilotprojekt.

Besucherzahlen wirken überhöht

Ursache: Randomisierte MAC-Adressen lassen ein Gerät wie mehrere erscheinen. Lösung: Verlangen Sie eine Wiedererkennung auf Basis der Anmeldeidentität und fordern Sie Bieter auf zu erklären, wie wiederkehrende Besucher gezählt werden.

Einwilligungen halten rechtlich nicht stand

Ursache: Opt-ins sind an allgemeine Bedingungen gekoppelt oder die angezeigte Formulierung wird nicht erfasst. Lösung: Verlangen Sie separate, nicht vorausgewählte Opt-ins und versionierte Einwilligungsprotokolle.

Ein Anbieterwechsel ist nicht möglich

Ursache: Keine Klausel zum Datenexport. Lösung: Fordern Sie bei Vertragsende den vollständigen Export in den Formaten CSV oder JSON ohne zusätzliche Kosten.

Der Vertrag erzwingt neue Hardware

Ursache: Ein Anbieter ist an eine bestimmte AP-Marke gebunden. Lösung: Eine hardwareneutrale Klausel, die jede von Ihnen genutzte Plattform namentlich aufführt.

Welche Kosten entstehen und welcher Nutzen ergibt sich daraus?

Kalkulieren Sie sechs Kostenpositionen ein: Softwarelizenzen, eventuelle Hardware, Installation, Internetanbindungen, Support sowie den Zeitaufwand Ihres eigenen Teams. Die gewählte Architektur macht hierbei den Hauptunterschied aus.

Ansatz	Hardwarekosten	Heterogene Multi-Vendor-Umgebung	Einwilligung und Daten	Änderung an jedem Standort
Cloud-Overlay auf bestehenden APs (Purple)	Keine: Läuft auf bestehenden APs	Ein zentrales Portal über Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet hinweg	Zentrale Einwilligungsprotokolle und First-Party-Daten in Ihrem Besitz	Konfiguration von SSID und RADIUS auf bestehenden APs
Integriertes Captive Portal des AP-Herstellers	Keine auf der aktuellen Plattform	Ein separates Portal für jede Hardwareplattform	Einwilligungs- und Besucherdaten werden auf jeder Plattform separat gehalten	Konfiguration wird auf jeder Plattform wiederholt
Managed Network mit Komplettaustausch („Rip-and-Replace“)	Neue APs und Lizenzen an jedem Standort	Ein einziger Hardware-Hersteller für den gesamten Bestand vorgeschrieben	Festgelegt durch die Vertragsbedingungen des Anbieters	Neuinstallation von APs an jedem Standort

Fordern Sie die Bieter auf, Angebote auf einer einheitlichen Basis zu erstellen: ein fester Jahrespreis pro Standort für die gesamte Laufzeit. Verlangen Sie eine detaillierte Aufschlüsselung der Kosten für Onboarding, Support, Updates und Vertragsende. Purple bietet Angebote auf Basis von drei Tarifen an: Connect, Capture und Engage, mit SecurePass, Verify und Shield als Sicherheits-Add-ons.

Der Ertrag stammt aus vier Bereichen. Sie gewinnen First-Party-Daten, die durch rechtmäßige Einwilligung abgesichert sind. Sie sehen Spitzenzeiten und Verweildauern, um Ihre Personalplanung zu optimieren. Sie vermeiden Hardwareausgaben durch das Overlay. Sie erhalten eine einzige Plattform zur Unterstützung statt mehrerer. Purple bietet dies seit 2012 an mehr als 80.000 aktiven Standorten.

Häufig gestellte Fragen

Kann eine Plattform für Gäste-WiFi auf den Access Points ausgeführt werden, die wir bereits besitzen?

Ja. Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Ihre APs verarbeiten weiterhin den Funk- und Datenverkehr. Purple stellt das Captive Portal, das Cloud-RADIUS, die Einwilligungsnachweise und die Analysen bereit. Nennen Sie in Ihrer Ausschreibung jede von Ihnen genutzte Plattform und verlangen Sie vor der Vergabe einen Pilotbetrieb auf Ihrer eigenen Firmware.

Wie sollten wir Anbieter in einer Ausschreibung bitten, Preise für Gäste-WiFi anzugeben?

Fordern Sie einen jährlichen Festpreis pro Standort für die gesamte Vertragslaufzeit an, wobei Add-ons separat aufgeschlüsselt werden. Verlangen Sie von den Bietern, dass Onboarding, Support, Software-Updates und der Datenexport bei Vertragsende enthalten sind und etwaige Hardwarekosten angegeben werden. Purple bietet Angebote für drei Tarife an - Connect, Capture und Engage - mit SecurePass, Verify und Shield als Sicherheits-Add-ons. So können Sie Angebote Zeile für Zeile vergleichen.

Fällt unser Gäste-WiFi-Netzwerk in den Anwendungsbereich von PCI DSS?

Das sollte es nicht, vorausgesetzt, es ist von Ihrer Karteninhaber-Datenumgebung segmentiert. PCI DSS v4.0 ermöglicht es Ihnen, den Anwendungsbereich durch Segmentierung zu reduzieren, aber Sie müssen nachweisen, dass sie funktioniert. Anforderung 11.4.5 fordert Penetrationstests der Segmentierungskontrollen mindestens alle 12 Monate. Legen Sie fest, dass der Gästedatenverkehr niemals Zahlungs-Systeme kreuzt und keine Kartendaten auf dem Captive Portal eingegeben werden.

Wer ist der Verantwortliche für Gäste-WiFi-Daten gemäß GDPR?

In der Regel sind Sie der Verantwortliche und der WiFi-Anbieter ist Ihr Auftragsverarbeiter. Der Vertrag benötigt daher eine Auftragsverarbeitungsvereinbarung gemäß Artikel 28, die Zweck, Sicherheit, Unterauftragsverarbeiter, Löschung und Benachrichtigung bei Verletzungen abdeckt. Ihre Ausschreibung sollte zudem exportierbare Einwilligungsnachweise und eine konfigurierbare Speicherdauer fordern. Fügen Sie Tools hinzu, um Auskunfts- und Löschanträge innerhalb der in Artikel 12 Abs. 3 festgelegten Monatsfrist zu beantworten.

Benötigen wir Passpoint oder OpenRoaming vom ersten Tag an?

Nein, aber Sie sollten eine kalkulierte Roadmap für beides verlangen. Ein Captive Portal bleibt die richtige Erstbesuchsoption, um Einwilligungen und First-Party-Daten zu erfassen. Passpoint und OpenRoaming ermöglichen wiederkehrenden Gästen anschließend eine automatische Verbindung über eine verschlüsselte 802.1X-Authentifizierung ohne Anmeldeseite. Purple unterstützt OpenRoaming, sodass Sie die automatische Verbindung später innerhalb desselben Vertrags hinzufügen können.

Sollte schützendes DNS Teil des Vertrags für Gäste-WiFi sein?

Ja, insbesondere für öffentliche Einrichtungen und familienfreundliche Standorte. Schützendes DNS verhindert, dass Geräte Domänen erreichen, die mit Malware, Phishing und Command-and-Control-Servern in Verbindung stehen. Es kann auch eine Kategorienfilterung pro Standort angewendet werden. Machen Sie dies zu einer Voraussetzung für Kommunen, Bibliotheken und Gesundheitseinrichtungen. Fordern Sie eine gebrandete Sperrseite, eine verschlüsselte DNS-Richtlinie, monatliche Berichte und eine Protokollspeicherung, die mit Ihrem GDPR-Zeitplan übereinstimmt.

Wie viel Unterbrechung verursacht der Wechsel von Gäste-WiFi-Plattformen?

Der Wechsel ist eine Konfigurationsänderung an jedem Standort und kein Hardwareprojekt, wenn die neue Plattform als Overlay läuft. Purple legt sich über die bestehende Infrastruktur, sodass Ihre APs, Verkabelungen und Leitungen erhalten bleiben. Führen Sie ein 30-tägiges Pilotprojekt an zwei Standorten mit unterschiedlicher Hardware durch und rollen Sie das System dann schrittweise aus. Exportieren Sie zuerst die Einwilligungsdaten aus der bisherigen Plattform, damit keine rechtmäßigen Opt-ins verloren gehen.

Warum nutzen wir nicht das Captive Portal, das in die Plattform unseres AP-Anbieters integriert ist?

Weil ein integriertes Portal das Onboarding, die Einwilligung und die Daten an eine einzige Hardwaremarke bindet. Standorte mit mehreren Filialen bleiben nach Übernahmen und Erneuerungszyklen selten auf einer einzigen Plattform. Eine unabhängige Plattform bietet ein einziges Portal, einen einzigen Einwilligungssatz und eine einzige Analyseansicht über alle Standorte hinweg, unabhängig von der Hardware. Das schützt Ihre Daten und Ihre Verhandlungsposition bei jeder zukünftigen Hardware-Erneuerung.