eIDAS 2.0 Is Coming for Document-Based KYC: What a Credential-Ready Stack Actually Needs

Most KYC platforms verify a person by scanning a document: OCR the passport, check the security features, compare the photo, done. eIDAS 2.0 and the EU Digital Identity Wallet are built around a different object entirely a cryptographically signed credential that a user holds and presents, verified by checking a signature and a trust chain, not by inspecting a photo of a physical ID. Those are two different verification models, and the regulatory timeline that forces the switch is no longer theoretical.

The Timeline That Makes This Non-Optional

• eIDAS 2.0 (Regulation (EU) 2024/1183) entered into force in 2024, requiring every EU Member State to offer citizens a government-backed European Digital Identity Wallet.
• By the end of 2026, Member States are expected to have EUDI Wallets available, with cross-border interoperability testing already underway in several countries.
• By December 2027, large regulated private-sector relying parties banks, fintechs, insurers, telecoms are required to accept the EUDI Wallet for authentication.
• The EU's Anti-Money Laundering Regulation (AMLR) reaches full application on a similar 2027 timeline, and narrows the identity verification methods regulated entities can rely on to eIDAS-notified national digital ID schemes, the EU Digital Identity Wallet, or qualified trust services under eIDAS. A verification flow built entirely around scanning a passport photo isn't one of the three.

Why the Document-Scanning Model Doesn't Map to a Wallet-Based One

The EUDI Wallet doesn't hand a relying party a document image to inspect. It presents a Verifiable Credential or an mDL-style attestation issued by a trusted authority, cryptographically signed, and selectively disclosed the wallet holder controls exactly which attributes get shared for a given request. Verifying that means validating a signature and a trust chain against a registry of trusted issuers, not running OCR and a hologram check. A platform whose entire verification pipeline assumes "here is a photo of a document" as the input has nothing to do with an input that arrives as a signed credential. That's not a configuration gap. It's a different verification model, and retrofitting one onto the other under deadline pressure is a worse position than building for it now.

The parts of a KYC stack that specifically don't carry over: document image capture and OCR pipelines, physical security-feature detection (holograms, microprint), and manual document-authenticity review queues built entirely around ID photos. What does carry over and matters more under eIDAS 2.0: fraud and risk scoring, AML and sanctions screening, case management, and audit logging all of which still have to run, just against a different kind of verified input.

What a Credential-Ready Stack Needs to Support

• W3C Verifiable Credentials and DID-based issuance the underlying data model the EUDI Wallet and most credential-based verification systems are built on.
• Selective disclosure at the attribute level so a relying party requests and receives only the specific claim it needs (age over a threshold, KYC status, nationality) rather than a full identity document, in line with GDPR's data minimization principle that AMLR and eIDAS 2.0 both lean on.
• Cryptographic trust-chain validation checking a credential's signature and issuer chain against a trust registry, instead of a human or an OCR model inspecting a document image.
• Credential revocation that's checkable without contacting the issuer a relying party needs to confirm a credential hasn't been revoked in real time, without a synchronous callback to whoever issued it.
• Audit trails built for verification events, not document uploads a regulator asking "how was this person verified" needs a record of which credential was presented, which claims were disclosed, and how the signature was validated not a stored copy of a passport scan.

Notably absent from what a compliant stack strictly needs: a vendor that files your relying-party registration with a national eIDAS authority for you. That registration, and the legal work of confirming your specific AMLR obligations, stays with the business relying party status isn't something infrastructure can hold on your behalf.

Where Hypersign Maps to This

• A full W3C DID Core and Verifiable Credential stack (VC 1.1/2.0), with EdDSA/Ed25519, ES256K/Secp256k1, and BBS+ signature support, issuing credentials aligned with the eIDAS 2.0 framework and EUDI Wallet specification any eIDAS 2.0 compliant relying party can verify them.
• Selective disclosure through zero-knowledge and BBS+ proofs, so a relying party gets a pass/fail or threshold answer age over 18, KYC passed instead of the underlying document, matching the attribute-level disclosure the EUDI Wallet is built around.
• An on-chain Credential Revocation Registry using a bitstring status list, so revocation status is globally queryable in real time without a callback to the original issuer.
• Reusable KYC credentials a user verified once can present that credential to any connected relying party, rather than re-running document capture at every new platform which is the same "verify once" shape eIDAS 2.0 is standardising at the EU level.
• Selective disclosure explicitly built as AMLR-ready, aligned with the narrower set of verification methods AMLR permits from 2027.

What this doesn't do: register your business as a relying party with a national eIDAS authority, or make your specific AMLR gap analysis for you. Those are legal and regulatory steps a business has to complete itself. What credential-ready infrastructure changes is whether your verification pipeline can actually ingest, validate, and audit a wallet-based credential when a user shows up with one or whether that becomes a rebuild under a 2027 deadline instead of a capability you already have.

About Hypersign

Hypersign issues and verifies W3C Verifiable Credentials aligned with eIDAS 2.0 and the EU Digital Identity Wallet selective disclosure, on-chain revocation, and reusable credentials built in, so a KYC flow verifies cryptographic trust chains as readily as it verifies a document today.