EEI est-il un substitut au device fingerprinting ?

Non. Le fingerprinting répond à 'est-ce probablement le même appareil que nous avons vu avant ?' — un identifiant probabiliste dérivé de traits observables de l'appareil. EEI répond à 'qu'a effectivement fait cet appareil, dans quel ordre, dans quel état runtime ?' — un enregistrement déterministe et cryptographiquement signé de l'exécution. Identification et attestation d'exécution sont des problèmes différents. Ils composent.

Que fait le fingerprinting qu'EEI ne fait pas ?

Le fingerprinting établit un identifiant d'appareil probabiliste entre sessions, sans nécessiter de clé liée au matériel ni de bootstrap one-time. Il fonctionne sur le web, web-mobile, et tout contexte navigateur où vous ne pouvez pas installer d'infrastructure runtime. EEI ne réplique pas cela — il exige un module runtime embarqué dans l'app ou le firmware du terminal.

Que fait EEI que le fingerprinting ne fait pas ?

EEI produit un enregistrement cryptographiquement signé qui nomme exactement ce qui s'est exécuté — utilisation de credential, biométrie, assemblage de payload, soumission de requête, état runtime à chaque étape. L'enregistrement est vérifiable indépendamment avec une clé publique, hash-linké à l'événement précédent, rejouable depuis le ledger appareil. Le fingerprinting produit un score de similarité que le risk engine de l'opérateur consomme ; EEI produit une evidence que le risk engine de l'opérateur, la plateforme de litiges, l'émetteur, et le régulateur peuvent chacun vérifier.

Les fingerprints sont-ils spoofables ?

Les fingerprints dérivent de traits observables — user agent, taille d'écran, liste de fonts, hash de canvas, classe IP, pattern comportemental. Des adversaires suffisamment motivés peuvent normaliser leur appareil pour matcher un fingerprint cible, surtout sur mobile. La clé de signature EEI vit à l'intérieur du TEE de l'appareil ; le spoof exige une extraction de clé matérielle, qui est une classe de menace entièrement différente. Les deux répondent à des questions différentes sur le coût adversarial.

Les deux peuvent-ils composer ?

Oui. Le fingerprinting peut piloter la couche de continuité d'identité — 'c'est le même appareil qui s'est authentifié la semaine dernière'. EEI signe ce que cet appareil identifié a effectivement fait pendant cette session — 'la même clé liée au matériel a produit ces événements signés dans cet ordre'. Les opérateurs qui livrent les deux obtiennent la continuité d'identité probabiliste plus l'evidence d'exécution déterministe.

comparaison · EEI vs device fingerprinting

L'identité probabiliste rencontre
l'evidence d'exécution déterministe.

ThreatMetrix, BioCatch, Forter, Sift, FingerprintJS Pro, Iovation — ces solutions répondent à "est-ce le même appareil ?" avec un score de similarité. EEI répond à "qu'a fait cet appareil ?" avec un enregistrement cryptographiquement signé. Questions différentes, infrastructures différentes, points de décision différents.

réponse courte

Le fingerprinting est de l'identification — probabiliste, dérivée de traits observables. EEI est de l'attestation d'exécution — déterministe, signée avec une clé liée au matériel, vérifiable sans fournisseur. Les deux répondent à des questions différentes ; ils ne se remplacent pas, ils se placent à des couches différentes.

couches différentes, même risk engine

La continuité d'identité alimente un input. L'exécution signée en alimente un autre.

Sur Android comme sur iOS, la régulation privacy retire les traits sur lesquels le fingerprinting s'appuyait. Ce qui reste se réduit vers SSAID/IDFV plus quelques octets d'attestation. EEI n'observe pas de traits ; il signe l'exécution avec une clé liée au TEE — l'input ne change pas quand les API privacy changent.

côte à côte

Ce à quoi chacun répond. Ce qu'aucun ne fait.

