The regulation is already in force
eIDAS 2.0 (Regulation (EU) 2024/1183) entered into force in 2024. It is past the discussion stage and into implementation. The core is a single requirement: EU member states must offer their citizens a digital identity wallet (EUDI Wallet), and a defined set of service providers must accept it.
"Must accept" is what gives the regulation its weight. It is not only a problem for whoever builds the wallet — it is a problem for everyone doing business in the EU.
What this means for Korean companies
There are two cases.
First, if you provide services in the EU. When a customer wants to present their identity from an EUDI Wallet, you have to be able to receive it. That is the Verifier role. Whether you build it yourself or plug in a product, you need an implementation that understands OID4VP 1.0 and HAIP 1.0.
Second, if you want identities issued in Korea to be usable in the EU. That is the Issuer role, and it is considerably harder. Credential format, signature algorithms and the trust framework all have to match what the EU has adopted.
What has been settled technically
The EU has based wallet-ecosystem interoperability on HAIP (High Assurance Interoperability Profile). HAIP is not a new standard; it is a profile that narrows a combination of existing ones.
| What | With what |
|---|---|
| Credential format | SD-JWT VC (with selective disclosure) and ISO/IEC 18013-5 mdoc |
| Issuance protocol | OID4VCI 1.0 |
| Presentation protocol | OID4VP 1.0 (`direct_post.jwt`) |
| Security | FAPI 2.0-grade authorization — PAR, PKCE, DPoP |
Saying you "support" this combination and actually interoperating are two different things. That is why the OpenID Foundation publishes a conformance suite. There is a test plan for each of issuer, verifier and wallet, and dozens of modules exercise both the happy path and the failure paths.
How to check readiness
When a vendor says "eIDAS 2.0 ready", there are three things to check.
1. Which roles were tested. Passing as an issuer only is not the same as passing as issuer, verifier and wallet.
2. Which version. OID4VCI/OID4VP went through several drafts before FINAL, and they are not compatible with each other.
3. How many SKIPPED and REVIEW results. Do not look only at the pass count. Which optional features were left unimplemented is hidden in those numbers.
This is why we publish our results module by module. A single summary number cannot answer any of the three.
What you can do now
Starting when the regulation takes effect is too late. The verifier role can be attached relatively quickly, but the issuer role takes time just to settle the credential schema and trust model. What to confirm now is simple — where in our service is identity needed, and which of those points touch the EU.