DOMAIN:EU_REGULATION:EIDAS¶
OWNER: eric, julian
ALSO_USED_BY: aimee, margot, ALL dev agents building auth or signing features
UPDATED: 2026-03-26
SCOPE: eIDAS 1.0 and 2.0, electronic signatures, EUDI Wallet, trust services
OVERVIEW¶
eIDAS (Electronic Identification, Authentication and Trust Services) is the EU regulation
establishing a legal framework for electronic identification and trust services.
It ensures that electronic signatures, seals, timestamps, and digital identity
are legally recognised across all EU Member States.
eIDAS 1.0: Regulation (EU) No 910/2014 — in force since July 2016
eIDAS 2.0: Regulation (EU) 2024/1183 — entered into force 20 May 2024
WHY_GE_CARES: every GE project that handles authentication, contract signing,
document verification, or identity proofing is affected. GE's own contract signing
with clients requires AES minimum. The EUDI Wallet will reshape how authentication
works in client applications by 2027.
EIDAS 1.0 — RECAP¶
TRUST_SERVICES_DEFINED¶
eIDAS 1.0 established legal definitions and cross-border recognition for:
ELECTRONIC_SIGNATURES: data attached to or logically associated with electronic data,
used to sign. Three levels defined (SES, AES, QES — see below).
ELECTRONIC_SEALS: similar to signatures but for legal persons (organisations).
Used to prove origin and integrity of documents. Three levels parallel to signatures.
ELECTRONIC_TIMESTAMPS: data binding other data to a particular time, establishing
proof that the data existed at that time. Qualified timestamps have legal presumption
of accuracy.
ELECTRONIC_REGISTERED_DELIVERY: service providing evidence of sending and receiving
electronic data, including protection against loss, theft, damage, or alteration.
EU equivalent of registered postal mail.
WEBSITE_AUTHENTICATION_CERTIFICATES (QWACs): qualified certificates binding a website
to its owner. Extended under eIDAS 2.0 with mandatory browser recognition.
TRUST_SERVICE_PROVIDERS¶
TSP — TRUST_SERVICE_PROVIDER: any entity providing one or more trust services
QTSP — QUALIFIED_TRUST_SERVICE_PROVIDER: TSP that has been granted qualified status
by a national supervisory body and appears on the EU Trusted List
EU_TRUSTED_LIST: centralized, publicly accessible database maintained by the
European Commission. Lists all QTSPs and their qualified trust services.
Updated monthly. Constitutive effect — a provider is ONLY qualified if listed.
URL: https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists
CROSS_BORDER_RECOGNITION¶
A qualified trust service from any EU/EEA QTSP on the Trusted List is automatically
valid in ALL 30 eIDAS countries. No additional recognition needed.
A QES from Estonia validates in Portugal. A qualified seal from Germany is
recognised in the Netherlands.
THREE SIGNATURE LEVELS¶
SES — SIMPLE_ELECTRONIC_SIGNATURE¶
DEFINITION: any data in electronic form attached to or logically associated with
other electronic data used as a method of authentication (Art. 3(10))
EXAMPLES: typing a name in an email, clicking "I agree", scanned handwritten signature,
checkbox + IP logging
LEGAL_STATUS: cannot be denied legal effect solely because it is electronic (Art. 25(1)).
However, burden of proof lies with the party relying on the signature.
USE_CASES:
- B2C terms acceptance
- internal approvals (low-risk)
- newsletter sign-ups
- non-binding confirmations
GE_GUIDANCE: SES is sufficient for most B2C interactions. Document the intent
to sign and capture metadata (timestamp, IP, user agent) for evidential weight.
AES — ADVANCED_ELECTRONIC_SIGNATURE¶
DEFINITION: electronic signature meeting four requirements (Art. 3(11) + Art. 26):
1. uniquely linked to the signatory
2. capable of identifying the signatory
3. created using data under the signatory's sole control
4. linked to signed data such that subsequent changes are detectable
EXAMPLES: PKI-based signatures with personal certificate, biometric + crypto signatures,
signing via authentication with strong identity verification
LEGAL_STATUS: stronger evidential weight than SES. In many jurisdictions treated
as presumptively valid. Still not equivalent to handwritten.
USE_CASES:
- B2B contracts (recommended minimum)
- GE client contracts (MANDATORY minimum)
- employment agreements
- procurement documents
- regulatory filings (where QES not required)
GE_GUIDANCE: AES is the minimum for GE's own contract signing with clients.
Eric must ensure all client contracts use AES or higher.
QES — QUALIFIED_ELECTRONIC_SIGNATURE¶
DEFINITION: advanced electronic signature created by a qualified electronic
signature creation device (QSCD) and based on a qualified certificate for
electronic signatures issued by a QTSP (Art. 3(12))
LEGAL_EQUIVALENCE: equivalent to a handwritten signature in ALL EU Member States (Art. 25(2)).
Cannot be denied legal effect. Presumption of validity. Shifts burden of proof to challenger.
REQUIREMENTS:
- qualified certificate from a QTSP on the EU Trusted List
- created on a qualified signature creation device (hardware security module or equivalent)
- identity of signatory verified to high assurance level (typically video ident or in-person)
USE_CASES:
- regulated industries (financial, healthcare, legal)
- real estate transactions
- notarial acts (some Member States)
- public procurement (some Member States mandate QES for bids)
- cross-border contracts where legal certainty is critical
GE_GUIDANCE: QES required when client operates in regulated industry or when
contract involves high-value, high-risk obligations. Cost is higher than AES
but provides maximum legal protection.
SIGNATURE_LEVEL_DECISION_MATRIX¶
1. regulated industry (finance, health, legal)? → QES required
2. real estate or notarial? → QES required
3. B2B contract, significant value? → AES minimum, QES recommended
4. B2B contract, routine? → AES minimum
5. B2C terms acceptance? → SES sufficient
6. internal approval workflow? → SES for low-risk, AES for policy decisions
7. cross-border, need certainty? → QES recommended
8. public procurement bid? → check country requirements (often QES)
EIDAS 2.0 — EUROPEAN DIGITAL IDENTITY WALLET¶
WHAT_CHANGED¶
eIDAS 2.0 (Regulation 2024/1183) amends the original eIDAS Regulation with
major additions:
- EUDI WALLET: every Member State must provide citizens with a digital identity wallet
- MANDATORY ACCEPTANCE: regulated sectors must accept the wallet for authentication
- SELECTIVE DISCLOSURE: prove attributes (e.g., "over 18") without revealing full identity
- OPEN SOURCE: wallet component source code must be open-source
- FREE OF CHARGE: wallet issuance, use, and revocation free for all natural persons
- VOLUNTARY: sufficient safeguards against discrimination for non-users
- QWACs: qualified website authentication certificates must be recognised by browsers
TIMELINE¶
| Date | Milestone |
|---|---|
| 20 May 2024 | eIDAS 2.0 entered into force |
| Sep 2024 | First functionalities integration started |
| 29 Sep 2025 | Implementing regulation for registered delivery adopted |
| End 2025 | Core trust services in place |
| Mar 2026 | Public feedback on implementing acts (deadline 5 March 2026) |
| 28 Apr 2026 | Trusted List v6 (TLv6) format mandatory — systems must upgrade |
| 24 Dec 2026 | ALL Member States must provide EUDI Wallets |
| Dec 2027 | Relying parties in regulated sectors must accept EUDI Wallets |
| 2030 | Target: 80% active adoption |
CURRENT_STATUS (March 2026)¶
- NO production-ready EUDI Wallets exist yet
- 350+ companies and government agencies in Large Scale Pilots across 26 Member States
- implementing acts still under development — compliance uncertainty remains
- four implementing regulations set uniform standards for wallet technical functionalities
- December 2026 deadline is ambitious — significant interoperability challenges remain
- parallel development across technical standards, certification, and business integration
WALLET_FEATURES¶
SELECTIVE_DISCLOSURE: the wallet uses zero-knowledge or attribute-based credentials
to prove specific attributes without revealing full identity.
EXAMPLE: prove you are over 18 without revealing date of birth or name.
VERIFIABLE_CREDENTIALS: diplomas, driving licences, health certificates stored as
machine-readable, cryptographically verifiable credentials in the wallet.
STRONG_AUTHENTICATION: the wallet provides eIDAS-compliant strong authentication.
Can replace username/password flows entirely.
CROSS_BORDER: a French wallet is accepted in the Netherlands and vice versa.
Full interoperability across all 27 Member States.
MANDATORY_ACCEPTANCE_SECTORS (from December 2027)¶
These sectors MUST accept EUDI Wallet for authentication:
- banking and payment service providers
- electronic money institutions
- healthcare providers
- telecom operators
- transport services
- large online platforms (VLOP under DSA)
- public administration services
EUDI_WALLET_IMPACT_ON_GE_PROJECTS¶
AUTHENTICATION:
- design auth flows that can integrate EUDI Wallet as a login method
- wallet provides higher assurance than most current auth methods
- consider wallet-first auth for projects launching after 2027
IDENTITY_VERIFICATION:
- wallet can replace manual KYC processes
- selective disclosure means less personal data collected → better GDPR compliance
- real-time verification of credentials (diplomas, licences, certifications)
SIGNING:
- wallet can create qualified electronic signatures
- mobile QES becomes accessible to everyone (currently expensive/complex)
- contract signing flows can be streamlined through wallet integration
ACTION_NOW:
- gap analysis for existing auth flows (can they support OIDC4VP or similar?)
- design flexible architecture — abstract identity provider layer
- track implementing acts for technical specifications
- prototype wallet integration when reference implementations become available
EU-BASED SIGNATURE PROVIDERS¶
GE MUST prefer EU-based providers for digital sovereignty and eIDAS compliance.
US-based providers (DocuSign, HelloSign) should NOT be primary for EU operations.
TIER_1 — RECOMMENDED¶
ZEALID (Sweden):
- qualified trust service provider (QTSP) on EU Trusted List
- specialises in qualified electronic signatures (QES)
- free remote identity verification
- PSD2 strong customer authentication
- partner of ABN AMRO and ondertekenen.nl
- ideal for: high-assurance signing needs, financial sector clients
SIGNICAT (Norway):
- QTSP under eIDAS, one of first certified under eIDAS 2.0
- 450+ clients, 20+ identity schemes globally
- 20M+ identities verified per month
- ISO 27001 certified
- connects to national eID schemes (DigiD NL, BankID NO/SE)
- ideal for: identity verification + signing combined workflows
SCRIVE (Sweden):
- EU-based e-signature platform
- strong in Nordic and EU markets
- advanced electronic signatures with evidence packages
- integrates with Nordic eID schemes
- ideal for: B2B contract signing, HR workflows
TIER_2 — ALSO_SUITABLE¶
VALIDSIGN (Netherlands):
- Dutch e-signature solution
- enterprise signing with workflow management
- NL-domiciled — full data sovereignty
CONNECTIVE (Belgium):
- Belgian digital signature and document management
- strong in Belgian government and enterprise
- qualified signing capabilities
YOUSIGN (France):
- French QTSP, eIDAS-compliant
- simple API integration
- strong in French-speaking markets
NOT_RECOMMENDED_AS_PRIMARY¶
DOCUSIGN (USA): not an EU QTSP. Acceptable for SES in global context.
Cannot provide QES natively. Data stored in US unless EU data residency configured.
HELLOSIGN (USA / Dropbox): same US jurisdiction concerns.
Not a QTSP. Limited to SES level natively.
ADOBE_SIGN (USA): strong PAdES support but US-domiciled.
Can integrate with EU QTSPs for QES but adds complexity.
NOTE: US providers are acceptable as secondary or for non-EU transactions.
For EU contracts, especially regulated sectors, use EU QTSPs.
REMOTE IDENTIFICATION FOR QUALIFIED SIGNATURES¶
To issue a qualified certificate, a QTSP must verify the signatory's identity
to a high assurance level. Several methods are accepted:
IN_PERSON: physical presence at a registration authority
VIDEO_IDENT: real-time video call with identity document verification
EIDI: using existing national eID (DigiD in NL, but NL DigiD is "substantial" not "high")
BANK_IDENT: identity verified through banking relationship (ZealID + ABN AMRO model)
EUDI_WALLET: once available, the wallet itself provides high-assurance identification
VIDEO_IDENT is the most common remote method for QES. The operator:
1. verifies physical document via video
2. performs liveness check
3. cross-references with government databases
4. issues qualified certificate bound to the verified identity
GE INTERNAL — CONTRACT SIGNING¶
CURRENT_REQUIREMENT¶
GE client contracts must use AES minimum (Eric's domain).
Process: Eric generates contract → client reviews → digital signature → archived with hash.
RECOMMENDED_FLOW¶
1. Eric generates contract (PDF/A-3 format for archival)
2. contract sent to client via secure channel
3. client signs with AES or QES (depending on client sector)
4. GE counter-signs with AES minimum
5. signed document archived with cryptographic hash
6. timestamp applied for long-term validation
7. audit trail preserved (who signed, when, from where)
PROVIDER_SELECTION_FOR_GE¶
FOR_ROUTINE_CONTRACTS: Scrive or ValidSign (AES level, simple workflow)
FOR_REGULATED_CLIENTS: ZealID or Signicat (QES available)
FOR_BELGIAN_CLIENTS: Connective (local compliance, QES)
ANTI_PATTERNS AND FIXES¶
ANTI_PATTERN: using DocuSign for all EU contract signing
FIX: DocuSign provides SES only (unless integrated with EU QTSP).
For B2B contracts, use an EU QTSP that provides AES or QES.
ANTI_PATTERN: storing signed documents without timestamp
FIX: always apply a qualified timestamp at signing time.
Without it, you cannot prove WHEN the document was signed, and certificate
expiry/revocation can invalidate the signature retroactively.
ANTI_PATTERN: treating all e-signatures as legally equivalent
FIX: SES, AES, and QES have fundamentally different legal weight.
SES can be denied effect; QES has presumption of validity. Match the
signature level to the legal requirement of the transaction.
ANTI_PATTERN: building auth flows that cannot accommodate new identity providers
FIX: abstract the identity provider layer. Use OIDC/SAML with pluggable providers.
The EUDI Wallet will use OIDC4VP (OpenID for Verifiable Presentations).
Hard-coding a single identity provider creates technical debt.
ANTI_PATTERN: collecting full identity data when only an attribute is needed
FIX: with EUDI Wallet selective disclosure, you can verify "over 18" or
"resident of NL" without collecting name, address, date of birth.
Design data collection to request minimum necessary attributes.
ANTI_PATTERN: assuming national eID schemes interoperate automatically
FIX: under eIDAS 1.0, cross-border eID recognition was patchy.
eIDAS 2.0 + EUDI Wallet fixes this, but until wallets are live,
verify which national eIDs your auth flow actually supports.
ANTI_PATTERN: not checking the EU Trusted List before accepting a "qualified" signature
FIX: a signature is only qualified if the QTSP appears on the EU Trusted List.
Implement Trusted List validation in your verification workflow.
Library: eu-digital-identity DSS (Digital Signature Services) — open source.
ANTI_PATTERN: ignoring Trusted List v6 format change (28 April 2026)
FIX: systems that consume the EU Trusted List must upgrade to TLv6 format
(ETSI TS 119 612 v2.4.1) by 28 April 2026. Failure to upgrade may break
validation of qualified signatures. Test against TLv6 before the deadline.
TECHNICAL REFERENCES¶
EU_TRUSTED_LIST: https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists
DSS_LIBRARY: https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109107
EUDI_WALLET_HUB: https://www.eudi-wallet.eu/
EIDAS_REGULATION: https://eur-lex.europa.eu/eli/reg/2014/910
EIDAS_2_REGULATION: https://eur-lex.europa.eu/eli/reg/2024/1183
READ_ALSO:
- domains/eu-regulation/digital-signatures.md
- domains/eu-regulation/peppol-e-invoicing.md
- domains/security/authentication-patterns.md
- domains/compliance-frameworks/gdpr-implementation.md