Is EEI a replacement for device fingerprinting?

No. Fingerprinting answers ‘is this likely the same device we saw before?’ — a probabilistic identifier derived from observable device traits. EEI answers ‘what did this device actually do, in what order, in what runtime state?’ — a deterministic, cryptographically signed record of execution. Identification and execution attestation are different problems. They compose.

What does fingerprinting do that EEI does not?

Fingerprinting establishes a probabilistic device identifier across sessions, without requiring a hardware-bound key or a one-time bootstrap. It works on web, web-mobile, and any browser context where you cannot install runtime infrastructure. EEI does not replicate that — it requires a runtime module embedded in the app or terminal firmware.

What does EEI do that fingerprinting does not?

EEI produces a cryptographically signed record that names exactly what executed — credential use, biometric, payload assembly, request submission, runtime state at each step. The record is verifiable independently with a public key, hash-linked to the previous event, replayable from the device ledger. Fingerprinting produces a similarity score that the operator's risk engine consumes; EEI produces evidence that the operator's risk engine, the dispute platform, the issuer, and the regulator can each verify.

Are fingerprints spoofable?

Fingerprints derive from observable traits — user agent, screen size, font list, canvas hash, IP class, behavioural pattern. Adversaries with sufficient motivation can normalise their device to match a target fingerprint, especially on mobile. EEI's signing key lives inside the device's TEE; spoofing it requires hardware-key extraction, which is a different threat class entirely. The two answer different questions about adversarial cost.

Yes. Fingerprinting can drive the identity-continuity layer — ‘this is the same device that authenticated last week’. EEI signs what that identified device actually did during this session — ‘the same hardware-bound key produced these signed events in this order’. Operators that ship both get probabilistic identity continuity plus deterministic execution evidence.

comparison · EEI vs device fingerprinting

Probabilistic identity meets
deterministic execution evidence.

ThreatMetrix, BioCatch, Forter, Sift, FingerprintJS Pro, Iovation — these answer "is this the same device?" with a similarity score. EEI answers "what did this device do?" with a cryptographically signed record. Different questions, different infrastructure, different decision points.

short answer

Fingerprinting is identification — probabilistic, derived from observable traits. EEI is execution attestation — deterministic, signed with a hardware-bound key, verifiable without a vendor. The two answer different questions; they don't replace each other, they sit at different layers.

different layers, same risk engine

Identity continuity feeds one input. Signed execution feeds another.

On Android and iOS, privacy regulation removes traits fingerprinting historically relied on. What remains collapses toward SSAID/IDFV plus a few attestation bytes. EEI does not observe traits; it signs execution with a TEE-bound key — the input is unaffected when privacy APIs change.

side by side

What each one answers. What each one does not.

Dimension	Device fingerprinting	EEI
What it produces	Probabilistic device identifier (fingerprint hash, similarity score) derived from observable traits.	Deterministic, cryptographically signed Evidence Token bound to a TEE-resident key.
Question it answers	Is this the same device we saw before? Is this device similar to known-fraud devices?	What did this device do, in what order, in what runtime state, between credential use and network receipt?
Identity model	Implicit, derived from traits. Identifier changes when the trait surface changes (browser update, OS upgrade, network change).	Explicit, bound to a hardware-resident key. Identifier stable across the device's lifecycle until re-bootstrap.
Verification model	Vendor's matching engine produces a similarity score; the operator consumes the score.	Operator's verifier checks ES256 signature, key binding, hash-chain continuity. No vendor in the path.
Trust basis	Probabilistic match confidence — typically 0.0–1.0. Operator chooses a threshold.	Declared trust basis: `hardware_backed`, `hardware_bound`, `execution_proof`, `compromised_device`, `software_layer`. Never inferred.
Adversarial cost	Trait normalisation; tooling exists to mimic targeted fingerprints.	TEE key extraction or runtime substitution; orders-of-magnitude harder, declared honestly when it succeeds (`compromised_device`).
Forensic depth	Score history; trait change history.	Hash-linked Local Evidence Ledger on the device; full execution path retrievable via the Commander channel.
Where it deploys	Web, web-mobile, in-app, server-side. Works in any browser context.	Mobile (banking, fintech, superapp), POS / mPOS / SoftPOS, SST. Requires a runtime module embedded in the app or terminal firmware.
PII posture	Fingerprint hashes can be quasi-identifiers; some implementations carry IP, screen, and behavioural fields that complicate POPIA / GDPR posture.	No PII in evidence. Device identifiers are pseudonymous (SHA-256 of the device public key). Strict privacy profile required for SA consumers under POPIA §11.

