Aufgabe: „Zielkonfiguration aus dem Ärmel schütteln“
Meine Frage an Sie: Wie viel wird diese Migration am Ende kosten?
Und vor allem: Wie viel hätte man gespart, wenn man mich 6 Monate früher gefragt hätte?
Das Geschäftsmodell „Künstliche Komplexität“
Nach 35 Jahren Enterprise Architecture habe ich verstanden: Der deutsche IT-Markt lebt nicht von Lösungen. Er lebt von permanent beschäftigten Feuerwehren.
Die Mechanik ist simpel:
Phase 1: Vendor erhöht Preise (VMWare/Broadcom ist nur das neueste Beispiel)
Phase 2: Panik-Migration wird gestartet – ohne Gap-Finding, ohne Risiko-Assessment
Phase 3: Mittendrin merkt man: „Das ist komplexer als gedacht“
Phase 4: „Wir brauchen einen Senior Enterprise Architekten – SOFORT“
Phase 5: Teurer Notfall-Einsatz, halbgare Lösung, neue Abhängigkeiten
Phase 6: In 18 Monaten wiederholt sich das Spiel
Jede Phase generiert Umsatz. Für alle Beteiligten. Außer für den Auftraggeber.
Was ich in den ersten 2 Tagen gefunden hätte
Bei dieser konkreten Anfrage hätte ein 2-Tages-Assessment vermutlich ergeben:
Problem 1: Die 27 Leistungsscheine entstehen aus historisch gewachsener Service-Fragmentierung → Konsolidierung spart 40-60% Migrationskomplexität
Problem 2: Die „weltweiten Standorte“ nutzen wahrscheinlich 4-5 verschiedene Netzwerk-Architekturen → Standardisierung VORHER macht Migration trivial
Problem 3: Die VMWare-Umgebung läuft vermutlich auf überalterter Hardware mit jahrelang akkumuliertem Konfigurations-Debt → Clean-up vor Migration spart Wochen
Kostendifferenz zwischen „3 Wochen Feuerwehr“ und „2 Tage Gap-Finding“:
Mit Feuerwehr: €500K-800K Migration, 6-12 Monate Stabilisierung, neue Lock-ins
Mit Gap-Finding: €150K-250K Migration, 2-3 Monate Stabilisierung, echte Flexibilität
Das nennt man ROI von 3:1 bis 5:1. In zwei Tagen.
Warum zahlt niemand dafür?
Weil das System gegen präventive Intelligenz optimiert ist:
IT-Dienstleister verlieren 70% Umsatz, wenn Probleme gar nicht entstehen
Procurement verliert Daseinsberechtigung, wenn 27 Leistungsscheine auf 8 schrumpfen
Internal IT muss zugeben, dass man jahrelang Komplexität akkumuliert hat
Vendor verliert Lock-in-Macht, wenn echte Architektur Flexibilität schafft
Mein Name dafür: „Artificially Increased Emergence“
Komplexität, die nicht aus technischer Notwendigkeit entsteht, sondern aus wirtschaftlichen Interessen BEWUSST aufrechterhalten wird.
Die Rechnung für Portfolio-Eigentümer
Wenn Sie ein PE-Portfolio mit 15 Unternehmen haben:
Durchschnittlich 2-3 solcher „Notfall-Projekte“ pro Jahr und Portfolio-Firma
Durchschnittliche Mehrkosten durch fehlende Gap-Finding: €300K-500K pro Projekt
Portfolio-weite Verschwendung: €9M-22M pro Jahr
Und das ist nur die IT. Manufacturing, Supply Chain, Compliance – überall dieselbe Mechanik.
Was wäre nötig?
Ein Scharnier. Jemand, der NICHT vom Chaos lebt.
Jemand, der:
Vor Vendor-Panik die echten Abhängigkeiten findet
Vor Migrations-Projekten die Kosten-Treiber eliminiert
Vor Consulting-Orgien die vermeidbaren Probleme löst
Das ist kein „Senior Enterprise Architekt für 3 Wochen“.
Das ist ein 2-Tages-Investment, das 6-stellige Summen spart.
Aber dieser Rolle fehlt der Business Case – weil sie zu viele andere Business Cases zerstört.
Meine Frage an Sie
Wenn Sie ein Portfolio-Unternehmen haben, das gerade:
Einen „kritischen“ Cloud-Migration plant
„Dringend“ ein SAP S/4HANA-Projekt startet
„Sofort“ eine Cybersecurity-Initiative braucht
Wie sicher sind Sie, dass das wirklich kritisch, dringend, sofort ist?
Oder bezahlen Sie gerade jemanden, dessen Geschäftsmodell auf artificially increased emergence basiert?
Michael Schmid
Enterprise Architect | Spezialist für Gap-Finding
35 Jahre Erfahrung mit Telekom-Netzen, Automotive, Defense
it-dialog e.K., Stuttgart
„Ich baue Systeme, die 39 Jahre laufen. Ich werde nicht dafür bezahlt, Feuer zu löschen – sondern sie zu verhindern. Das macht mich unbeliebt bei Feuerwehren, aber wertvoll für Eigentümer.“
P.S.: Die Anfrage habe ich abgelehnt. Nicht weil ich die 3 Wochen nicht ausfüllen könnte. Sondern weil ich in 2 Tagen zeigen würde, dass 90% davon vermeidbar gewesen wäre. Und das will niemand hören, der vom Chaos lebt.
Möchten Sie wissen, wo in Ihrem Portfolio künstliche Komplexität Millionen verbrennt?
Sprechen Sie mich an: info@it-dialog.com
Kommentare und Shares willkommen – besonders wenn Sie anderer Meinung sind.
[Dieser Artikel vertieft meinen LinkedIn-Post vom 26. Oktober 2024]
PKI interne Netzwerke sind heute ein Albtraum für jeden IT-Administrator. Was eigentlich eine simple Sicherheitsanforderung sein sollte – verschlüsselte Kommunikation im Firmennetz – ist zu einer komplexen Herausforderung mutiert, für die es keine einfache Lösung gibt.
🧠 Nachgedacht: Wenn man heute im Firmennetz sicher verschlüsseln will, braucht man eine eigene Zertifizierungsstelle – sonst geht es schlicht nicht. Öffentliche Anbieter dürfen keine Zertifikate für interne Netze ausstellen. Selbstsignierte Zertifikate werden blockiert. Warum gibt es dafür kein fertiges, einfaches Produkt? Eine kleine Box, die man einmal einrichtet, prüft, ins Regal stellt – und fertig ist die interne Vertrauensbasis. Ist das wirklich so kompliziert – oder haben wir uns nur daran gewöhnt, dass es das nicht gibt?
Die Reaktionen auf diesen Post waren erhellend. Ein Experte kommentierte mit einer Liste von Lösungen – jede mit einem „wenn“: „Man kann… wenn man einen DNS-Namensraum fährt… wenn man ACME-Automatisierung hat… wenn man als Trusted Roots ausrollt…“
Genau das ist das Problem.
Der Hintergrund: Wie wir hier gelandet sind
2015 traf das CA/Browser Forum eine folgenreiche Entscheidung: Öffentliche Zertifizierungsstellen dürfen keine Zertifikate mehr für interne Domains (wie .local), private IP-Adressen oder nicht-routbare Netzwerke ausstellen. Die Begründung war nachvollziehbar – es ging um die Verhinderung von Domain-Hijacking und Man-in-the-Middle-Attacken.
Was dabei übersehen wurde: Millionen von Unternehmen betreiben interne Systeme, die niemals das Internet sehen werden. Produktionsanlagen, Steuerungssysteme, interne Datenbanken – sie alle benötigen verschlüsselte Kommunikation. Die Lösung? Jedes Unternehmen muss seine eigene PKI aufbauen.
PKI interne Netzwerke: Warum aus Sicherheit Raketenwissenschaft wurde
In meinen 35 Jahren in der IT habe ich viele Technologien kommen und gehen sehen. Aber selten habe ich erlebt, dass eine grundlegende Sicherheitsanforderung so unnötig verkompliziert wurde wie die interne PKI.
PKI interne Netzwerke versagen: Wenn Server die Verbindung verweigern
Das eigentliche Problem ist noch gravierender als die meisten ahnen: Moderne Server und Anwendungen lehnen unverschlüsselte Verbindungen zunehmend kategorisch ab. Nicht aus Böswilligkeit, sondern aus Sicherheitsgründen.
Bei einem Kunden (Energie) weigerte sich die neue Version der ERP-Software, mit den Um-Systemen zu kommunizieren. Der Grund? Man hatte nur ein selbstsigniertes Zertifikat. Die ERP-Software: „TLS 1.3 mit gültigem Zertifikat oder gar keine Verbindung.“
Kosten des Stillstands: 50.000 Euro/Tag.
Die Notlösung? Ein externer Berater baute in 72 Stunden Dauereinsatz eine Minimal-PKI auf. Kosten: 35.000 EUR. Dauerlösung? Bis heute nicht implementiert.
Zero-Trust macht es noch schlimmer:
Mit dem Zero-Trust-Paradigma wird es drastischer:
Jede Verbindung muss authentifiziert sein
Jeder Endpoint braucht eine Identität
Jedes Paket wird validiert
Ohne PKI: Komplette Isolation
In KRITIS-Umgebungen ist das bereits Pflicht. Ein Kunde aus dem Energiesektor musste seine komplette OT-Umgebung nachrüsten. 1.200 Geräte. Jedes brauchte ein Zertifikat. Die manuelle Einrichtung dauerte 8 Monate.
Die Komplexitätsstufen einer „einfachen“ PKI:
Root-CA einrichten – Schon hier beginnt die Philosophiediskussion: Online oder Offline? Hardware-Security-Module? Welcher Algorithmus? RSA 4096 oder doch ECC?
Intermediate CAs – Natürlich braucht man die, sagen die Best Practices. Aber wie viele? Eine pro Abteilung? Eine pro Anwendungsfall?
Zertifikats-Templates – Dutzende Parameter. Key Usage, Extended Key Usage, SANs, Validity Period. Jeder falsch gesetzte Wert kann später zum Problem werden.
Verteilung der Root-Zertifikate – Group Policies für Windows, Mobile Device Management für Smartphones, manuelle Installation für Linux, spezielle Verfahren für IoT-Geräte.
Revocation-Infrastruktur – CRL oder OCSP? Oder beides? Hochverfügbar natürlich.
Renewal-Prozesse – Die neue Mode: Zertifikate mit 47 Tagen Laufzeit. Wer tauscht die manuell in 500 Systemen?
Das ACME-Versprechen
Let’s Encrypt hat mit ACME gezeigt, wie einfach Zertifikatsverwaltung sein kann – für öffentliche Domains. Für interne Netze? Dann brauchen Sie:
Einen öffentlich registrierten Domain-Namen
DNS-Challenge-Unterstützung
Automatisierung in ALLEN Systemen
Und beten, dass Ihre 20 Jahre alte Produktionsanlage das versteht
Historische Parallelen: Wir hatten das Problem schon gelöst
1995 – ich erinnere mich noch gut – hatte Lotus Domino eine eingebaute PKI. Symmetrische Verschlüsselung, ja, aber sie funktionierte. Überall. Automatisch. Ohne Wenn und Aber.
Die Ironie: Heute, 30 Jahre später, kämpfen wir mit Problemen, die damals gelöst waren. Wir haben die Verschlüsselung asymmetrisch gemacht (gut!), aber dabei die Einfachheit verloren (schlecht!).
Bei der Bundeswehr lernte ich in den 80ern: „Ein System, das im Gefecht nicht bedienbar ist, ist nutzlos.“ Das gilt heute für PKI: Ein Sicherheitssystem, das so komplex ist, dass es niemand richtig implementiert, macht uns nicht sicherer – es macht uns verwundbarer.
Was das für Ihr Unternehmen bedeutet
Ich sehe bei meinen Kunden drei Reaktionsmuster:
Die Perfektionisten
Bauen eine Enterprise-PKI nach allen Regeln der Kunst auf. Budget: 500.000 EUR. Implementierungszeit: 18 Monate. Vollzeit-Administrator: 1-2 Personen. Ergebnis: Funktioniert, aber niemand versteht es.
Die Pragmatiker
Nutzen selbstsignierte Zertifikate und klicken Warnungen weg. Kosten: Null. Sicherheit: Auch null. Gewöhnung an Warnungen: 100%.
Die Resignierten
Verzichten auf Verschlüsselung im internen Netz. „Ist ja nur intern.“ Bis zur ersten Ransomware-Attacke.
Meine Lösung: Die PKI-Box
Was die Industrie braucht – und was ich seit Jahren predige – ist radikal einfach:
Eine Box. Fertig konfiguriert. Plug & Play.
So würde sie funktionieren:
Auspacken, anschließen – Wie einen WLAN-Router
Basis-Setup über Web-Interface – Firmenname, Domain, fertig
Automatische Integration – DHCP-Option für Clients, SCEP für mobile Geräte
Compliance-ready – Audit-Logs, HSM-Option für Regulierte
Warum gibt es das nicht?
Die unbequeme Wahrheit: Komplexität ist ein Geschäftsmodell.
PKI-Berater leben von der Komplexität
Software-Hersteller verkaufen Enterprise-Lizenzen
Zertifizierungs-Anbieter verdienen an Schulungen
Hardware-Vendor pushen HSMs für 50.000 EUR
Eine 2.000 EUR Box, die einfach funktioniert? Wo bleibt da das Consulting? Die Wartungsverträge? Die Zertifizierungen?
Weiterführende Gedanken: Der größere Kontext
Die PKI-Komplexität ist symptomatisch für ein größeres Problem in der IT: Wir lösen einfache Probleme mit komplexen Lösungen.
In meinem Buch „Greenfield Approach“ beschreibe ich, wie man radikal vereinfacht. Bei PKI hieße das:
Weg mit der Zertifikats-Hierarchie für kleine Firmen
Ein Zertifikat pro Service, nicht pro Server
10 Jahre Laufzeit für interne Systeme
Automatische Verteilung über bestehende Kanäle
Das ist keine Rocket Science. Das ist gesunder Menschenverstand.
Der Ausblick
Ich arbeite aktuell an einem Proof of Concept. Ein Raspberry Pi 5, ein bisschen Python, eine klare Vision. Die Alpha-Version läuft bereits in meinem Lab.
Was fehlt? Ein mutiger Hersteller, der sagt: „Wir machen Sicherheit einfach.“ Nicht „Enterprise-ready“. Nicht „Cloud-native“. Nicht „KI-powered“. Einfach nur: Es funktioniert.
Fazit: Zeit für eine Revolution
35 Jahre in der IT haben mich gelehrt: Die besten Lösungen sind die einfachsten. M/OMS läuft seit 1985 – weil es einfach ist. Meine Kunden bei Mercedes, Vodafone und der Telekom schätzen mich nicht, weil ich Komplexität hinzufüge, sondern weil ich sie reduziere.
PKI muss nicht kompliziert sein. Wir haben es kompliziert gemacht. Zeit, das zu ändern.
In der digitalen Transformation stehen Unternehmen vor einer zentralen Frage: Brauchen wir einen festangestellten Unternehmensarchitekten oder sollten wir einen externen Unternehmensarchitekt beauftragen? Die Entscheidung zwischen internem und externem Enterprise Architect hängt von den spezifischen Herausforderungen ab, die Ihr Unternehmen meistern muss.
Was macht ein Unternehmensarchitekt grundsätzlich?
Ein Unternehmensarchitekt fungiert als Brückenbauer zwischen Geschäftsstrategie und IT-Umsetzung. Er übersetzt Geschäftsziele in technische Architekturen und sorgt dafür, dass alle IT-Systeme harmonisch zusammenarbeiten. Dabei geht es nicht nur um Technik – ein Unternehmensarchitekt denkt ganzheitlich und berücksichtigt Prozesse, Menschen und Technologie gleichermaßen.
Die Kernaufgabe besteht darin, eine langfristige IT-Landschaft zu entwerfen, die flexibel genug ist, um mit dem Unternehmen zu wachsen, aber stabil genug, um den täglichen Betrieb zu gewährleisten.
Der festangestellte Unternehmensarchitekt: Der interne Stratege
Alltägliche Aufgaben und Verantwortlichkeiten
Ein festangestellter Unternehmensarchitekt kennt das Unternehmen in- und auswendig. Sein Arbeitstag beginnt oft mit der Analyse aktueller IT-Systeme und der Bewertung, ob sie noch den Geschäftsanforderungen entsprechen. Er sitzt in Strategiemeetings, diskutiert mit Fachabteilungen über neue Anforderungen und entwickelt kontinuierlich die IT-Architektur weiter.
Typische Wochensituation: Montags Review der laufenden Projekte, dienstags Workshops mit den Fachabteilungen, mittwochs Architektur-Reviews neuer Anwendungen, donnerstags Abstimmung mit dem IT-Management über Budget und Roadmap, freitags Dokumentation und Planung.
Stärken des internen Architekten
Der festangestellte Architekt bringt entscheidende Vorteile mit sich:
Tiefes Unternehmensverständnis: Er kennt die politischen Strukturen, weiß, wer welche Entscheidungen trifft, und versteht die historisch gewachsenen Systeme. Diese Kenntnis ermöglicht es ihm, Lösungen zu entwickeln, die nicht nur technisch funktionieren, sondern auch kulturell akzeptiert werden.
Kontinuität in der Strategie: Langfristige IT-Vorhaben benötigen einen durchgängigen roten Faden. Der interne Architekt sorgt dafür, dass begonnene Transformationsprojekte auch Jahre später noch im ursprünglichen Sinne weitergeführt werden.
Vertrauensaufbau: Durch die tägliche Zusammenarbeit entwickelt er enge Beziehungen zu allen Stakeholdern. Diese Vertrauensbasis ist entscheidend, wenn schwierige Entscheidungen getroffen werden müssen.
Herausforderungen im Alltag
Die interne Position bringt auch spezifische Schwierigkeiten mit sich. Der Architekt muss oft zwischen verschiedenen Interessengruppen vermitteln und dabei neutral bleiben. Gleichzeitig ist er den täglichen politischen Spannungen ausgesetzt und muss aufpassen, nicht in Grabenkämpfe zwischen Abteilungen hineinzugeraten.
Der externe Unternehmensarchitekt: Der objektive Impulsgeber
Einsatzgebiete und Arbeitsweise
Der externe Unternehmensarchitekt kommt meist in spezifischen Situationen zum Einsatz: bei größeren Transformationsprojekten, Systemmigrationen oder wenn frischer Wind in festgefahrene Strukturen gebracht werden soll. Sein Fokus liegt auf der schnellen Analyse und der Entwicklung konkreter Lösungsansätze.
Typisches Projektvorgehen: Erste Wochen intensive Analyse und Stakeholder-Interviews, dann Entwicklung der Zielarchitektur, Erstellung einer Roadmap und schließlich Begleitung der ersten Umsetzungsschritte.
Die Stärken der externen Perspektive
Neutralität und Objektivität: Der externe Architekt steht außerhalb der internen Machstrukturen und kann unvoreingenommen bewerten. Er kann unbequeme Wahrheiten aussprechen, ohne Angst vor karrieretechnischen Konsequenzen haben zu müssen.
Branchenweites Know-how: Durch die Arbeit in verschiedenen Unternehmen bringt er Best Practices und bewährte Lösungsansätze mit. Er weiß, welche Architekturmuster in vergleichbaren Situationen erfolgreich waren.
Fokussierte Expertise: Externe Architekten spezialisieren sich oft auf bestimmte Bereiche oder Technologien. Diese Tiefe kann besonders bei komplexen Transformationsprojekten entscheidend sein.
Arbeitsweise in Krisensituationen
Wenn IT-Projekte in Schieflage geraten oder wenn scheinbar unlösbare Architekturprobleme auftreten, zeigt sich die Stärke des externen Architekten. Er kann mit frischem Blick an das Problem herangehen, ist nicht von bisherigen Entscheidungen emotional belastet und kann radikalere Lösungsansätze vorschlagen.
Praxisvergleich: Typische Unternehmensszenarien
Szenario 1: Digitale Transformation eines Mittelständlers
Interne Lösung: Der festangestellte Architekt entwickelt über Monate hinweg eine Digitalisierungsstrategie, bindet alle Abteilungen ein und sorgt für breite Akzeptanz. Die Umsetzung dauert länger, ist aber nachhaltig und wird von allen Beteiligten mitgetragen.
Externe Lösung: Der externe Architekt analysiert binnen weniger Wochen den Status quo, entwickelt eine klare Roadmap und stößt die ersten Projekte an. Die Umsetzung geht schneller voran, benötigt aber zusätzliche interne Ressourcen für die dauerhafte Betreuung.
Szenario 2: Komplexe Systemlandschaft nach Fusion
Interne Herausforderung: Der interne Architekt kennt nur eine der beiden zu fusionierenden IT-Landschaften und muss sich erst in die neue Komplexität einarbeiten. Dafür kann er die Integration langfristig begleiten.
Externe Expertise: Der externe Architekt bringt Erfahrung aus ähnlichen Fusionsprojekten mit, kann schnell eine Konsolidierungsstrategie entwickeln und neutral zwischen den verschiedenen Systemwelten vermitteln.
Externer Unternehmensarchitekt oder interner – wann was?
Für den internen Architekten sprechen:
Langfristige Strategieentwicklung: Wenn Sie eine kontinuierliche Evolution Ihrer IT-Landschaft planen
Komplexe Stakeholder-Landschaft: Bei vielen beteiligten Abteilungen und komplexen Entscheidungsstrukturen
Begrenzte Budgets: Für dauerhaft verfügbare Architektur-Expertise bei planbaren Kosten
Spezifische Branchenkenntnisse: In regulierten Industrien mit besonderen Compliance-Anforderungen
Für den externen Architekten sprechen:
Transformationsprojekte: Bei grundlegenden Veränderungen der IT-Landschaft
Zeitkritische Projekte: Wenn schnelle Ergebnisse gefordert sind
Objektive Bewertung: Bei internen Konflikten oder festgefahrenen Situationen
Spezielle Expertise: Für Technologien oder Methodiken, die intern nicht verfügbar sind
Viele Unternehmen entscheiden sich heute für einen kombinierten Ansatz. Ein interner Architekt sorgt für Kontinuität und Unternehmenskenntnis, während externe Experten für spezifische Projekte oder bei besonderen Herausforderungen hinzugezogen werden.
Diese Kombination ermöglicht es, die strategische IT-Entwicklung intern zu steuern und gleichzeitig von externem Know-how und frischen Impulsen zu profitieren. Der interne Architekt fungiert dabei als Schnittstelle und sorgt dafür, dass externe Empfehlungen auch praktisch umsetzbar sind.
Erfolgsfaktoren für beide Ansätze
Unabhängig von der gewählten Lösung sind bestimmte Erfolgsfaktoren entscheidend:
Klare Mandate: Sowohl interne als auch externe Architekten benötigen eindeutige Befugnisse und Unterstützung durch das Management.
Kommunikationsfähigkeit: Die beste Architektur nützt nichts, wenn sie nicht vermittelt werden kann. Sowohl interne als auch externe Architekten müssen komplexe Sachverhalte verständlich erklären können.
Flexibilität: IT-Landschaften entwickeln sich schnell. Architekten müssen bereit sein, ihre Pläne anzupassen, wenn sich Rahmenbedingungen ändern.
Fazit: Strategische Entscheidung mit weitreichenden Folgen
Die Wahl zwischen festangestelltem und externem Unternehmensarchitekt ist eine strategische Entscheidung, die weitreichende Auswirkungen auf die IT-Entwicklung Ihres Unternehmens hat. Beide Ansätze haben ihre Berechtigung und bringen spezifische Vorteile mit sich.
Der interne Architekt ist der richtige Partner für kontinuierliche, langfristige IT-Entwicklung und komplexe Stakeholder-Management. Der externe Architekt bringt frische Impulse, objektive Bewertungen und spezialisiertes Know-how für Transformationsprojekte.
Die Entscheidung sollte auf Basis Ihrer spezifischen Unternehmensituation, Ihrer IT-Strategie und Ihrer verfügbaren Ressourcen getroffen werden. Häufig ist eine Kombination beider Ansätze der optimale Weg, um die Vorteile beider Welten zu nutzen und gleichzeitig die jeweiligen Schwächen zu kompensieren.
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
