Deepfakes broke one-time KYC. Continuous trust is what replaces it.

For fifteen years, digital identity verification rested on one assumption: check a person carefully once, at the moment they open an account, then trust the session afterwards. The whole compliance apparatus was built on it. Onboard, verify, log the evidence, move on.

That assumption is now false, and the numbers behind its collapse are not marginal.

Entrust analysed more than one billion identity verification events across 195 countries and more than 30 industries for its 2026 Identity Fraud Report.1 Deepfakes accounted for one in five biometric fraud attempts. Deepfaked selfie submissions rose 58% in a single year. Injection attacks, where manipulated media is fed directly into the verification pipeline rather than held up to a camera, grew 40% year over year.

Read that last figure again, because it is the one that changes the architecture. A deepfake presented to a camera is a hard problem with known defences. A deepfake injected past the camera entirely is a different problem.

Presentation attacks and injection attacks are not the same fight

The distinction matters more than any single statistic, and a surprising number of procurement conversations still blur it.

A presentation attack happens in front of the sensor. Someone holds up a printed photo, replays a video on a screen, wears a silicone mask, or points a phone at a monitor displaying a generated face. The camera captures something real. That something is fake. Liveness detection was invented for this. Texture analysis, depth sensing, challenge-response, reflection patterns, and micro-movement analysis all work reasonably well here, and vendors have a decade of adversarial hardening behind them.

An injection attack skips the sensor. The attacker uses a virtual camera driver, a rooted device, a modified app, a compromised SDK, or an intercepted API call to hand the system a video stream that no camera ever produced.4 The frames are pristine because they were rendered, not captured. Every liveness signal that depends on the physics of a real capture becomes meaningless, because the attacker controls the physics.

Two attacks, two defences

This is why a system can score well on presentation attack detection benchmarks and still be trivially defeated in the field. The benchmark tests the wrong layer.2

Alberto Lima of FaceTec has argued for cryptographically signed biometric barcodes as one response: bind the biometric evidence to a signature at the point of capture, so that anything arriving without a valid signature is rejected regardless of how convincing it looks. The logic generalises beyond any single vendor. If you cannot trust the content of the stream, you have to be able to trust its provenance.

Provenance means the device has to vouch for itself

Once you accept that content-based detection alone is insufficient, the question becomes what you can trust instead. The answer running through most serious architectures in 2026 is the device.

Device integrity and attestation move the trust anchor from "does this face look real" to "did this capture come from an unmodified app running on an uncompromised device that can prove it cryptographically". Nuno Ponte of Multicert and David Rabuat of Famoco have both worked on this in practice, and the honest summary is that it helps substantially and solves nothing completely.

It helps because it eliminates the cheapest attacks. Virtual cameras, emulators, rooted devices, and repackaged apps all become detectable. That removes the long tail of low-effort fraud, which is most of the volume.

The practical conclusion is that no single control carries the load. Signal from the capture, signal from the device, signal from the network, signal from behaviour, and signal from the document all have to be combined. The combination has to be tuned against actual attack data rather than a vendor datasheet.

The Portuguese Social Security case

Abstraction is easy in this field, so it is worth looking at a deployment with numbers behind it.

Biometrid and the Portuguese Social Security built a fraud prevention system using biometric and AI engines to detect identification fraud at scale in a public service context. Frederico Costa and José Pedro Neto presented the work at LisbonID 2026, and what makes it instructive is the setting rather than the technology.

Public services cannot select their users. A bank can decline a customer whose device fails attestation and accept the lost revenue. A social security system cannot decline a pensioner with an eight-year-old Android phone, because that pensioner has a legal entitlement and no alternative. The population includes people with limited digital literacy, damaged identity documents, medical conditions that affect biometric capture, and no realistic fallback channel.

That constraint forces a different design. Instead of a single gate that admits or refuses, you build layered assessment: low-friction checks for the vast majority, escalation for anomalies, and a human path that actually functions for the cases automation cannot resolve. The fraud detection has to be strong enough to protect public money and permissive enough not to exclude the people the system exists to serve.

Every commercial deployment faces a diluted version of the same tension. The public sector just faces it without the option of walking away.