Dimension	Device fingerprinting	EEI
Ce qu'il produit	Identifiant d'appareil probabiliste (hash de fingerprint, score de similarité) dérivé de traits observables.	Evidence Token cryptographiquement signé et déterministe lié à une clé résidant dans le TEE.
Question à laquelle il répond	Est-ce le même appareil qu'on a vu avant ? Cet appareil ressemble-t-il à des appareils connus pour fraude ?	Qu'a fait cet appareil, dans quel ordre, dans quel état runtime, entre l'utilisation du credential et la réception réseau ?
Modèle d'identité	Implicite, dérivé des traits. L'identifiant change quand la surface des traits change (mise à jour navigateur, upgrade OS, changement réseau).	Explicite, lié à une clé résidant dans le matériel. L'identifiant est stable sur le cycle de vie de l'appareil jusqu'au re-bootstrap.
Modèle de vérification	Le moteur de matching du fournisseur produit un score de similarité ; l'opérateur consomme le score.	Le vérificateur de l'opérateur vérifie la signature ES256, le key binding, la continuité de hash chain. Aucun fournisseur dans le chemin.
Trust basis	Confiance de match probabiliste — typiquement 0.0–1.0. L'opérateur choisit un seuil.	Trust basis déclaré : `hardware_backed`, `hardware_bound`, `execution_proof`, `compromised_device`, `software_layer`. Jamais inféré.
Coût adversarial	Normalisation de traits ; l'outillage existe pour mimer des fingerprints ciblés.	Extraction de clé TEE ou substitution de runtime ; ordres de grandeur plus dur, déclaré honnêtement quand cela réussit (`compromised_device`).
Profondeur forensique	Historique de scores ; historique de changement de traits.	Local Evidence Ledger hash-linké sur l'appareil ; chemin d'exécution complet récupérable via le canal Commander.
Où il se déploie	Web, web-mobile, in-app, server-side. Fonctionne dans tout contexte navigateur.	Mobile (banque, fintech, superapp), POS / mPOS / SoftPOS, SST. Exige un module runtime embarqué dans l'app ou le firmware du terminal.
Posture PII	Les hashes de fingerprint peuvent être des quasi-identifiants ; certaines implémentations portent IP, écran, et champs comportementaux qui compliquent la posture POPIA / RGPD.	Pas de PII dans l'evidence. Identifiants d'appareil pseudonymes (SHA-256 de la clé publique de l'appareil). Profil de privacy strict requis pour les consommateurs SA sous POPIA §11.

où ils composent

Continuité d'identité plus evidence d'exécution.

Le fingerprinting est mature, ubiquitaire, et répond à une vraie question — est-ce le même appareil qui s'est authentifié la semaine dernière ? — qu'EEI ne répond pas. EEI signe ce que l'appareil fait, pas s'il est reconnaissable. Les deux couches composent :

Le fingerprint identifie l'appareil entre sessions — même pré-login, pré-bootstrap, sur les surfaces web où le runtime EEI ne peut pas être embarqué.
EEI signe ce que cet appareil identifié a exécuté — l'utilisation du credential, la biométrie, l'assemblage de payload, le swap réseau mid-transaction.
Le risk engine de l'opérateur lit les deux : score de similarité d'identité depuis le fingerprint, enregistrement signé d'exécution depuis EEI. Une policy conditionnelle et contextuelle remplace un bit unique de "device approved".

Là où le fingerprinting peine — normalisation de fingerprint, fermes, proxies résidentiels, outils d'automatisation — la clé liée au matériel d'EEI ajoute un coût différent : extraire la clé privée d'un TEE est un problème différent de la normalisation de traits. Là où EEI ne va pas — surfaces web pures, funnels pré-installation d'app — le fingerprinting fonctionne toujours. Les opérateurs qui livrent les deux couvrent la surface.

La régulation privacy rétrécit la surface des traits. User-Agent reduction, Privacy Sandbox, restrictions d'identifiants Android 13+, iOS App Tracking Transparency, et le Privacy Manifest d'Apple — chacun retire ou gate des signaux sur lesquels le fingerprinting historiquement s'appuyait. Sur Android, l'identifiant stable se réduit vers SECURE_ID plus quelques octets d'attestation ; sur iOS, la surface de traits lisibles publiquement se rétrécit vers ce qu'App Attest émet. L'input EEI — événements d'exécution signés avec une clé liée au TEE — n'est pas affecté par ces changements, parce qu'il ne dépend pas du tout de traits observables. L'input fingerprinting rétrécit à chaque release plateforme ; l'input EEI reste stable.

Réalité des réseaux mobiles africains. Sur les réseaux mobiles ASN-collapsed où la classe IP et la géolocalisation perdent leur pouvoir discriminatif (large-NAT chez les opérateurs mobiles à travers SADC, ECOWAS, EAC), la précision du fingerprinting se dégrade. La clé liée au matériel d'EEI produit une surface de coût différente pour les adversaires, qui ne dépend pas de signaux réseau.

Les surfaces de banque web restent le domaine du fingerprinting. Là où le runtime ne peut pas être embarqué — banque web pure, flows hybrides web-mobile pré-installation d'app, portails self-service client — le fingerprinting et les biométries comportementales (BioCatch, Featurespace ARIC, Forter device intelligence) restent le substrat. EEI n'y atteint pas par construction. À l'intérieur de l'app wallet, du firmware terminal, ou du shell kiosque, EEI signe ce qui s'est exécuté ; le score de fingerprint continue à identifier l'appareil entre sessions.

questions fréquentes

Cinq questions, cinq réponses.

·01 EEI est-il un substitut au device fingerprinting ?: Non. Le fingerprinting répond à 'est-ce probablement le même appareil que nous avons vu avant ?' — un identifiant probabiliste dérivé de traits observables de l'appareil. EEI répond à 'qu'a effectivement fait cet appareil, dans quel ordre, dans quel état runtime ?' — un enregistrement déterministe et cryptographiquement signé de l'exécution. Identification et attestation d'exécution sont des problèmes différents. Ils composent.
·02 Que fait le fingerprinting qu'EEI ne fait pas ?: Le fingerprinting établit un identifiant d'appareil probabiliste entre sessions, sans nécessiter de clé liée au matériel ni de bootstrap one-time. Il fonctionne sur le web, web-mobile, et tout contexte navigateur où vous ne pouvez pas installer d'infrastructure runtime. EEI ne réplique pas cela — il exige un module runtime embarqué dans l'app ou le firmware du terminal.
·03 Que fait EEI que le fingerprinting ne fait pas ?: EEI produit un enregistrement cryptographiquement signé qui nomme exactement ce qui s'est exécuté — utilisation de credential, biométrie, assemblage de payload, soumission de requête, état runtime à chaque étape. L'enregistrement est vérifiable indépendamment avec une clé publique, hash-linké à l'événement précédent, rejouable depuis le ledger appareil. Le fingerprinting produit un score de similarité que le risk engine de l'opérateur consomme ; EEI produit une evidence que le risk engine de l'opérateur, la plateforme de litiges, l'émetteur, et le régulateur peuvent chacun vérifier.
·04 Les fingerprints sont-ils spoofables ?: Les fingerprints dérivent de traits observables — user agent, taille d'écran, liste de fonts, hash de canvas, classe IP, pattern comportemental. Des adversaires suffisamment motivés peuvent normaliser leur appareil pour matcher un fingerprint cible, surtout sur mobile. La clé de signature EEI vit à l'intérieur du TEE de l'appareil ; le spoof exige une extraction de clé matérielle, qui est une classe de menace entièrement différente. Les deux répondent à des questions différentes sur le coût adversarial.
·05 Les deux peuvent-ils composer ?: Oui. Le fingerprinting peut piloter la couche de continuité d'identité — 'c'est le même appareil qui s'est authentifié la semaine dernière'. EEI signe ce que cet appareil identifié a effectivement fait pendant cette session — 'la même clé liée au matériel a produit ces événements signés dans cet ordre'. Les opérateurs qui livrent les deux obtiennent la continuité d'identité probabiliste plus l'evidence d'exécution déterministe.

Les opérateurs avec des pipelines fingerprinting matures veulent souvent EEI dessous, pas à la place de.

Nous mappons vos signaux fingerprint existants aux classes de signaux EEI, montrons où l'execution evidence répond à ce que le fingerprint ne peut pas, et où le fingerprint fait encore mieux le travail. Vous gardez le pipeline ; vous ajoutez l'evidence.

Demander un briefing

L'identité probabiliste rencontre l'evidence d'exécution déterministe.