> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Geräte-Fingerprinting & IP-Risiko: Warnungscodes > Alle Warnungscodes der Geräte- und IP-Analyse von Didit: VPN/Tor, Länderabweichung, Sperrlisten, doppelte IPs/Geräte und erwartete IP-Abweichungen. ## Übersicht Die Geräte- und IP-Analyse gibt Warnungs-Tags unter `ip_analyses[].warnings[]` aus, wann immer sie verdächtiges Geräte-, Netzwerk- oder Standortverhalten erkennt. Neun Tags verfügen über eine konfigurierbare Aktion (Ablehnen / Prüfung / Keine Aktion) pro Workflow-Knoten; die beiden Sperrlisten-Tags erzwingen immer `Declined`, und die beiden Positivlisten-Tags sind stets rein informativ. Der `log_type` jeder Warnung spiegelt die angewendete Aktion wider: `error` (Ablehnen), `warning` (Prüfung) oder `information` (Keine Aktion). Jedes Risiko wird höchstens einmal pro Sitzung ausgelöst. Jedes der folgenden Risiken wird anhand der Live-Entscheidungspipeline überprüft; Warnungen enthalten das Funktions-Tag `LOCATION` und die standardmäßige Struktur des [Warnungsobjekts](https://docs.didit.me/de/reference/data-models.md#warnungsobjekt). Die Warnungen zum Geräte-Fingerprint sind bewusst in exakte und wiederhergestellte Signale unterteilt: * `DUPLICATED_DEVICE_FINGERPRINT` bedeutet, dass dieselbe deterministische Geräteidentität (`match_source` `persistent_id` oder `legacy_fp`) sitzungsübergreifend mit unterschiedlichen `vendor_data`-Werten wiederverwendet wurde. * `DEVICE_RECOVERED_HIGH_CONFIDENCE` bedeutet, dass die v2-Fingerprint-Wiederherstellung die Sitzung einem zuvor gesehenen Gerät zugeordnet hat, **nachdem** sich die persistente ID geändert hat (Speicher geleert, Inkognito-Modus, Neuinstallation der App). Die Warnung wird nur ausgegeben, wenn die Übereinstimmung den Schwellenwert für eine Übereinstimmung mit hoher Konfidenz überschreitet und die strikten Bedingungen erfüllt. ![Beispiel für Warnungen der Didit Geräte- und IP-Analyse mit Alerts zu Gerät, VPN, Proxy und Standortabweichung](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/ip-analysis-warning-example.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=370f87af45a6138ebd7454abe9131665) ## Erzeugte Warnungen | Risiko | Ursache | `log_type` | Beeinflusst Status | Empfohlene Behebung | | - | - | - | - | - | | `PRIVATE_NETWORK_DETECTED` | `is_vpn_or_tor` war `true` – die Sitzung wurde über ein VPN, einen Proxy oder einen Tor-Exit-Node geöffnet. `additional_data` ist `null`. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Entscheiden Sie, ob Ihre Risikotoleranz maskierten Datenverkehr zulässt. Wenn Sie ihn akzeptieren, belassen Sie die Einstellung auf No action. | | `COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP` | Der ISO-Ländercode des Ausweisdokuments weicht von dem aus der IP-Adresse abgeleiteten Land ab. `additional_data` enthält beide ISO-3-Codes: `document_country_code`, `ip_country_code`. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Führen Sie eine Prüfung durch, wenn der Benutzer legitim reist. Lehnen Sie ab, wenn dies zusammen mit einem VPN oder Signalen für ein doppeltes Gerät auftritt. | | `EXPECTED_IP_ADDRESS_MISMATCH` | Die Sitzung wurde mit einer erwarteten IP-Adresse erstellt, und die Live-IP weicht ab. `additional_data` enthält `expected_ip_address` und `actual_ip_address`. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Verwenden Sie dies, wenn Sie die IP bei der Sitzungserstellung vorab festlegen. Verweigern Sie die Sitzung oder führen Sie bei einer Abweichung eine stärkere Authentifizierung durch. | | `IP_ADDRESS_IN_BLOCKLIST` | Die IP-Adresse der Sitzung stimmt mit einem Eintrag in der IP-Sperrliste der Anwendung überein. `additional_data`: `ip_address`. | immer `error` | Erzwingt `Declined`. | Weisen Sie die Sitzung ab. Überprüfen Sie bei Bedarf die Quelle der Sperrliste auf falsch-positive Ergebnisse. | | `DEVICE_FINGERPRINT_IN_BLOCKLIST` | Der Geräte-Fingerprint der Sitzung stimmt mit einem Eintrag in der Geräte-Sperrliste überein. `additional_data`: `device_fingerprint`. | immer `error` | Erzwingt `Declined`. | Weisen Sie die Sitzung ab. | | `IP_ADDRESS_IN_ALLOWLIST` | Für die IP der Sitzung gab es Duplikat-Übereinstimmungen, sie befindet sich jedoch auf der IP-Allowlist der Anwendung, sodass die Warnung vor doppelter IP übersprungen wurde. `additional_data`: `ip_address`. | immer `information` | Keine. | Verwenden Sie dies für vertrauenswürdige Unternehmens-NATs, QA-Netzwerke oder bekannte gemeinsame Zugangspunkte. | | `DEVICE_FINGERPRINT_IN_ALLOWLIST` | Für den Geräte-Fingerprint der Sitzung gab es deterministische Duplikat-Übereinstimmungen, er befindet sich jedoch auf der Geräte-Allowlist, sodass die Warnung vor doppeltem Gerät übersprungen wurde. `additional_data`: `device_fingerprint`. | immer `information` | Keine. | Verwenden Sie dies nur für vertrauenswürdige gemeinsam genutzte Geräte. Sperrlisten haben weiterhin Vorrang. | | `DUPLICATED_IP_ADDRESS` | Dieselbe IP wurde in einer anderen Sitzung mit anderen `vendor_data` verwendet. `additional_data`: `duplicated_session_id`, `duplicated_session_number`, `api_service`. Wird übersprungen, wenn die IP auf der Allowlist steht. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Häufig bei Unternehmens- oder gemeinsam genutzten NATs. Kombinieren Sie dies mit weiteren Signalen (doppeltes Gerät, Länderabweichung), bevor Sie ablehnen. | | `DUPLICATED_DEVICE_FINGERPRINT` | Dieselbe deterministische Geräteidentität wurde sitzungsübergreifend mit anderen `vendor_data` wiederverwendet. `additional_data`: `duplicated_session_id`, `duplicated_session_number`, `api_service`, `match_source` (`persistent_id` oder `legacy_fp`). Wird übersprungen, wenn der Fingerprint auf der Allowlist steht. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Starker Beleg für Multi-Account-Missbrauch. Prüfen oder lehnen Sie je nach Betrugstoleranz ab. | | `DEVICE_RECOVERED_HIGH_CONFIDENCE` | Das Gerätewiederherstellungsmodell v2 ordnete die Sitzung mit hoher Konfidenz einem zuvor erfassten Gerät zu, selbst nachdem sich die persistente ID geändert hatte. `additional_data`: `duplicated_session_id`, `duplicated_session_number`, `api_service`, `match_source` (`recovered_high`), `recovery_similarity`, `recovery_match_device_uuid`. Wird nicht durch die Geräte-Allowlist unterdrückt. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Beginnen Sie mit Review, messen Sie Ihre Rate an falsch-positiven Ergebnissen und verschärfen Sie anschließend die Aktion. Starkes Signal für Versuche mit Speicherbereinigung oder im Inkognito-Modus. | | `DEVICE_LINKED_TO_LIVENESS_ATTACK` | Dasselbe Gerät (abgeglichen anhand seiner persistenten Geräte-ID) wurde in einer früheren Sitzung eines anderen Benutzers verwendet, dessen Liveness-Erfassung als Angriff gewertet wurde. Ein Gerät, das bereits für einen Angriff auf den Liveness-Check verwendet wurde, ist ein starker Indikator dafür, dass diese Erfassung vom selben Angreifer stammt. `additional_data`: `liveness_attack_session_id`, `liveness_attack_session_number`, `liveness_attack_sessions_count`, `match_source` (`persistent_id`). | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Beginnen Sie mit Review und messen Sie Ihre Rate an falsch-positiven Ergebnissen, bevor Sie auf Decline umstellen. | | `DEVICE_MODEL_INCONSISTENT` | Dasselbe Gerät (abgeglichen anhand seiner persistenten Geräte-ID) wurde in einer früheren Sitzung als anderes Gerätemodell gemeldet. Ein physisches Gerät ändert sein Modell nicht; daher ist das gemeldete Modell wahrscheinlich manipuliert oder die Gerätekennung wurde auf ein anderes Gerät kopiert. Generische Modellzeichenfolgen werden nie verglichen. `additional_data`: `device_model`, `earlier_device_model`, `earlier_session_id`, `earlier_session_number`, `match_source`. | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: No action). | Vergleichen Sie die beiden gemeldeten Modelle und prüfen Sie die frühere Sitzung, bevor Sie Maßnahmen ergreifen. | | `IP_LOCATION_NOT_ALLOWED` | IP-Geofencing ist aktiviert und die Sitzungs-IP befindet sich in einem als nicht zulässig markierten Land, Bundesstaat oder einer nicht zulässigen Region. `additional_data`: `ip_country_code` (ISO-3), `ip_country`, `ip_state`, `restricted_by` (`country` oder `state`). | spiegelt konfigurierte Aktion wider | Konfigurierbar: Decline / Review / No action (Standard: Decline). | Verwenden Sie dies zur Durchsetzung von regionalen Einschränkungen. Kombinieren Sie dies mit `vpn_detection_action`, damit maskierter Datenverkehr das Geofencing nicht umgehen kann. | Wenn für das wiederhergestellte Gerät noch keine geeigneten Geschwistersitzungen vorhanden sind (sodass nichts in `matches[]` landet), wird `DEVICE_RECOVERED_HIGH_CONFIDENCE` dennoch mit einer Fallback-Struktur für `additional_data` ausgelöst: `recovery_match_device_uuid`, `recovery_match_similarity`, `recovery_match_band`, `recovery_gate_reason`. `IP_LOCATION_NOT_ALLOWED` wird ausgelöst, wenn IP-Geofencing aktiviert ist (`is_ip_geofencing_enabled`) und sich die Sitzungs-IP in einem in `ip_geofencing_by_country` als nicht zulässig markierten Land, Bundesstaat oder einer nicht zulässigen Region befindet. `additional_data` enthält `ip_country_code` (ISO-3), `ip_country`, `ip_state` und `restricted_by` (`country` oder `state`). Bundesstaats-/Regionseinträge überschreiben das Länder-Flag und werden ohne Berücksichtigung der Groß-/Kleinschreibung mit dem Regionsnamen des IP-Anbieters abgeglichen (z. B. `"California"`); Länder, die nicht in der Konfiguration aufgeführt sind, sind zulässig. ## Geräte- und Laufzeitintegrität Signale, die von den nativen SDKs und dem Web-Client gemeldet werden und den Zustand des Geräts beschreiben, auf dem die Verifizierung ausgeführt wurde. Sie dienen dazu, Injection-Angriffe zu erkennen: Ein Angreifer, der ein Gerät rooten oder den App-Prozess hooken kann, kann den Kamera-Feed austauschen, noch bevor er die biometrischen Prüfungen erreicht. Jedes Signal ist pro Workflow konfigurierbar und standardmäßig auf **Keine Aktion** gesetzt, sodass die Aktivierung der Funktion keine Entscheidungen ändert, bis Sie dies explizit festlegen. | Risiko | Ursache | Konfigurationsschlüssel | Standard | | - | - | - | - | | `DEVICE_APP_TAMPERED` | Die Plattform-Attestierung konnte nicht verifizieren, dass die Anfrage von einem echten, unmodifizierten Build der Anwendung auf einem echten Gerät stammte. | `device_app_tampered_action` | `NO_ACTION` | | `DEVICE_RUNTIME_HOOKING_DETECTED` | Ein Laufzeit-Instrumentierungs- oder Hooking-Framework (Frida, Xposed, LSPosed, Substrate) wurde im Anwendungsprozess erkannt. | `device_hooking_action` | `NO_ACTION` | | `DEVICE_ROOTED_OR_JAILBROKEN` | Das Gerät weist Root- oder Jailbreak-Indikatoren auf, wodurch die Schutzmechanismen des Betriebssystems zur Verhinderung des Abfangens der Kamera entfallen. | `device_rooted_action` | `NO_ACTION` | | `DEVICE_EMULATOR_DETECTED` | Die Sitzung stammte von einem Emulator oder Simulator und nicht von einem physischen Gerät. | `device_emulator_action` | `NO_ACTION` | | `DEVICE_DEBUGGER_ATTACHED` | Während der Verifizierung war ein Debugger oder Prozess-Tracer an die Anwendung angehängt. | `device_debugger_action` | `NO_ACTION` | | `AUTOMATION_FRAMEWORK_DETECTED` | Die Sitzung wurde von einem Browser-Automatisierungs-Framework oder Headless-Browser statt von einer Person gesteuert. | `automation_detected_action` | `NO_ACTION` | | `DEVICE_INTEGRITY_SIGNALS_MISSING` | Der Client meldete eine SDK-Version, die Integritätsmeldungen unterstützt, es trafen jedoch keine Integritätssignale ein – was darauf hindeuten kann, dass die Signale während der Übertragung entfernt wurden. | `device_integrity_missing_action` | `NO_ACTION` | > [!NOTE] > > Jede Überprüfung erfolgt nach dem Best-Effort-Prinzip. Wenn eine Prüfung nicht ausgeführt werden kann, meldet sie **nicht ermittelt** statt eines unauffälligen Ergebnisses, sodass ein fehlschlagender Test niemals ein falsches Positiv bei einem legitimen Benutzer erzeugt. Signale werden ab dem nativen SDK **4.4.0** gemeldet; Sitzungen von früheren SDKs senden erwartungsgemäß nichts und lösen niemals `DEVICE_INTEGRITY_SIGNALS_MISSING` aus. > [!WARNING] > > Root- und Emulator-Signale treten häufig bei legitimen Benutzern auf modifizierten, aber nicht betrügerischen Geräten auf. Setzen Sie diese zunächst auf Prüfung statt Ablehnen und beobachten Sie Ihre eigene Ablehnungsrate, bevor Sie die Regeln verschärfen. ## Konfigurierbare Einstellungen Steuerelemente auf Workflow-Knotenebene (auch global in den Verifizierungseinstellungen der Anwendung konfigurierbar; jede Aktion ist standardmäßig auf **Keine Aktion** gesetzt, sofern nicht anders angegeben): | Einstellung | Steuert | Standard | | - | - | - | | `vpn_detection_action` | `PRIVATE_NETWORK_DETECTED` | Keine Aktion | | `ip_mismatch_action` | `COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP` | Keine Aktion | | `expected_ip_mismatch_action` | `EXPECTED_IP_ADDRESS_MISMATCH` | Keine Aktion | | `duplicated_ip_action` | `DUPLICATED_IP_ADDRESS` | Keine Aktion | | `duplicated_device_action` | `DUPLICATED_DEVICE_FINGERPRINT` | Keine Aktion | | `recovered_device_action` | `DEVICE_RECOVERED_HIGH_CONFIDENCE` | Keine Aktion | | `device_liveness_attack_history_action` | `DEVICE_LINKED_TO_LIVENESS_ATTACK` | Keine Aktion | | `device_model_inconsistency_action` | `DEVICE_MODEL_INCONSISTENT` | Keine Aktion | | `ip_geofencing_action` | `IP_LOCATION_NOT_ALLOWED` | Ablehnen | IP- und Geräte-Allowlists unterdrücken nur die exakte Warnung für doppelte IP-Adressen oder deterministisch duplizierte Geräte für den auf der Allowlist geführten Wert. Sie unterdrücken keine Warnungen zu VPN/Proxy, Länderabweichungen, Abweichungen von erwarteten IP-Adressen, wiederhergestellten Geräten oder Sperrlisten. Warnungen zu wiederhergestellten Geräten sind nützlich, um Betrugsringe zu erkennen, die Konten und Sitzungen von derselben Hardware aus wechseln, aber Didit ist von Grund auf konservativ ausgelegt – das System nimmt lieber in Kauf, einige doppelte Benutzer zu übersehen, als nicht miteinander verbundene Geräte zusammenzuführen, wenn die Beweislage nicht eindeutig genug ist. **Empfohlene Einführung**: Beginnen Sie mit Prüfung, beobachten Sie das Volumen zwei Wochen lang und verschärfen Sie die Aktion anschließend, wenn Ihre Falsch-Positiv-Rate niedrig ist. ## Dupliziertes Gerät vs. wiederhergestelltes Gerät Behandeln Sie die beiden Warnungen unterschiedlich – sie werden durch unterschiedliche Nachweise ausgelöst: | Warnung | Auslöser | Typische Bedeutung | Empfohlene erste Aktion | | - | - | - | - | | `DUPLICATED_DEVICE_FINGERPRINT` | Exakte Übereinstimmung der persistenten Geräteidentität (`persistent_id`) oder des Legacy-Fingerprint-Hashs (`legacy_fp`). | Starker Nachweis, dass dasselbe Gerät bei unterschiedlichen Benutzern auftritt. | Prüfung oder Ablehnung, abhängig von Ihrer Betrugstoleranz. | | `DEVICE_RECOVERED_HIGH_CONFIDENCE` | V2-Wiederherstellung mit hoher Konfidenz (`recovered_high`), nachdem sich Speicher, Sitzung oder App-Identität geändert haben. | Starkes Signal für Inkognito-, Speicher-Reset- oder App-Neuinstallationsversuche. Bewusst separat gehalten, damit Sie dies unabhängig überwachen können. | Zunächst auf Prüfung setzen und die Aktion nach Messung Ihrer Falsch-Positiv-Rate verschärfen. | ## Sitzungsübergreifende Übereinstimmungen Wenn dieselbe Adresse, eine exakte Geräteidentität oder ein wiederhergestelltes Gerät über Sitzungen hinweg erkannt wird, die zu **verschiedenen Benutzern** gehören, erfasst Didit diese als `matches[]` unter `ip_analyses[]`. Sitzungen werden nach `vendor_data` gruppiert: Sitzungen mit denselben `vendor_data` werden als derselbe Benutzer behandelt und von den Übereinstimmungen ausgeschlossen. Ohne `vendor_data` wird jede Sitzung als eindeutiger Benutzer behandelt und alle potenziellen Duplikate werden angezeigt – wir empfehlen dringend, `vendor_data` stets anzugeben, um Rauschen zu reduzieren. Jede Übereinstimmung enthält: * `session_id`, `session_number`, `vendor_data` und `verification_date` der übereinstimmenden Sitzung sowie deren Lebenszyklus-`status` und `api_service` (`null` für Workflow-Sitzungen); `source` ist immer `session` * `match_type` – `ip_address` oder `device_fingerprint` * `match_source` – `ip_address`, `persistent_id`, `legacy_fp` oder `recovered_high` * `matched_value` – die gemeinsam genutzte Adresse, die Gerätekennung oder (bei Übereinstimmungen mit wiederhergestellten Geräten) die UUID des wiederhergestellten Geräts * `confidence` (0–1, `1 - P(false positive)`) und `match_mode` (`deterministic` / `probabilistic` / `co_occurrence`) * `device_info` – `device_brand`, `device_model`, `browser_family`, `os_family`, `platform`, `device_fingerprint` * `location_info` – `ip_address`, `ip_country`, `ip_country_code`, `ip_state`, `ip_city`, `is_vpn_or_tor`, `is_data_center` * Zusatzfelder für wiederhergestellte Geräte, wenn `match_source` den Wert `recovered_high` hat: `recovery_similarity`, `tls_ja4_corroborated`, `recovery_gate_reason` IP-Übereinstimmungen und Geräteübereinstimmungen sind auf jeweils 5 begrenzt (maximal 10 Einträge). Das vollständige Übereinstimmungsschema und das Konfidenzmodell finden Sie auf der [Berichtsseite](https://docs.didit.me/de/core-technology/ip-analysis/report-ip-analysis.md#match-semantik). ## Beispiele ### VPN + Länderabweichung (auf Prüfung konfiguriert) ```json theme={null} { "warnings": [ { "feature": "LOCATION", "risk": "PRIVATE_NETWORK_DETECTED", "additional_data": null, "log_type": "warning", "short_description": "Private network (VPN/Tor) detected", "long_description": "The system detected that the user tried to use a private network (VPN/TOR) to complete the verification process.", "node_id": "ip-1" }, { "feature": "LOCATION", "risk": "COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP", "additional_data": { "document_country_code": "ESP", "ip_country_code": "NLD" }, "log_type": "warning", "short_description": "Document country does not match IP country", "long_description": "The country from the document does not match the country from the IP address, suggesting a potential mismatch between the document and the user's location.", "node_id": "ip-1" } ] } ``` ### Treffer auf Sperrliste (erzwingt Ablehnung) ```json theme={null} { "warnings": [ { "feature": "LOCATION", "risk": "IP_ADDRESS_IN_BLOCKLIST", "additional_data": { "ip_address": "45.61.20.5" }, "log_type": "error", "short_description": "IP address in blocklist", "long_description": "The IP address used for this session was found in the application's IP blocklist, indicating a known suspicious or forbidden origin.", "node_id": "ip-1" } ] } ``` ### Wiederhergestelltes Gerät mit hoher Konfidenz (auf Prüfung konfiguriert) ```json theme={null} { "warnings": [ { "feature": "LOCATION", "risk": "DEVICE_RECOVERED_HIGH_CONFIDENCE", "additional_data": { "duplicated_session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee", "duplicated_session_number": 5101, "api_service": null, "match_source": "recovered_high", "recovery_similarity": 0.9874, "recovery_match_device_uuid": "f47ac10b-58cc-4372-a567-0e02b2c3d479" }, "log_type": "warning", "short_description": "Device matches a previously seen device with high confidence", "long_description": "A previously seen device matched this session with high confidence through v2 fuzzy fingerprint recovery after passing strict hard gates, indicating the same physical device under a fresh persistent_id.", "node_id": "ip-1" } ] } ``` ## Verwandte Themen * [Bericht zur Geräte- und IP-Analyse](https://docs.didit.me/de/core-technology/ip-analysis/report-ip-analysis.md) – vollständige Antwortstruktur und Statussemantik * [Übersicht zur Geräte- und IP-Analyse](https://docs.didit.me/de/core-technology/ip-analysis/overview.md) – was die einzelnen Blöcke erfassen * [Datenmodelle – IP-Analyse](https://docs.didit.me/de/reference/data-models.md#ip-analyse) – kanonisches Schema * [Webhooks](https://docs.didit.me/de/integration/webhooks.md) – `status.updated` übermittelt Warnungen der IP-Analyse ### Warnungstypen This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.