Device-Fingerprinting in einer Welt nach dem Cookie: die regulatorische und technische Landkarte 2026

Die Formulierung „Welt nach dem Cookie“ verdichtet zwei sehr unterschiedliche Geschichten zu einer, und diese Vermengung verursacht den größten Teil der Verwirrung um die Frage, ob Device-Fingerprinting 2026 noch tragfähig ist. Die eine Geschichte ist technisch: Browser haben Third-Party-Cookies erst eingeschränkt und dann entfernt und Ersatzmechanismen gebaut. Die andere ist rechtlich: Die Aufsichtsbehörden haben klargestellt, dass Fingerprinting denselben Regeln unterliegt wie Cookies. Beide Geschichten sind real, beide sind wichtig, und beide werden häufig als „Fingerprinting ist tot“ fehlgedeutet, während sie in Wahrheit etwas weitaus Konkreteres festlegen.

Dieser Beitrag kartiert beides — was sich in den Browsern geändert hat, was das Recht sagt und wie beide zusammenspielen — mit einem durchgehenden roten Faden: Der Zweck der Identifikation, nicht der Mechanismus, entscheidet sowohl über die technische Tragfähigkeit als auch über die rechtliche Stellung. Das Publikum sind Verantwortliche aus Datenschutz, Recht und Technik, die entscheiden, ob und wie sie Device Intelligence (Geräteintelligenz) einsetzen.

Was die „Welt nach dem Cookie“ tatsächlich beseitigt hat

Der Wandel nach dem Cookie hat Third-Party-Cookies beseitigt — den seitenübergreifenden Tracking-Mechanismus — und dabei den First-Party-Status sowie die First-Party-Geräteidentifikation unangetastet gelassen. Diese Unterscheidung ist die mit Abstand wichtigste Tatsache für die Beurteilung von Fingerprinting, und sie ist zugleich diejenige, die am häufigsten übersehen wird.

Ein Third-Party-Cookie wird von einer anderen Domain als der in der Adresszeile gesetzt und erlaubt es diesem Dritten, einen Nutzer über alle unzusammenhängenden Websites hinweg wiederzuerkennen, auf denen sein Code läuft. Das ist der Motor der seitenübergreifenden verhaltensbasierten Werbung, und genau ihn haben die Browser zerlegt. Ein First-Party-Cookie — gesetzt von der Website, die Sie tatsächlich besuchen, und nur von dieser lesbar — war nie das Ziel und funktioniert weiterhin.

Die Browser gingen unterschiedliche Zeitpläne mit unterschiedlichen Mechanismen, aber die Richtung war einheitlich: den seitenübergreifenden Third-Party-Status abtöten, die First-Party-Beziehung erhalten.

Safari (Intelligent Tracking Prevention). Apples ITP blockiert Third-Party-Cookies seit 2020 standardmäßig und hat die First-Party-Speicherlebensdauer für per Skript gesetzten Status zunehmend verkürzt, um Tracking-Umgehungen einzudämmen. ITP zielt gezielt auf den Anwendungsfall des seitenübergreifenden Trackings.

Firefox (Enhanced Tracking Protection / Total Cookie Protection). Firefox blockiert Third-Party-Tracking-Cookies standardmäßig und partitioniert den Speicher pro Website, sodass ein Dritter auf jeder Website einen eigenen Cookie-Behälter erhält statt einer gemeinsamen Identität über alle hinweg. Auch hier ist die seitenübergreifende Verknüpfung das Ziel.

Chrome (Privacy Sandbox). Chromes Weg war länger und umstrittener. Statt Third-Party-Cookies einfach zu blockieren, baute Google die Privacy Sandbox — eine Reihe zweckgebundener APIs (Topics für Interessensignale, Protected Audience für Remarketing, Attribution Reporting für Conversion-Messung), die Werbeergebnisse ohne seitenübergreifende Identifikatoren liefern sollen. Der Rollout, der Zeitplan der Abschaffung und der genaue Stand der nutzerseitigen Wahlmöglichkeit verschoben sich zwischen 2024 und 2026 wiederholt, doch die architektonische Absicht blieb bestehen: den seitenübergreifenden Identifikator durch aggregierte, datenschutzbeschränkte Mechanismen ersetzen. Die Auswirkungen speziell auf das Fingerprinting behandelt Auswirkungen der Privacy Sandbox.

