Fighting Document Fraud: Think from the Other End

Key points made by Stephan D. Hofstetter during the panel discussion on ‘Combating Document Forgery’ at Identity Week Europe 2026 at the RAI Amsterdam.

Most conversations about document security start with procurement. Which features. Which technology. Which vendor. How many pages in the RFP.

That is the wrong starting point.

The fight against document fraud doesn't begin with what you buy. It begins with a precise

understanding of what you are trying to achieve — and an honest assessment of how well what you deploy actually achieves it in the real world, with real users, in real environments.

Three claims from my presentation at Identity Week Europe that challenge the conventional thinking.

#01 — A credential no one can authenticate is not secure

A highly sophisticated credential that cannot be professionally authenticated at the point of inspection is not more secure than a Disney World membership card.

This sounds provocative. It isn't. It is the most basic test in document security, and it is routinely underweighted — not because the authorities procuring these systems lack expertise, but because the question is rarely asked in the right order, against the right operational context.

Physical security features matter enormously. They are the backbone of document integrity, and decades of accumulated knowledge across standards bodies, security printers, and issuing authorities have made modern travel documents exceptionally difficult to counterfeit. That investment deserves respect — and it deserves to be protected by ensuring those features can actually be used.

A feature that requires specialist laboratory equipment, expert training, or controlled conditions to verify does not lose its value — but it cannot carry the full weight of security at the border post, the law enforcement spot check, or the car rental counter on its own. The physical security architecture of a document and the operational verification capability at the point of inspection must be designed together, as a system. Where that alignment is missing, complexity accumulates without translating into operational security.

The question that should precede every procurement decision is not "how sophisticated is this feature?" or even "how secure is this document?" It is: how good does a counterfeit need to be to pass the validator? The uncomfortable answer is: good enough. Not perfect. Not indistinguishable from the genuine article under laboratory conditions. Just good enough to get through the specific check, performed by the specific person, in the specific environment, under the specific operational pressures that person is working under at that moment.

That reframing changes everything. It shifts the design question from the document in isolation to the ecosystem around it — the inspector, the tool, the environment, the time available, the training received. A security feature is only as strong as the point at which it is relied upon. Designing for the full chain, not just the credential, is what separates a secure system from a secure-looking one.

Procurement that focuses on acquiring "a passport system" will very likely get you a system. The harder discipline — and the one that determines whether that system actually reduces fraud — is defining what the system must achieve, for whom, and under what conditions, before a single requirement is written.

#02 — AI is not the end of physical documents. It is the end of complacency.

Some actors in or around the identity industry have developed a habit of using AI as a rhetorical endpoint. AI can mimic physical documents in online sessions — therefore physical documents are obsolete. The logic sounds clean. It doesn't hold, and it is a false framing.

Most physical documents were never specified or developed to operate in a digital environment. When a passport or identity card is presented remotely — photographed, scanned, or streamed — it is stripped of most of the security technologies it was designed around. The substrate, the ink chemistry, the optical variable devices, the tactile features: gone. What the IDV system receives is a flat image. Authenticating that image reliably against the original document's security architecture is, in most cases, simply not possible.

Calling this a failure of physical documents misdiagnoses the problem. It is a failure of scope — deploying a credential in an environment it was never designed for, then concluding the credential is the weak link.

By the same reasoning, AI exposes and exploits gaps in digital systems with equal — arguably greater — thoroughness and speed. The threat is symmetric. If AI makes physical credentials obsolete, it makes digital credentials equally vulnerable. The difference is that we have decades of hard-won knowledge about how to design, issue, and inspect physical credentials. Digital identity systems are still accumulating theirs.

What AI actually demands is not a choice between physical and digital. It demands clarity of purpose. Know what your credential is designed to do. Know the specific threat it is designed to counter. Know the environment in which it will be used and the people who will use it. Design for that — not for a general sense of security, and not in response to the last industry headline.

That is the difference between doing a job and getting the job done.

#03 — Think like a user, not like an engineer

Procure systems and credentials with the actual users and their actual environments in mind. Not only the ideal user in a well-equiped airport bordercontrol booths and extensive and repeatedly updated trainings. The other ones, too.

The law enforcement officer at a rural crossing, working with a handheld device on a network that drops in and out, making a decision in seconds with no colleague to consult and perhaps just a onetime quick training.

The guard at an automated gate in a major hub, trained on the equipment but not on the edge cases — who now has to interpret a system message that the engineers understood perfectly and that means nothing to her in the moment it matters. The member of the general public filling in an ETA application on a cracked phone screen, in a language that is not their first, under time pressure, without a help desk.

These are not edge cases. They are the operational reality for a significant proportion of the interactions these systems are designed to handle. Designing for the exception — the expert user, the optimal environment, the controlled conditions — and treating everything else as a training problem is a form of willful blindness that the security of the system cannot afford.

Technically sophisticated does not mean operationally secure. A system that a senior engineer finds elegant but a frontline officer finds confusing will be bypassed, ignored, or misread. Not out of negligence — out of necessity. People under operational pressure find workarounds. They always have. A security architecture that depends on perfect user behaviour in imperfect conditions is not security. It is an assumption dressed as a design.

The discipline of thinking like a user is not a concession to the lowest common denominator. It is the highest standard of systems design. The users of these systems — officers, administrators, dealers, travellers, employers — may not share our enthusiasm for the science behind the security technology. They should not need to. That is not their failure. It is ours, if we build systems that only work when everyone behaves as we hoped they would.

Security that holds under real conditions, with real people, is the only kind that counts.

The uncomfortable structural problem

Most advisory in this market comes from vendors. That is not a criticism — it is a structural reality. If you ask a passport manufacturer what kind of passport you need, you will get a passport.

Independent advice means someone who can say: maybe you don't need a new document system right now. Maybe you need better inspection training and a PKI that actually works. Maybe the weakest point in your chain is not the credential — it is the process around it.

Define the threat. Define the use case. Everything else — features, security levels, physical or digital — follows from that. A government that can answer those questions precisely will write a better RFP in two pages than one that cannot answer them in two hundred.

Stephan Hofstetter is Managing Partner of SECOIA Executive Consultants AG and Editor of CEN TS 17489-5, the trust framework for breeder documents. SECOIA provides independent advisory to governments and authorities on ICAO TRIP strategy, secure document procurement, and border management.