What continuous trust actually means

"Continuous trust" is at risk of becoming a slogan, so it is worth being concrete. John Erik Setsaas of Setsaas Trust Advisory has framed it as risk-based authentication extended across the whole account lifecycle, and the operational content is specific.

• Verification becomes a stream rather than an event. Identity confidence has a value at every moment, not just at onboarding. It rises when signals agree, decays when they do not, and decays with time even when nothing suspicious happens.
• Assurance is matched to consequence. Checking a balance and moving €40,000 to a new beneficiary are not the same action and should not require the same confidence.
• Re-verification has a trigger model. A new device, an impossible travel pattern, a change of beneficiary, a dormant account waking up, a support call requesting a credential reset.
• Enrolment binds to something durable. If the only thing linking a person to an account is a one-off selfie in a database, an attacker who defeats that single check owns the account permanently.

Most systems still gate at the door and leave the interior open, which is why 82% of payment-related fraud in the Entrust data concentrates at authentication stages on active accounts rather than at onboarding, and why 55% of digital banking fraud is account takeover.1

Those two figures deserve emphasis. The industry spent a decade hardening onboarding. Attackers responded by attacking accounts that were already open, where the identity check had already passed and nobody was looking anymore.

Binding to a device credential, a wallet-held attestation, or a passkey creates something the attacker has to defeat again on every subsequent interaction. This is where the European wallet framework and the anti-fraud conversation converge, and the connection is under-appreciated. A wallet-held attestation issued after high-assurance proofing gives a relying party something no selfie check can: verified evidence with a known provenance, a known issuer, a revocation path, and cryptographic binding to a device. It does not eliminate fraud. It changes what an attacker has to compromise, from a probabilistic image check to a chain of cryptographic assertions.

Hardware as the fallback when software runs out

There is a strand of this discussion that gets dismissed as legacy thinking and deserves better.

Giuseppe Guagliardo of NXP asks whether chips are still a secure place for your identity. Vincent Gourmelen of Linxens works on securing electronic documents. Christophe Halopé of CST works on physical features that support digital trust. Emilie Bonnefoy of Open Sezam frames authentication around what you know, what you have, and what you are, which is not a new formulation but remains the correct one.

The common thread is that when software-based verification faces an adversary with generative models, hardware-rooted evidence gains value rather than losing it. A secure element holding a private key that never leaves the chip is resistant to an entire category of attack that AI has made cheap. A document with physical security features requires the attacker to be physically present with physical materials, which is expensive in a way that generating video is not.

The framing that matters is cost asymmetry. Generative AI collapsed the cost of producing convincing fake evidence.2 Controls that raise the attacker's cost back up, especially controls that require physical presence or possession of certified hardware, restore an asymmetry that pure software checks have lost.

None of this argues against biometrics or software verification. It argues that the answer is layered, and that the layers should fail in different ways.

What to change in the next six months

• Test for injection, not just presentation. If your vendor's evidence is limited to presentation attack detection certification, you have not tested the attack that grew 40% last year. Ask about virtual camera detection, SDK integrity and injection resistance, and ask for red team evidence rather than lab benchmarks.
• Move controls beyond the front door. Map every high-consequence action in your product and ask what identity confidence you require for each. Most organisations discover that the answer for actions after login is "whatever we established at signup, indefinitely".
• Instrument decay. Record when identity confidence was last established for each session and each account, and let that value influence authorisation. An account verified four years ago on a device that no longer exists is not a verified account.
• Keep a functioning human path. Automation will refuse legitimate people. A fallback that is technically available and practically unusable is the same as no fallback.
• Measure what you reject. False rejection rates are a fraud metric. An attacker who forces you to tighten thresholds until you block genuine customers has achieved a result, and most dashboards will not show it as an attack.

The debate worth having in person

The technical arguments in this field are well documented. The disagreements are not.

Vendors disagree about whether content analysis or provenance verification should carry more weight. Regulators and product teams disagree about how much friction is acceptable. Public sector and private sector disagree about what an acceptable exclusion rate looks like, because one has customers and the other has citizens. Those disagreements do not resolve in white papers.