Jeder einzelne dieser Ansätze zielt auf dasselbe: einen Dritten, der einen Nutzer über Websites hinweg wiedererkennt, die ihm nicht gehören. Keiner davon zielt — oder könnte zielen, ohne das Web zu zerstören — auf eine Website, die ihre eigenen Besucher auf ihren eigenen Seiten wiedererkennt. Genau in dieser Lücke lebt das Betrugs-Fingerprinting.

First-Party-Betrugs-Fingerprinting ist ein anderer Anwendungsfall

Fingerprinting zur Betrugsprävention ist von Natur aus First-Party und auf eine einzelne Website beschränkt: Eine Plattform identifiziert ihre eigenen Besucher auf ihren eigenen Seiten, um Sicherheitsentscheidungen zu treffen. Das ist grundverschieden vom seitenübergreifenden Werbe-Anwendungsfall, den die Browser zerlegt haben, und die Browser-Mechanismen schränken es nicht ein — weil sie es nicht können, ohne wesentliche Funktionalität zu zerstören, auf die jede Website angewiesen ist.

Überlegen Sie, was ein Browser zerstören müsste, um die First-Party-Geräteidentifikation zu unterbinden. Er müsste verhindern, dass eine Website die Merkmale des Browsers ausliest, der ihre eigenen Seiten rendert — Bildschirmgröße, Sprache, das Timing- und Rendering-Verhalten, das eine Website zum Funktionieren braucht, den Netzwerk-Stack, mit dem sie ohnehin schon spricht. Das sind keine Tracking-Haken; es ist die grundlegende Oberfläche, auf der eine Webanwendung läuft. Ihre Einschränkung zerstört legitime Funktionalität, deshalb schränken Browser die seitenübergreifende Kombination und den Missbrauch dieser Signale ein, nicht ihre First-Party-Beobachtung.

Deshalb ist die Unterscheidung zwischen Gerät und Cookie so wichtig. Ein Betrugssystem, das ein wiederkehrendes Gerät auf einer einzelnen Plattform identifiziert, rekonstruiert kein Third-Party-Cookie — es tut etwas, das Third-Party-Cookies ohnehin nie gut konnten: eine stabile, gegen Löschen resistente Identität für den eigenen Sicherheitszweck der Website erzeugen. Und das ganz ohne Cookies, was die gesamte Frage der Cookie-Abschaffung umgeht.

Das Verdikt zur technischen Tragfähigkeit ist daher eindeutig: Die Browser-Änderungen nach dem Cookie verringern das seitenübergreifende Fingerprinting (schwieriger, stärker eingeschränkt) und lassen das First-Party-Betrugs-Fingerprinting im Wesentlichen unangetastet. Ein Betrugssystem, das auf seitenübergreifendem Signalaustausch beruhte, wäre in Schwierigkeiten; eines, das um die First-Party-Geräteidentität herum aufgebaut ist, ist es nicht.

Was DSGVO und ePrivacy tatsächlich über Fingerprinting sagen

Das europäische Recht behandelt Device-Fingerprinting genauso wie Cookies: Es reguliert nach Zweck und nach dem Zugriff auf das Endgerät des Nutzers, nicht nach der spezifischen Technologie. Fingerprinting entgeht den Regeln nicht dadurch, dass es kein Cookie ist, und fällt auch nicht automatisch unter sie — die Prüfung hängt davon ab, warum Sie es tun.

Zwei Rechtsinstrumente greifen, und sie wirken nacheinander.

Die ePrivacy-Richtlinie (Artikel 5 Absatz 3) regelt das Speichern von Informationen im Endgerät eines Nutzers bzw. den Zugriff auf bereits dort gespeicherte Informationen. Das ist das „Cookie-Gesetz“, doch sein Wortlaut ist technologieneutral — er umfasst „Informationen“ und „Zugriff“, was die Aufsichtsbehörden (und die Leitlinien des Europäischen Datenschutzausschusses) durchgängig so ausgelegt haben, dass Fingerprinting-Techniken, die auf Gerätemerkmale zugreifen, eingeschlossen sind. Das Auslesen von Signalen eines Geräts fällt somit in den Anwendungsbereich der ePrivacy-Richtlinie, unabhängig davon, ob ein Cookie beteiligt ist.

