- Insights
Digital identity risk assessment: what happens after eID verification?
Lessons from Hopae’s work on Kantara’s Digital Identity Risk Universe: the risks that appear after an eID is verified, and how to manage them.
ㅣ
Junmin (Eric) Kim
ㅣ
7 min read
ㅣ
Lessons from Hopae's contribution to Kantara's Digital Identity Risk Universe (DIRU)
A user presents a credential. The signature checks out. Your service accepts it.
Then the user replaces their phone. The credential's status changes. A third party asks for more data than the transaction needs. None of these moments happen at onboarding, yet each one can turn a working integration into an incident.
That is why a digital identity risk assessment has to cover the whole credential lifecycle, not just the moment of eID verification. A working connection is the start of the job, not the end.
The Digital Identity Risk Universe (DIRU), published by the Kantara Initiative in May 2026, gives teams a shared map for exactly this work. Hopae's Junmin (Eric) Kim contributed to the discussion group behind it, and group chair John Fiske publicly acknowledged Eric alongside the other contributors. This post explains what DIRU covers, where we see risk concentrating in real integrations, and how to turn the framework into a working risk register.
What is the Digital Identity Risk Universe (DIRU)?
The Digital Identity Risk Universe is an open taxonomy of digital identity risks, published by the Kantara Initiative with an accompanying report on its methodology and on how organizations can use it to build their own risk register.
163 risks in total: 98 relating to human digital identity and 65 relating to AI agents.
Lifecycle scope: it covers issuance, use, change, recovery and retirement of credentials, not only identity proofing at onboarding.
A vocabulary, not a rulebook: DIRU does not prescribe mitigations or a risk-scoring method. Each organization still decides which risks apply, how serious they are and what to do about them.
That separation is deliberate, and useful. A wallet provider, an issuer and a relying party (the business that accepts and verifies a credential) carry different responsibilities. A shared map shows where those responsibilities meet, which is usually where things break.
For a quick overview, John Fiske discusses the framework in Kantara's Identity Insights interview on DIRU.
Where does digital identity risk sit after verification?
In our experience connecting businesses to eIDs and digital wallets, the most serious risks rarely sit inside one component. They sit in the handoffs between them.
Take a user moving to a new phone. For the user, the goal is simple: keep access to the services they already use. For the organizations involved, it raises three hard questions:
How is the user's authority to recover or replace the credential established?
What happens to the credential and keys left on the old device?
If the old credential should no longer be accepted, how does the verifier find out?
Our view: a recovery flow that leaves a usable credential on an uncontrolled device is a defect, not a trade-off. Equally, a recovery process so restrictive that users lose access to essential services is a failure of a different kind. Both have to be designed explicitly, across the wallet provider, issuer and verifier.
This question is about to become urgent. EU member states must make EUDI Wallets available to citizens by the end of 2026, with obligations for many private relying parties following in late 2027. Millions of people will change phones in that window. Every relying party will inherit the consequences of how wallet recovery was designed.
Each component can behave exactly as specified while the end-to-end process still leaves a gap. That is the case for a lifecycle view.
3 questions for your digital identity risk assessment
These are practical review questions from Hopae's experience, not prescribed DIRU controls. Take them into your next architecture review.
1. What does a successful verification result actually establish?
Be explicit about the checks behind a "verified" result: the credential's origin, its validity and status, and any required binding between the person presenting it and the credential itself.
Then define how uncertainty is represented. A status service that is unavailable is not the same as a credential that has been revoked. If both collapse into a generic error, the business cannot make a sound decision, or explain it to a regulator later.
Status check result | What it means | Suggested relying party action |
|---|---|---|
Valid | The issuer confirms the credential is active | Accept, if all other required checks pass |
Revoked or suspended | The issuer has withdrawn the credential | Reject and log the reason |
Status service unavailable | Outcome unknown | Apply the risk-based fallback agreed in advance |
Stale status (cache expired) | Outcome uncertain | Re-check, or step up to another verification method |
Agree these outcomes before you design the fallback, not after the first outage.
2. Can the service get what it needs without collecting more?
An age check and a full identity check serve different purposes. Requested attributes, retained data and operational logs should all match the transaction. Selective disclosure in modern wallets makes this possible; your own systems have to keep the promise.
Review the complete flow, including analytics, debugging and customer support. A carefully minimized credential request delivers little privacy benefit if a log file or support ticket keeps the full record anyway. This is a conversation for product, engineering and privacy teams to have together.
3. Who acts when trust conditions change?
A credential expires. A key is compromised. An issuer's status changes. Your review should name who detects the event, who updates the relevant information, and who decides what the relying party does next.
Responsibilities should be specific enough to test. An integration plan that names a dependency but leaves its failure behavior undefined is unfinished.
What are the identity risks of AI agents?
Forty percent of the DIRU taxonomy, 65 of its 163 risks, concerns AI agents. That proportion reflects where the industry is heading: agents booking travel, opening accounts and completing purchases on a person's behalf, often presenting that person's credentials to do it.
For relying parties, agentic transactions raise questions that traditional eID flows never had to answer:
Delegation: did the person actually authorize this agent, and can you prove it?
Scope: is the agent's authority limited to this transaction, this amount, this time window?
Distinction: can your service tell the person apart from their agent, and treat each appropriately?
Revocation: when the person withdraws consent, how quickly does every service the agent touched find out?
Our expectation is that agent delegation will become one of the defining identity problems of the next few years. Teams designing wallet integrations today should leave room for it in their architecture rather than retrofitting it later.
How to build a digital identity risk register
For a team starting with DIRU, the most useful first step is small: pick one real transaction and walk it through issuance, use, recovery and retirement.
Choose one flow. For example, account opening with a national eID, or age verification with a wallet credential.
Map it against DIRU. Identify which of the 163 risks apply to each stage.
Record five fields for each relevant risk: the affected component, a named owner, the existing control, the evidence needed to test it, and a review date.
Agree what is unresolved. Write down the open risks and when they will be reviewed.
Repeat for the next flow. Expand only once the first register is being maintained.
A short register tied to real architecture and real decisions beats a spreadsheet that copies every DIRU entry and is never opened again.
Why connecting eIDs and wallets exposes these risks
Hopae builds the network infrastructure that connects businesses with eIDs and digital wallets. That work puts us at the boundaries between systems, where technical assumptions and operational responsibilities have to line up, and where most of the risks above first appear.
Industry work like DIRU gives practitioners a place to examine those boundaries together. We are grateful for John Fiske's leadership and for the contributions of the entire Kantara DIRU discussion group.
For any business planning an identity integration, DIRU is a strong starting point for a better review: what could fail, who would be affected, and who owns the response?
Frequently asked questions
What is the Kantara Digital Identity Risk Universe?
It is an open taxonomy of digital identity risks published by the Kantara Initiative in May 2026, with a companion report explaining how organizations can use it to build their own risk register.
How many risks does DIRU include?
163: 98 relating to human digital identity and 65 relating to AI agents.
Does DIRU tell you how to mitigate risks?
No. DIRU provides a shared vocabulary and structure. It does not prescribe controls or a scoring method; each organization decides which risks apply and how to treat them.
What is a digital identity risk assessment?
A structured review of what could go wrong when an organization issues, accepts or relies on digital identity credentials, who would be affected, and who owns the response. A good one covers the full credential lifecycle, not just onboarding.
What happens to a digital credential when you change phones?
It depends on the wallet and issuer. A well-designed recovery flow re-establishes the user's authority, issues or moves the credential to the new device, and ensures any old credential that should no longer be accepted is invalidated, with verifiers able to detect the change.
Download Kantara's Digital Identity Risk Universe, or talk to Hopae about connecting eIDs and digital wallets to your service.
About the author
Junmin (Eric) Kim is Head of Trust at Hopae, where he works on identity assurance and trust frameworks, making sure the eIDs and digital wallets Hopae connects meet the security, privacy and regulatory standards that relying parties depend on, including eIDAS 2.0 and the EUDI Wallet rollout. He contributed to the Kantara Initiative's Digital Identity Risk Universe discussion group.
