Jeder Online-Dienst mit einem Registrierungsformular, einem Login oder einem Rabattcode zieht Missbrauch an: massenhaft angelegte Fake-Konten, Bots für Credential Stuffing, Scalper- und Scraper-Bots und Personen, die Willkommensboni, Empfehlungsguthaben oder Testzeiträume mit Dutzenden Identitäten abgreifen. Moderne Abwehr schichtet Bot-Erkennung am Rand, Geräte- und Verhaltenssignale, Graphanalyse verknüpfter Konten und einen Risikowert, der Zusatzprüfungen statt pauschaler Sperren auslöst. Betreiber sehen typischerweise geringere Missbrauchskosten, sauberere Marketingkennzahlen und weniger Verluste durch Support und Betrug – bei minimaler Reibung für echte Kunden.
Problem & Nutzen
- Wer betroffen ist: Webshops, Marktplätze, SaaS mit kostenlosen Stufen, Fintech-/Neobank-Apps, Gaming- und Social-Plattformen, Ticketing und Portale der öffentlichen Hand (z. B. gefälschte Registrierungen bei Bürgerdiensten). KMU spüren es als Spam-Registrierungen, ausgelesene Kataloge, Card Testing und abfließende Gutscheine; Großunternehmen als Kontoübernahme, Empfehlungsringe und aufgeblähte Akquisekosten.
- Heute: statische Regeln (IP-Sperrlisten, Ratenbegrenzung, „ein Gutschein pro E-Mail-Adresse“), CAPTCHAs und manuelle Prüfung. Angreifer umgehen diese mit Residential-Proxys, Wegwerf-E-Mail-Adressen, Anti-Detect-Browsern und zunehmend LLM-gesteuerten Agenten, die Formulare wie Menschen ausfüllen.
- KI-Nutzen: überwachte Modelle für bekannte Missbrauchsmuster, unüberwachte Anomalieerkennung für neue Kampagnen, Graphmodelle, die Konten über gemeinsame Geräte/Zahlungsmittel/Adressen verknüpfen, und LLMs zur Klassifikation von Freitext (Benutzernamen, Profiltexte, Nachrichten) und zum Entwurf von Fallnotizen.
- Ausmaß des Problems (vom Anbieter berichtet): Der Bad Bot Report 2025 von Imperva nennt für automatisierten Datenverkehr 51 % des gesamten Web-Traffics und für schädliche Bots 37 % [1]. Das ist eine Messung des Anbieters an der eigenen Kundenbasis; verstehen Sie sie als Anhaltspunkt, nicht als branchenweite Erhebung.
Varianten
- Fake-Konten / Registrierungsbetrug: Massenregistrierung für Spam, Manipulation von Bewertungen (siehe ANOM-010), Bonusabgriff oder späteren Betrug.
- Kontoübernahme und Credential Stuffing: Bot-Abwehr auf der Login-Seite (eng verwandt mit SEC-005 für interne Nutzer).
- Missbrauch von Aktionen / Gutscheinen / Empfehlungen / Testzeiträumen („Incentive Abuse“): Mehrfachkonten, Selbstempfehlungsringe, Rückgabe und Wiederverwendung von Gutscheinen (Retouren im Handel: ANOM-033).
- Scalping-, Scraping- und Bestandshortungs-Bots: Ticketing, Sneaker-Drops, Preis-Scraping.
- Community-/Social-Plattformen: Netzwerke unauthentischen Verhaltens, Spam-Bots; Trust-and-Safety-Abläufe. VLMs und Textklassifikatoren helfen bei Profilbildern und Nachrichten.
- Gaming: Bot-Farmen und Ringe von Cheat-Konten (siehe ANOM-036).
- Öffentlicher Sektor / KMU-Light: Schutz vor Spam in Kontaktformularen und Registrierungen mit datenschutzfreundlichen CAPTCHAs auf Basis von Proof-of-Work.
- Datenverkehr von KI-Agenten: legitime, deklarierte KI-Agenten (Shopping- oder Recherche-Agenten) von missbräuchlichen unterscheiden – eine neue Grundsatzfrage 2025/26 und keine reine Erkennungsaufgabe.
So funktioniert es
- Client-/Edge-Telemetrie (HTTP, TLS-Fingerprint, JS-Challenge, Geräte-Signale, IP/ASN-Reputation)
- Bot-Management-Schicht (Positivliste verifizierter Bots, Proof-of-Work / verwaltete Challenge)
- Ereignisstrom (Registrierung, Login, Checkout, Einlösung) + Feature Store (Geschwindigkeit, Entropie von E-Mail/Benutzername, Geräte-Wiederverwendung)
- Bewertung: Regeln + Gradient-Boosted Trees + Anomalie-Detektoren + Textklassifikator
- Entitätsgraph (Gerät, IP, E-Mail, Telefon, Karte, Adresse, Empfehlungscode)
- Community Detection / GNN-Scoring von Ringen
- Entscheidungsmaschine: zulassen | Step-up (E-Mail/SMS/MFA/Ausweisprüfung) | drosseln | Shadow-Ban | blockieren
- manuelle Prüfwarteschlange (vom LLM vorbereitete Fallzusammenfassung, Begründungscodes)
- Feedback-Labels (Rückbuchungen, bestätigter Missbrauch, Widersprüche)
- Nachtraining & Regelanpassung
- Bot-Schicht: verwaltete Challenges und nicht-interaktive Proof-of-Work-Prüfungen ersetzen Bilderrätsel; verifizierte Crawler und signierte Agenten stehen auf einer Positivliste (z. B. über Web Bot Auth, ein auf einem IETF-Entwurf beruhendes Verfahren mit signierten HTTP-Nachrichten [3]).
- Bewertung: Gradient Boosting (XGBoost/LightGBM) auf Geschwindigkeits- und Gerätemerkmalen bleibt das Arbeitspferd; Detektoren im Stil von Isolation Forest/Autoencoder (z. B. die 61 Detektoren in PyOD [4]) erfassen neue Kampagnen, wo Labels knapp sind.
- Graphschicht: Konten über gemeinsame Kennungen verknüpfen; Label Propagation und GNN-Modelle (z. B. die in DGFraud gesammelten [5]) ordnen Ringe für die Prüfung im Stapel nach Priorität.
- LLMs: klassifizieren Benutzernamen, Profiltexte und Bewertungstexte; fassen die Belege eines Kontos für Analysten zusammen; entwerfen Antworten auf Widersprüche. Sie sind nicht der primäre Detektor – Latenz und Kosten passen nicht zu Entscheidungen pro Anfrage.
- Mensch-in-der-Schleife (Human-in-the-Loop): Grenzwertige Scores gehen in die Prüfung; dauerhafte Sperren oder die Verweigerung eines bezahlten Dienstes erfordern dokumentierte Gründe und einen Widerspruchsweg.
Datenaufbereitung
Benötigte Daten: Registrierungs- und Anmeldeereignisse, IP- und Gerätesignale, E-Mail- und Telefonattribute, Einlösungen von Gutscheinen oder Aktionen, Bestellungen und Erstattungen sowie Ergebnisse früherer Sperren oder Beschwerden als Labels. Sie liegen im Backend des Shops oder der App, in Webserver-Logs, im CRM und beim PSP. Typische Lücken: Logs sind kurzlebig oder nicht zentralisiert, Konten und Geräte sind nicht verknüpft, Missbraucher werden nie markiert, und die Einwilligung für Geräte-Fingerprinting fehlt.
Aufbereitungsschritte: Ereignisprotokolle zentralisieren (PREP-005), Konten über stabile Kennungen verknüpfen, Labels aus gesperrten Konten und erstatteten Aktionen gewinnen (PREP-020), Missbrauchskategorien festlegen (PREP-019) und IPs und Kennungen für die Analyse pseudonymisieren (PREP-022). Die Rechtsgrundlage für Geräte- und Verhaltensdaten prüfen (PREP-025). Für Weg A genügen meist ein sauberer Ereignis-Feed und ein Weg, Fehlalarme zu melden. Siehe DATA-003.
Grober Aufwandsanteil: 20–30 Prozent bei Weg A, 40 Prozent bei Weg B und C.
Umsetzungswege
Welcher Weg für wen
- KMU: Weg A, weil Bot-Management, CAPTCHA und Risikosignal-Dienste ausgereifter (teils in der EU gehosteter) Anbieter den Standardprozess kostengünstig abdecken.
- Großunternehmen: Weg B, weil große Plattformen eigene Missbrauchsmuster und eigene Verhaltensdaten haben und Anbietersignale daher mit hauseigener Bewertung und Regeln kombiniert werden.
- Entwickler: Weg C, weil quelloffene Werkzeuge für Regeln, Graph und Anomalien auf HW1 volle Kontrolle über Merkmale und Schwellenwerte geben.
- Öffentlicher Sektor: Weg C, weil öffentliche Portale souveränes Hosting und vergabekonforme Komponenten für den Schutz von Bürgerkonten brauchen.
Weg A — Kaufen (für die meisten KMU und den gehobenen Mittelstand empfohlen)
- Datenschutzfreundliches CAPTCHA / Proof-of-Work: Friendly Captcha (deutsch, Option auf EU-Rechenzentrum, ohne Cookies, Herstellerangabe) [6]; ALTCHA (Open Source, selbst hostbar, cookie-frei) [7]; Cloudflare Turnstile (nicht-interaktive Challenges, nutzbar, ohne den Datenverkehr über Cloudflare zu leiten) [2]; hCaptcha (Bot-Erkennung für Unternehmen, Account Defense, „Zero-PII“-Aussage, Herstellerangabe) [8].
- Bot-Management / WAF: Cloudflare Bot Management, Akamai, Imperva (Thales), HUMAN Security, DataDome (französisch), Arkose Labs, Kasada, Netacea (UK).
- Betrugs-/Missbrauchsplattformen: Sift, Forter, Riskified, Feedzai, Sardine, DataVisor, EU-Spezialisten im Stil von Fraugster sowie SEON (Ungarn/EU) für leichtgewichtige Anreicherung und Bewertung von E-Mail/Telefon/IP. Zahlungsdienstleister (Stripe Radar, Adyen RevenueProtect) decken Missbrauch beim Checkout ab.
- Wählen Sie A, wenn: es kein eigenes Data-Science-Team gibt, Missbrauch ein Kostenfaktor und kein Kernrisiko ist und ein AVV des Anbieters mit Verarbeitung in der EU verfügbar ist. Prüfen Sie Aussagen mit einem Pilotversuch auf Ihrem eigenen Datenverkehr; die „Reduktion des Angriffsvolumens“ der Anbieter sind Werbezahlen.
Weg B — Auf Cloud-KI-Diensten aufbauen
- Signale als APIs: Reputation von E-Mail/Telefon/IP (z. B. SEON, Twilio Lookup, MaxMind), verwaltete Challenges (Turnstile, hCaptcha), Cloud-ML (Nachfolger von Amazon Fraud Detector, Google reCAPTCHA Enterprise, Azure-Dienste mit EU-Regionen).
- Bewertung: Gradient-Boosting-Modelle auf Ihren eigenen Ereignisprotokollen in einem verwalteten ML-Dienst trainieren (Vertex AI, SageMaker, Azure ML – EU-Regionen); LLM-Aufrufe (Claude, Mistral, Gemini, GPT über EU-Endpunkte) für Textklassifikation und Zusammenfassungen für Analysten.
- Orchestrierung: Ereignisse über Kafka/Kinesis/Pub/Sub streamen, in einer Regel-Engine entscheiden, Fälle an n8n/Power Automate/Ticketing übergeben.
- Wählen Sie B, wenn: Sie Entwickler und eigene Missbrauchsmuster haben, aber keine On-Premises-Vorgabe besteht.
Weg C — Selbst betreiben (Open Source)
- Bot-Abwehr: CrowdSec (MIT-lizenziertes IDS/IPS/WAF mit Proof-of-Work-Bot-Challenge und Community-Sperrlisten [9]), ModSecurity/Coraza mit dem OWASP Core Rule Set, ALTCHA, Proof-of-Work-Gateways im Stil von Anubis, Ratenbegrenzung mit Nginx/HAProxy.
- ML: XGBoost/LightGBM, scikit-learn, PyOD [4], PyG/DGL für Graphen, Neo4j oder Memgraph für Entitätsgraphen, Redis/Feast für Merkmale, Flink oder Kafka Streams fürs Streaming.
- LLM (optional): ein kleines Open-Weight-Modell (z. B. Qwen3 oder Mistral/Ministral-Klasse, ≤ 8B) für die Textklassifikation; Embeddings für nahezu doppelte Profiltexte.
- Hardware: HW1 (CPU-Server) genügt für die meisten Lasten; HW2 nur für GNN-Training oder lokale LLMs ergänzen.
- Wählen Sie C, wenn: Daten On-Premises bleiben müssen (öffentlicher Sektor, Banken) oder die SaaS-Preise pro Anfrage bei sehr hohem Datenverkehr unbezahlbar sind.
Weg D — Eigenes Training
Lohnt sich für große Plattformen mit besonderem Missbrauch: Sequenzmodelle auf Klick-/Tipp-Telemetrie trainieren, GNNs auf dem Kontengraphen oder einen kleinen Encoder auf Ihren gelabelten Spam-Texten feintunen. Es braucht Tausende bestätigter Missbrauchs-Labels (schwierig, weil Labels verzögert eintreffen und durch frühere Regeln verzerrt sind), zeitbasierte Validierung und einen Prozess für gegnerische Drift (wöchentlich bis monatlich neu trainieren/kalibrieren). Die meisten KMU sollten hier nicht beginnen.
Stand der Technik (2026)
- Vom CAPTCHA zu unsichtbaren Risikosignalen: Prüfungen ohne Challenge, auf Basis von Proof-of-Work sowie Verhalten/Telemetrie sind Standard; Bilderrätsel sind weitgehend nur noch die Rückfalloption, weil KI-Löser sie überwinden.
- Datenverkehr von Agenten ist die neue Front: LLM-gesteuerte Browser-Agenten laufen in echten Browser-Engines und wirken auf Netzwerkebene menschlich; Werkzeuge, die nur auf der Netzwerkschicht ansetzen, übersehen sie [Kaufberatung von Anbietern, z. B. 10]. Kryptografische Identifikation von Bots (Entwürfe zu Web Bot Auth) lässt Websites deklarierte Agenten prüfen, ist aber noch in Arbeit [3].
- Graph-zuerst-Erkennung findet Ringe, die die Bewertung einzelner Konten übersieht; die Wirtschaftlichkeit bei Aktionsmissbrauch verbessert sich am meisten durch das Verknüpfen von Konten, nicht durch strengere Regeln für Einzelkonten.
- Die Kombination überwachter und unüberwachter Verfahren mit schneller Rückmeldung bleibt besser als jedes Einzelmodell; öffentliche Betrugsdatensätze (z. B. IEEE-CIS) betreffen Zahlungen, daher gibt es keinen offenen Standard-Benchmark für Registrierungsmissbrauch – seien Sie skeptisch gegenüber Genauigkeitsangaben der Anbieter.
- Grenzen und Fehlerbilder: Fehlalarme treffen datenschutzbewusste Nutzer (VPN, Tor, gehärtete Browser), gemeinsam genutzte IPs (CGNAT, Hochschulen) und Hilfsmittel der Barrierefreiheit; Angreifer passen sich binnen Tagen an; Labels treffen verzögert ein; Verhaltensbiometrie wirft Fragen zu DSGVO und Verzerrung auf; das Aussperren deklarierter KI-Agenten kann legitime Umsätze kosten.
Gemeinsame Bausteine & Kombinationen
- Gemeinsame Bausteine: tabular-ml + anomaly-detection + streaming + graph-ml sind derselbe Stack wie bei Zahlungsbetrug (ANOM-001), Betrug bei Retouren/Kasse im Handel (ANOM-033), Werbebetrug (ANOM-027) und UEBA (SEC-005). Ein Feature Store und ein Ereignisstrom auf HW1 können alle bedienen.
- Kombinieren mit: ANOM-014 (Dokumenten-/Lebendigkeitsprüfung als Zusatzprüfung bei verdächtigen Registrierungen), ANOM-010 (gefälschte Bewertungen aus denselben Ringen), ANOM-036 (Cheat-Konten in Spielen), SEC-021 (gefälschte Shops/Profile außerhalb Ihrer Plattform), SEC-010 (Leitplanken, wenn Sie LLM-Agenten oder Chatbots gegenüber Bots öffnen), ANOM-025 (Betrugsschutz für Verbraucher; Betrüger beginnen oft mit gefälschten Konten).
- LLM-Komponenten (Textklassifikation, Fallzusammenfassungen) teilen sich das Bereitstellen kleiner Modelle mit Anwendungsfällen für Ticket-Triage und Moderation.
Aufwand, Kosten & Kennzahlen
- Weg A: Tage bis Wochen; Abonnement oder Preis pro Anfrage; Werkzeuge der CAPTCHA-Klasse sind bei kleinen Mengen günstig oder kostenlos.
- Weg B: 2–4 Monate für eine produktive Pipeline mit Rückmeldeschleife; die Gebühren für Cloud-ML und Anreicherungs-APIs wachsen mit dem Datenverkehr.
- Weg C: 3–6 Monate; Engineering plus Betrieb; bei großem Volumen günstig pro Anfrage.
- Weg D: Quartale; eigenes Data-Science-Team.
- Kennzahlen: Fake-Konto-Rate nach 7/30 Tagen, Bot-Anteil am Datenverkehr, Missbrauchskosten je 1.000 Registrierungen, Abfluss durch Aktionen, Fehlalarmrate und Challenge-Rate bei echten Nutzern, Abschlussrate der Zusatzprüfungen, Auswirkung auf die Konversion (A/B-Holdout), Zeit bis zur Erkennung einer neuen Kampagne, Trefferquote der manuellen Prüfung, Quote aufgehobener Entscheidungen nach Widerspruch.
Menschen & Veränderung
Binden Sie die Geschäftsleitung ein (Risikobereitschaft gegenüber Konversion), die Abteilungsleitung (Wachstum, Marketing, Support) als Prozessverantwortliche, IT und IT-Sicherheit für die Integration sowie die/den Datenschutzbeauftragte(n) für die Regeln zu Fingerprinting und Tracking (Einwilligung nach TTDSG und DSGVO). Support-Teams brauchen einen klaren Weg, zu Unrecht markierte Kunden wieder freizuschalten.
Betriebsrat: im Normalfall nein, weil das System Kunden und Registrierungen analysiert, nicht das Verhalten von Beschäftigten; es wird relevant (§ 87 Abs. 1 Nr. 6 BetrVG), wenn Analysten-Dashboards die Leistung von Support-Mitarbeitenden messen, und § 90 Abs. 1 Nr. 3 verlangt weiterhin die rechtzeitige Unterrichtung über KI-gestützte Prozesse, wo sich Arbeitsabläufe der Beschäftigten ändern.
Datenschutz: Profiling von Nutzern in großem Umfang und Geräte-Fingerprinting machen eine DSFA wahrscheinlich (Art. 35 DSGVO); AVV mit Anbietern. KI-Kompetenz: Unterstützen Sie die Missbrauchs- und Support-Teams mit kurzen Schulungen zu Scores und zum Umgang mit Fehlalarmen (Art. 4 KI-Verordnung). Pilotbetrieb: einige Wochen nur im Überwachungsmodus laufen lassen, eine Stichprobe mit Support-Mitarbeitenden prüfen und erst weiche Maßnahmen (zusätzliche Verifizierung) durchsetzen, bevor harte Sperren folgen. Typische Sorge: „Echte Kunden werden ausgesperrt“; begegnen Sie ihr mit Zusatzprüfungen statt Sperren, einem Widerspruchskanal und der Kennzahl Fehlalarmrate. Siehe GUIDE-005, GUIDE-009 und GUIDE-011.
Risiken, Regulierung & Compliance
- KI-Verordnung (AI Act): typischerweise minimales Risiko. Anhang III (z. B. Kreditwürdigkeit) nimmt Systeme zur Aufdeckung von Finanzbetrug ausdrücklich aus der Kategorie Kredit-Scoring aus [11], und Bot- oder Missbrauchs-Scoring ist für sich nicht aufgeführt. Prüfen Sie Grenzfälle: Biometrische Kategorisierung oder Emotionserkennung aus Verhalten würde in regulierte oder verbotene Bereiche (Art. 5) führen und sollte nicht eingesetzt werden; biometrische Fernidentifizierung liegt hier außerhalb des Umfangs (zur Eins-zu-eins-Verifizierung siehe ANOM-014). Verweigert eine Plattform über den Score den Zugang zu wesentlichen Diensten (Leistungen, Versicherung), kann das System zum Hochrisiko-System werden.
- DSGVO: IP-Adressen, Geräte-IDs, Verhaltensdaten und Kontengraphen sind personenbezogene Daten. Berechtigtes Interesse (Art. 6 Abs. 1 Buchst. f, Erwägungsgrund 47 zur Betrugsprävention) ist die übliche Grundlage, braucht aber eine dokumentierte Interessenabwägung; Speicherdauer minimieren und Zwecke dokumentieren. Führt ein Score allein zu einer erheblichen Beeinträchtigung, machen Art. 22 und das SCHUFA-Urteil des EuGH (C-634/21) zum automatisierten Scoring menschliche Prüfung und Erklärung erforderlich. Führen Sie bei umfangreichem Profiling eine DSFA durch.
- ePrivacy (Art. 5 Abs. 3): Das Auslesen von Informationen vom Endgerät des Nutzers (Fingerprinting, Telemetrie-Skripte) erfordert grundsätzlich eine Einwilligung, sofern es nicht unbedingt erforderlich ist; die EDPB-Leitlinien 2/2023 stellen den weiten technischen Anwendungsbereich klar [12]. Bevorzugen Sie serverseitige Signale und Proof-of-Work-Ansätze, die das Speichern/Auslesen von Gerätedaten vermeiden.
- DSA (EU) für Plattformen: Online-Plattformen müssen Maßnahmen gegen Missbrauch ergreifen und für Kontobeschränkungen Melde- und Abhilfeverfahren sowie Begründungen vorsehen; halten Sie Gründe und Widersprüche dokumentiert.
- Branchenregeln: Banken und Zahlungsunternehmen (PSD2/PSD3-Betrugsüberwachung, DORA-IKT-Governance, AML-Onboarding); verbraucherrechtliche Fairness der Aktionsbedingungen.
- Gegenmaßnahmen: abgestufte Reaktionen (Challenge vor Sperre), Begründungscodes, Prüfprotokolle, Verzerrungsprüfungen nach Region/ASN/Gerät, Holdout-Bewertung, AVV und Verarbeitung in der EU, kein seitenübergreifendes Tracking.
Erste Schritte
- Das Problem beziffern: Fake-Konto-Rate, Kosten je Einlösung einer Aktion, Bot-Anteil am Datenverkehr, Anteil der durch Missbrauch verursachten Support-Tickets.
- Eine reibungsarme Bot-Schicht vor Registrierung, Login und Checkout setzen (Turnstile, Friendly Captcha oder ALTCHA) und Ratenbegrenzungen sowie Prüfungen auf Wegwerf-E-Mail-Adressen ergänzen.
- Alle Ereignisse mit stabilen IDs und Ergebnissen protokollieren; eine gelabelte Missbrauchstabelle beginnen (bestätigter Ring, Rückbuchung, manuelle Sperre).
- Einen Gradient-Boosting-Risikowert plus einen einfachen Entitätsgraphen (Verknüpfungen über Gerät/Zahlungsmittel/Adresse) ergänzen und im Schattenmodus neben den Regeln laufen lassen.
- Abgestufte Maßnahmen und eine Prüfwarteschlange mit Widerspruchsweg einführen; die DSFA bzw. Prüfung des berechtigten Interesses vor der Durchsetzung schreiben.
Quellen
- Imperva — 2025 Bad Bot Report — https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
- Cloudflare — Turnstile documentation — https://developers.cloudflare.com/turnstile/
- Cloudflare — Web Bot Auth documentation — https://developers.cloudflare.com/bots/concepts/bot/verified-bots/web-bot-auth/
- PyOD — anomaly detection library documentation — https://pyod.readthedocs.io/en/latest/
- safe-graph — DGFraud, graph-based fraud detection toolbox — https://github.com/safe-graph/DGFraud
- Friendly Captcha — product and privacy information — https://friendlycaptcha.com/
- ALTCHA — open-source proof-of-work CAPTCHA alternative — https://github.com/altcha-org/altcha
- hCaptcha Enterprise — https://www.hcaptcha.com/
- CrowdSec — open-source IDS/IPS, WAF and bot detection — https://github.com/crowdsecurity/crowdsec
- Arkose Labs — bot and fraud prevention vendor — https://www.arkoselabs.com/
- EU AI Act — Annex III, high-risk systems — https://artificialintelligenceact.eu/annex/3/
- EDPB — Guidelines 2/2023 on the technical scope of Art. 5(3) ePrivacy Directive — https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en