Entscheidend ist: Artikel 5 Absatz 3 enthält Ausnahmen. Eine Einwilligung ist nicht erforderlich, wenn der Zugriff unbedingt erforderlich ist, um entweder eine Nachricht zu übermitteln oder einen vom Nutzer ausdrücklich gewünschten Dienst bereitzustellen. Sicherheit und Betrugsprävention, auf die der vom Nutzer angeforderte Dienst tatsächlich angewiesen ist, haben eine echte Grundlage für die Ausnahme der unbedingten Erforderlichkeit — ein Punkt, auf den weiter unten zurückgekommen wird.

Die DSGVO regelt die Verarbeitung aller daraus entstehenden personenbezogenen Daten. Ein Geräte-Fingerabdruck, der eine Einzelperson herausgreifen kann, ist ein personenbezogenes Datum, sodass seine Verarbeitung eine Rechtsgrundlage nach Artikel 6 benötigt. Die einschlägigen Grundlagen für die Betrugsarbeit sind berechtigte Interessen (Artikel 6 Absatz 1 Buchstabe f) — und die Erwägungsgründe der DSGVO selbst nennen die Betrugsprävention ausdrücklich als berechtigtes Interesse — sowie, wo einschlägig, eine rechtliche Verpflichtung. Hier liegt die detaillierte Compliance-Mechanik: Zweckbindung, Datenminimierung, Transparenz, Speicherbegrenzungen und eine dokumentierte Abwägung der berechtigten Interessen. Die praktische Ausgestaltung eines konformen Einsatzes ist in DSGVO-konformes Device-Fingerprinting dargelegt.

Die beiden Instrumente bauen aufeinander auf: Die ePrivacy-Richtlinie entscheidet, ob Sie eine Einwilligung für den Zugriff auf das Gerät benötigen, die DSGVO entscheidet, ob Sie eine Rechtsgrundlage für die Verarbeitung des Erlangten haben. Für die Betrugsprävention ist der plausible Weg die Ausnahme der unbedingten Erforderlichkeit der ePrivacy-Richtlinie plus die berechtigten Interessen der DSGVO — doch dieser Weg hat Bedingungen, und er ist nicht automatisch gegeben.

Braucht Betrugs-Fingerprinting eine Einwilligung?

Es hängt vom Zweck ab, und die Trennlinie ist scharf: Fingerprinting für Werbung, Analytik oder seitenübergreifendes Tracking braucht eine Einwilligung; Fingerprinting, das für einen vom Nutzer angeforderten Betrugspräventionsdienst unbedingt erforderlich ist, hat eine echte Grundlage, ohne dasselbe Opt-in zu arbeiten. Der Mechanismus ist in beiden Fällen identisch — die rechtliche Behandlung teilt sich vollständig an der Frage nach dem Warum.

Für die Zwecke Werbung und Analytik gibt es kein ernstzunehmendes Argument: Genau dafür wurde das Einwilligungserfordernis der ePrivacy-Richtlinie geschrieben, es ist für keinen vom Nutzer gewünschten Dienst unbedingt erforderlich, und es braucht eine vorherige informierte Einwilligung wie jedes Tracking-Cookie.

Für die Betrugsprävention ist der Fall für die Ausnahme der unbedingten Erforderlichkeit real, aber an Bedingungen geknüpft. Er trägt am stärksten, wenn:

• Das Fingerprinting wirklich erforderlich ist, um einen vom Nutzer angeforderten Dienst zu erbringen — seinen Login zu sichern, seine Zahlung zu schützen, die Übernahme seines Kontos zu verhindern. Die Sicherheit ist Teil dessen, was der Nutzer verlangt, wenn er den Dienst nutzt.
• Die Verarbeitung auf den Sicherheitszweck beschränkt bleibt und nicht für Marketing, Profiling oder etwas anderes zweckentfremdet wird, das der Nutzer nicht angefordert hat. Die Zweckbindung leistet hier echte Arbeit; in dem Moment, in dem derselbe Fingerabdruck Werbung speist, bricht das Argument der Ausnahme zusammen.
• Die Datenerhebung auf das beschränkt wird, was der Sicherheitszweck benötigt, die Speicherung begrenzt ist und die Verarbeitung dokumentiert und transparent ist (im Datenschutzhinweis offengelegt, auch wenn die Einwilligung nicht die Grundlage ist).