where they compose

Identity continuity plus execution evidence.

Fingerprinting is mature, ubiquitous, and answers a real question — is this the same device that authenticated last week? — that EEI does not answer. EEI signs what the device does, not whether it's recognisable. The two layers compose:

Fingerprint identifies the device across sessions — even pre-login, pre-bootstrap, on web surfaces where EEI's runtime can't be embedded.
EEI signs what that identified device executed — the credential use, the biometric, the payload assembly, the network swap mid-transaction.
The operator's risk engine reads both: identity-similarity score from the fingerprint, signed execution record from EEI. Conditional, contextual policy replaces a single bit of "device approved".

Where fingerprinting struggles — fingerprint normalisation, farms, residential proxies, automation tools — EEI's hardware-bound key adds a different cost: extracting the private key from a TEE is a different problem than normalising traits. Where EEI doesn't reach — pure web surfaces, pre-app-install funnels — fingerprinting still works. Operators that ship both cover the surface.

Privacy regulation is shrinking the trait surface. User-Agent reduction, Privacy Sandbox, Android 13+ identifier restrictions, iOS App Tracking Transparency, and Apple's Privacy Manifest each remove or gate signals that fingerprinting historically relied on. On Android the stable identifier reduces toward SECURE_ID plus a few attestation bytes; on iOS the publicly readable trait surface narrows toward whatever App Attest emits. EEI's input — execution events signed with a TEE-bound key — is unaffected by these changes, because it does not depend on observable traits at all. The fingerprinting input shrinks with each platform release; the EEI input stays stable.

African mobile-network reality. On ASN-collapsed mobile networks where IP-class and geolocation lose discriminative power (large-NAT mobile operators across SADC, ECOWAS, EAC), fingerprinting accuracy degrades. EEI's hardware-bound key produces a different cost surface for adversaries that does not depend on network signals.

Web banking surfaces remain fingerprinting's domain. Where the runtime cannot be embedded — pure web banking, hybrid web-mobile flows pre-app-install, customer self-service portals — fingerprinting and behavioural biometrics (BioCatch, Featurespace ARIC, Forter device intelligence) remain the substrate. EEI does not reach there by construction. Inside the wallet app, terminal firmware, or kiosk shell, EEI signs what executed; the fingerprint score continues to identify the device across sessions.

frequently asked

Five questions, five answers.

·01 Is EEI a replacement for device fingerprinting?: No. Fingerprinting answers ‘is this likely the same device we saw before?’ — a probabilistic identifier derived from observable device traits. EEI answers ‘what did this device actually do, in what order, in what runtime state?’ — a deterministic, cryptographically signed record of execution. Identification and execution attestation are different problems. They compose.
·02 What does fingerprinting do that EEI does not?: Fingerprinting establishes a probabilistic device identifier across sessions, without requiring a hardware-bound key or a one-time bootstrap. It works on web, web-mobile, and any browser context where you cannot install runtime infrastructure. EEI does not replicate that — it requires a runtime module embedded in the app or terminal firmware.
·03 What does EEI do that fingerprinting does not?: EEI produces a cryptographically signed record that names exactly what executed — credential use, biometric, payload assembly, request submission, runtime state at each step. The record is verifiable independently with a public key, hash-linked to the previous event, replayable from the device ledger. Fingerprinting produces a similarity score that the operator's risk engine consumes; EEI produces evidence that the operator's risk engine, the dispute platform, the issuer, and the regulator can each verify.
·04 Are fingerprints spoofable?: Fingerprints derive from observable traits — user agent, screen size, font list, canvas hash, IP class, behavioural pattern. Adversaries with sufficient motivation can normalise their device to match a target fingerprint, especially on mobile. EEI's signing key lives inside the device's TEE; spoofing it requires hardware-key extraction, which is a different threat class entirely. The two answer different questions about adversarial cost.
·05 Can the two compose?: Yes. Fingerprinting can drive the identity-continuity layer — ‘this is the same device that authenticated last week’. EEI signs what that identified device actually did during this session — ‘the same hardware-bound key produced these signed events in this order’. Operators that ship both get probabilistic identity continuity plus deterministic execution evidence.

Operators with mature fingerprinting pipelines often want EEI underneath, not instead of.

We map your existing fingerprint signals to EEI's signal classes, show where execution evidence answers what the fingerprint can't, and where the fingerprint still does the work better. You keep the pipeline; you add the evidence.

Request a briefing

Probabilistic identity meets deterministic execution evidence.