The surprising journey from the sci-fi Multi Pass to real-world, secure Digital Identity solutions.
This article is inspired by a talk delivered by Licel co-founder and CTO, Mikhail Dudarev, at Droidcon London 2025.
Rewatching sci-fi movies from the 1990s can be quite a disorienting experience sometimes – especially for those of us old enough to remember seeing them when they were first released. What seemed at the time to be impossible-to-imagine dates far into the future are often now, well, the present day. And while some predictions have fallen flat, others have aged remarkably well.
The 1997 cult sci-fi classic, The Fifth Element, is set in the 23rd century, and so we have a while to wait yet to know whether yellow cabs will hover as high as the tallest skyscrapers in New York City. Other predictions from the movie, however, appear to have come to pass already. Take the famous Multi Pass, for example, flashed by protagonist Leeloo Dallas to prove who she is and to unlock access to places and services. It feels a lot closer to reality than fiction.
The Multi Pass moment in the film The Fifth Element.
Today, identity documents are moving onto the smartphone at remarkable speed. Driver’s licences, visas, health records, and hand written signatures used to exist in plastic cards, paper booklets, and government databases. The fact they are moving to mobile apps marks a profound and exciting shift. But while identity is moving from hardware to software, trust will have to travel with it; and that might be a trickier journey, because trust simply cannot be assumed in the digital age.
In the following paragraphs, we’ll do a bit of future thinking ourselves. We’ll take a look at the trajectory of Digital ID applications in the next decade and set out what is required to secure identities; first of humans and then of the AI agents we’ll increasingly rely upon to carry out digital tasks for us.
When fiction meets reality: the modern digital identity ecosystem
The more you examine the Multi Pass from The Fifth Element, the clearer it becomes; what appeared at the time to be a visual gag might – even if by accident rather than by design – have been a blueprint for how deeply integrated future digital identity ecosystems could become. It’s surprisingly prophetic.
Modern identity schemes such as European Digital Identity Wallets, digital driving licenses, digital travel credentials, or ePassports, all follow strict international specifications designed to make identity secure and verifiable across borders. The overlap between these and the fields on the Multi Pass is remarkable.
For example:
- The 3D hologram on the Multi Pass maps neatly with ICAO Doc 9303 requirements for biometric facial imagery
- Personal data like name, date of birth, and nationality is a pretty close match for DG1 and DG11 data groups in ePassports
- Driving license permissions correspond to the ISO/IEC 18013-5 mobile driving license standard
- Travel access permissions are formalized through Digital Travel Credentials (DTC Types 1 and 3) under ICAO
- Payment system linkage echoes the direction of EUDIW and the Digital Euro, where regulated private sector services (including payments) can rely on government-issued credentials
What once looked futuristic is now being actively implemented by governments, integrators, and wallet providers around the world.
Today’s emerging digital identity wallets won’t just prove who you are. They will unlock access to services, authenticate payments and sign ups, validate your legal status, and sign binding agreements – all from the convenience of a device you already carry everywhere.
Your eyes might have been drawn to the health status field on the Multi Pass, which reads “Viral State: Low.” One suspects that this detail would have been interpreted differently by viewers of the movie either before or after the coronavirus pandemic. Before, it might have seemed unnecessary or even an invasion of privacy to have such a field on your ID document. But having lived through that strange time, we can probably all remember having to carry some form of proof either of having had a vaccine against the virus or of receiving a negative result from a test.
It’s also a reminder of what’s at stake from a security perspective. Identity data is sensitive, sure, but health data is incredibly sensitive. We might be willing to share some of our personal data, while we would want other data to be completely hidden all of the time. Health data falls squarely in that second category.
This is why designing a Digital ID app is so complex. It isn’t simply a case of creating a digital version of the Multi Pass – of placing some UI over a credential – but rather of building a complete ecosystem of cryptography, secure storage, attestation, and controlled interactions with the physical world.
The way we choose to design and build Digital Identity solutions in the next decade will likely determine whether citizen end users can trust them or not.
What does a Digital ID application actually do?
Something else that makes the design and delivery of a Digital ID app challenging is that it has to carry out three completely different - and equally critical - functions. And each of them requires highly advanced security mechanisms.
The first of these is the enrolment stage. Remember; when the Digital ID app is downloaded from an app store, it is essentially an empty vessel. Enrolment is where a blank mobile app becomes a verified identity. This involves biometrics, document checks, NFC passport reading, and the approval of the backend. But this is also the stage where deepfakes, camera injection malware and virtual camera apps can facilitate eKYC fraud, potentially enabling attackers to bypass verification altogether and create fake citizens within the database.
The second use case of a Digital ID app is verification. This is when you present your ID – or at least parts of it – quickly and privately. Imagine you’re at the airport, preparing to board a flight, or you’re at the car rental agency to pick up a pre-booked vehicle. There are security risks associated with presenting your identity, however. These include overlay attacks, NFC relay attacks, and malware that can modify what is being shown or sent.
Finally, there’s the act of signing. This is potentially one of the biggest efficiency savings people can look forward to with a Digital ID app; the idea of using it to make a digital signature, payment, or legal authorization quickly and easily. Strong protection for private keys and secure execution is absolutely vital if the act of signing or making transactions is to be done safely, because if an attacker were able to extract or misuse keys, then they could impersonate a user easily.
Building Trusted Identity: the foundations
For each of these three functions, there are some key principles that need to be realized if we want to put the foundations in place for building trusted identity solutions:
Trusted enrolment (that can combat the threat of eKYC fraud) requires a combination of liveness checks and attestation. If either the device or the human using that device cannot be verified or trusted, then that identity shouldn’t be enrolled. A physical ID document is also sometimes required to be read via an NFC interface, which opens up the NFC relay attack vector again.
Key protection needs a combination of secure storage and device binding, because non-exportable cryptographic keys are the backbone of Digital ID authenticity (and therefore the amount of trust citizens will have in it). If keys can leak, identities can be copied, and trust will break down.
Tamper resistance relies on integrity verification and runtime checks. The upshot of identification moving to mobile apps is that they will be operating in an untrusted environment where threats like hooking and dynamic instrumentation tools float in the ether. These threats need to be detected and then stopped.
Verifiable operations are also a must. Digital ID systems have to be able – via cryptographic proofs and attestation – to prove that each operation (signing, authentication, presentation of credentials) has been carried out by the genuine app, on a trusted device, and in an uncompromised runtime environment.
The technical building blocks of digital trust
So, we’ve set out the key principles for building trusted identity. But how to actually go about achieving it? That’s where vital mobile channel protection mechanisms come into play. They should be seen by governments and integrators as non-negotiable if they want to deliver tamper-resistant digital identity solutions that citizen end users can buy into and trust.
Trusted capture and document verification is a good place to start. Mechanisms must be put in place that can verify that document scans are authentic, the capture pipeline hasn’t been manipulated, and liveness and anti-spoofing checks cannot be bypassed.
Keys for signing, authentication, and credential validation must be stored in a secure form and operated in a secure environment - and they should be bound to the device and app instance. This secure storage and secure environment implementation must be CC EAL4+ (VAN.5) certified.
A secure execution environment (be that a TEE or a virtual TEE) is also vital, providing a secure vault for document signing, credential presentation, operations involving private keys, and other sensitive transactions and operations. This isolated, self-defending space is incredibly important to offset Digital ID moving to an untrustworthy, mobile environment.
A trusted execution environment should also be reinforced by RASP (runtime application self protection) and integrity checks, which help to make sure that the application hasn’t been modified, that dynamic instrumentation tools like Frida are detected, and that the integrity of the app is intact both before and during operations.
Mutual TLS and end-to-end encryption is also important to make sure that the server is communicating with a legitimate, unmodified app, that the app is connected to the correct backend, and that data is protected both in transit and at rest.
Real time visibility and the ability to make more nuanced security decisions completes the loop, and that’s where threat telemetry comes in. This provides visibility into malware activity, tampering attempts, and attack trends over time, all of which can help to improve long-term security posture.
All of the security mechanisms above are vital for Digital ID protection, but one in particular is worthy of further exploration; the concept of trusted execution and, in particular, how a virtual trusted execution environment (vTEE) can help to secure Digital ID initiatives in the years to come.
Let’s dig a little deeper.
The concept of trusted execution
The main concern about our digital identities moving to the smartphone is that the mobile channel is inherently untrusted. And so we have to somehow bring security to a place that isn’t secure by default or design. The key concept of trusted execution is therefore to divide the execution environment between two worlds; the trusted world and the untrusted world.
It might help to think of a trusted execution environment as a secure room within a larger, riskier building. It’s a protected space where private keys can be stored, and sensitive operations and transactions can take place. If the world outside is noisy and chaotic, the trusted execution environment is calm and peaceful. It’s like plugging into your noise-cancelling headphones; the chaos outside is still there, but it can’t touch you.
Inside the trusted execution environment – in this quieter, trusted world – a trusted application operates. A specialized app designed to run in that environment, it handles sensitive operations like encryption, decryption, authentication, and secure storage. The fact that the trusted application is running in an isolated and secure environment gives it an extra layer of protection. You might think of it as the Common Criteria (CC) EAL 4+ (VAN.5) secure chip of the digital world.
In a wider sense, the concept of trusted execution is the mechanism that brings the security guarantees of a physical passport - with its hundreds of years of security and anti-fraud measures – to a device that wasn’t built for security and also runs hundreds of different apps, about 50 open browser tabs, and, potentially, some dormant malware.
It combines the key factors of isolation, confidentiality, integrity, secure execution, and controlled access that are so integral to every global Digital ID framework, including eIDAS 2.0 / EUDI Wallet, and ISO/IEC identity standards.
Why a Virtual Trusted Execution Environment (vTEE) is ideally placed to secure Digital ID apps
An EMVCo Virtual Trusted Execution Environment (vTEE) is a purely software solution that operates in the same way and achieves the same goals as any TEE, but has little to zero specific hardware support. The fact that it is a software TEE actually gives it several advantages over hardware TEEs when it comes to securing Digital Identity apps, such as:
- Cross-platform compatibility
- Allows custom trusted applications with enhanced functionality to be run
- Scalability, developer friendly, and flexible
- No vendor lock-in, making for easier deployment
When evaluated under frameworks such as EMVCo SBMP TEE, virtual TEEs are held to rigorous security requirements, even though the implementation isn’t tied to a hardware enclave.
The image below illustrates how the Licel vTEE (itself EMVCo evaluated and approved for both Android and iOS) works. Operating inside the client application, it helps to make the untrusted world (the wider mobile channel) trusted via mechanisms such as secure storage, while its Trusted Virtual Machine (VM) can host trusted applications.
This security matters for Digital ID applications because the Licel vTEE makes sure that enrolment, credential storage, PACE/EAC flows, digital signatures, and cryptographic operations can take place in a secure, integrity-controlled environment. Even on devices that don’t have strong hardware.
Another way to think of it is that trust is no longer dependent on the device itself when there’s a secure, reliable enclave inside the application.
Talking to Digital ID apps
You might be reading this article and thinking “I probably won’t be designing and building a Digital ID app myself.” However, if you’re involved in developing other applications such as mobile banking, healthcare, or travel apps, then it’s likely that your app will have to communicate with a Digital ID app in some way. In the coming years, Digital ID won’t sit in isolation but will be a universal trust anchor that other apps will rely on. A kind of secure, portable identity core inside the device that other apps will request proof from.
These other apps will ask questions of it such as:
- Is this person really who they claim to be?
- Does this person have the right (age, license type, residency status) to be making this request?
- Can you (the Digital ID wallet) sign this transaction or consent form?
The thing is, other applications will only trust and rely on the Digital ID application to answer these questions and carry out these tasks if they know there are robust security layers underpinning it that can withstand malware, OS-level manipulation, and device compromises. Building secure Digital ID apps and systems therefore matters even to teams who will never build one.
As the table below highlights, there are already several international standards that define how apps request identity data, verify credentials, or obtain digital signatures from a Digital ID wallet. These frameworks ensure consistency, privacy, and cross-border compatibility.
Standards for Communication
When not only humans need their identity protected
If Digital ID is to become the universal trust layer on the device, what does that mean for the future of identity? And how do we ensure that trust holds over time?
These would be big, important questions if we were only talking about protecting human identities. But a time is fast approaching when autonomous AI agents, acting on your behalf, will also need to prove who they are and what they are permitted to do.
A bit like the Multi Pass from The Fifth Element predicting the future of identification at the beginning of this piece, other sci-fi movies have predicted that AI entities (albeit physical ones) would be carrying out day-to-day tasks for us. I, Robot is one example – set in 2035 for what it’s worth. And again, what was once far-fetched sci-fi is now becoming an accepted part of our world. After all, AI systems are already logging into services, initiating transactions, and interacting with mobile apps and cloud infrastructure. But right now there aren’t tamper-proof, standardized ways to make sure that the legitimate AI agent is making a request, on whose behalf, and whether it has permission to do so. This could increasingly cause problems in the near future as the threat landscape becomes even more chaotic with fraudulent, spoofed, or cloned AI assistants initiating harmful transactions or acting without visibility or accountability, to name but two potential risks.
How to go about naming and identifying our AI agents, though?
Humans have spent millennia developing naming systems that encode roles, lineage, and accountability, even if we don’t tend to think of it as such. In Ancient Rome, for example, a full name wasn’t just a label, but a structured identity. Let’s take one of Rome’s most famous citizens; Gaius (personal identifier) Julius (broader clan or community) Caeser (specific family branch). Naming our AI agents so we can verify their identity safely can lean on similar conventions, while also incorporating something even more fundamental: cryptographic truth.
An AI agent’s unique ID could be its non-reusable personal identifier; the equivalent of a human first name. The question “who created me?” would be the clan – the organization, model family, or platform. And another question “on whose authority do I act?” is the equivalent of the family branch; the specific project or permission scope. The additional layer and, arguably, the most important question here is “have I been tampered with?” which requires a cryptographic proof of identity, verified in real time. An AI agent’s identity must be non-spoofable, non-exportable, bound to a device or a secure runtime, and cryptographically verifiable before any action is taken.
The same foundations that are required to protect human Digital IDs are the ones we need to secure those of AI agents. If those agents are going to sign documents, request credentials, authorize payments, or act on behalf of people, then we need trusted execution (TEE or vTEE), device binding and cryptographic identity, runtime integrity checks, trusted signals for behavioral verification, and secure channels for presenting and verifying credentials.
From the Multi Pass to the future of secure Digital Identity
In the Fifth Element, the Multi Pass acts as a universal credential; something that is very close to what governments and integrators around the world are currently working on. Albeit the modern Digital Identity is far more complex. The Multi Pass is still a physical card, but modern identity is moving from hardware to software, and it isn’t a foregone conclusion that end user trust will make the same journey quite as smoothly. Not when millions of consumer devices are compromised, tampered, untrusted.
In such an environment, trusted execution is the key to making the untrusted trusted; making the unsecured secured. Whether delivered by more traditional hardware TEEs or software-based vTEEs, trusted execution is the minimum requirement if secure Digital Identities are to be realized. It’s a requirement that is also set out across the growing ecosystem of interoperable specifications around the world.
Getting the secure foundations of Digital ID in place now is vital, because trusted execution, verifiable credentials, and cryptographic proofs won’t just form the backbone of human ID verification, but will also work for AI agents in the near future.
Securing our Digital Identity is one of the most exciting challenges of our time. Let’s make sure that we get it right.