Das ist kein Schlupfloch und sollte auch nicht als solches behandelt werden. Es ist eine zweckgebundene Ausnahme, die nur so lange Bestand hat, wie der Zweck gebunden bleibt. Ein Betrugssystem, das seine Signale still in einen Werbe-Graphen einspeist, betreibt keine unbedingt erforderliche Sicherheitsverarbeitung mehr und verliert die Ausnahme. Die dauerhafte Position ist ein Betrugseinsatz, der genau das ist und bleibt, was er zu sein vorgibt: First-Party, sicherheitszweckgebunden, minimiert und vom Marketing getrennt.

Nichts davon ist eine Rechtsberatung, und die genaue Anwendung hängt von der Rechtsordnung, den nationalen ePrivacy-Umsetzungen, Branchenregeln und Ihrer konkreten Verarbeitung ab — die Darstellung hier ist die allgemeine regulatorische Gestalt, und ein realer Einsatz braucht seine eigene Abwägung der berechtigten Interessen sowie eine rechtliche Prüfung.

Die dauerhafte Architektur

Die Architektur, die sowohl den technischen als auch den rechtlichen Wandel übersteht, ist die, auf die das betrugsorientierte Fingerprinting bereits zusteuerte: First-Party, mit Gewicht auf serverseitigen Signalen, auf Sicherheit zweckgebunden und unabhängig von seitenübergreifenden Mechanismen.

Aus der obigen Landkarte folgen drei Design-Verpflichtungen.

Auf First-Party- und serverseitige Signale setzen. Die Browser-Änderungen schränken seitenübergreifende clientseitige Sonden am stärksten ein. Serverseitige Signale — Netzwerk-Stack-Fingerabdrücke, TLS-Merkmale, Verbindungsverhalten — werden von Ihrer eigenen Infrastruktur beobachtet, während der Nutzer sich mit Ihrem Dienst verbindet, sind von Natur aus First-Party und unterliegen nicht den clientseitigen Einschränkungen, die die Browser verschärfen. Ein System mit Gewicht auf diesen Signalen altert besser als eines, das auf clientseitigen Sonden aufbaut, die eingeschränkt werden könnten.

Den Zweck gebunden und sichtbar halten. Die rechtliche Tragfähigkeit hängt vollständig davon ab, innerhalb des Sicherheitszwecks zu bleiben. Das bedeutet: Betrugssignale nicht für Marketing zweckentfremden, keinen seitenübergreifenden Graphen aufbauen, die Verarbeitung im Datenschutzhinweis offenlegen, die Erhebung minimieren und die Speicherung begrenzen. Das ist kein nachträglich aufgesetzter Compliance-Ballast — es sind die Bedingungen, unter denen der gesamte Ansatz rechtmäßig ist.

Für das Kern-Verdikt nicht auf seitenübergreifenden Signalaustausch angewiesen sein. Anonymisierte, aggregierte kundenübergreifende Intelligenz kann die Erkennung stärken, doch die primäre Geräteidentität sollte allein auf First-Party-Signalen stehen, damit das System nicht auf den seitenübergreifenden Mechanismen ruht, die sowohl technisch eingeschränkt als auch rechtlich einwilligungspflichtig sind.

Ein so gebautes Betrugs-Fingerprinting-System ist wirklich post-cookie: Es verwendet keine Cookies, braucht sie nicht, verlässt sich nicht auf Third-Party-Status und fällt nicht auseinander, wenn die nächste Tracking-Schutzfunktion ausgeliefert wird — weil es von vornherein nie seitenübergreifendes Tracking betrieben hat.

Tracio ist genau auf diese Gestalt gebaut. Die Identität ist First-Party und cookielos, gewichtet über serverseitige Netzwerksignale und clientseitige Gerätesignale, auf Sicherheits- und Betrugsentscheidungen zweckgebunden, und sie speist keinen Werbe-Graphen. Sie ist darauf ausgelegt, durch Browser-Datenschutzänderungen hindurch stabil zu bleiben, weil sie nicht von den seitenübergreifenden Mechanismen abhängt, auf die diese Änderungen zielen. Für die detaillierte Compliance-Mechanik siehe den DSGVO-Einsatzleitfaden; das Glossar behandelt die zugrunde liegenden Konzepte.

Möchten Sie sehen, wie eine First-Party-, sicherheitszweckgebundene Geräteidentität zu Ihrer Datenschutz- und Compliance-Aufstellung passt?

Starten Sie Ihre kostenlose Testphase — 2.500 Verifizierungen gratis, keine Kreditkarte erforderlich. Buchen Sie eine Demo, um die Architektur und den Umgang mit Daten gemeinsam mit unserem Team zu prüfen.