Separate eIDAS duties for electronic identification, trust services, qualified certificates, and EUDI Wallet relying parties from GDPR duties for personal-data processing.
This comparison helps scope roles, lawful basis, minimisation, relying-party evidence, security controls, breach handling, and user-rights records without treating one regime as a substitute for the other.
eIDAS and GDPR often meet in the same identity journey, but they answer different questions. eIDAS defines the EU framework for electronic identification, EUDI Wallets, trust services, signatures, seals, certificates, attestations, validation, and relying-party recognition. GDPR applies when identity attributes, wallet logs, signatures, certificates, contact details, authentication events, or support records are processed by a controller or processor. The practical result is usually two linked records: one proving the eIDAS role, service, legal effect, or wallet requirement, and one proving the GDPR purpose, lawful basis, minimisation, security, retention, and rights handling for the same data flow.
Side-by-side comparison
eIDAS vs GDPR for identity data
Use these rows to decide which regime answers each operational question in an identity, wallet, or trust-service flow.
This side helps classify the identity means, wallet role, trust service, certificate, attestation, validation result, legal effect, and relying-party registration evidence.
Second framework
GDPR identity-data rules
This side helps classify the controller or processor role, purpose, lawful basis, minimisation, transparency, rights, security, breach, retention, and accountability evidence.
GDPR governs processing of , including identity attributes, identifiers, authentication events, wallet connection logs, certificate-holder data, support records, and security records when they relate to an identified or identifiable natural person.
Key eIDAS actors include Member States, wallet providers, relying parties, trust service providers, qualified trust service providers, issuers of electronic attestations, supervisory bodies, and conformity assessment bodies.
Key GDPR actors are controllers, processors, joint controllers, data protection officers where required, representatives where required, recipients, and supervisory authorities.
A relying party can also be a GDPR controller for its attribute request and retention. A trust-service provider can also be a controller or processor for certificate and validation data.
eIDAS supplies identity and trust-service legal effects, such as recognition of notified eID schemes, qualified signature and seal effects, certificate validity checks, and wallet relying-party requirements.
GDPR still requires a lawful basis for each personal-data processing purpose, such as consent, contract, legal obligation, public task, vital interests, or legitimate interests where available and not overridden.
Do not cite eIDAS status as the whole privacy justification. Keep a GDPR lawful-basis entry for each identity-data collection, validation, storage, sharing, monitoring, and deletion purpose.
EUDI Wallet relying parties must register their intended wallet use and indicate the data to be requested; they shall not request data beyond that registered indication. Wallet design must support selective disclosure where the relevant attestation can disclose attributes selectively.
GDPR requires to be adequate, relevant, limited to what is necessary, and protected by design and by default so only necessary personal data is processed for each purpose.
Build the attribute-request review around the stricter practical result: ask only for registered, purpose-linked, necessary attributes, and prefer selective disclosure or a derived proof where it satisfies the use case.
eIDAS evidence includes relying-party registration, intended wallet use, requested data, authentication and identification of the relying party, validation of person identification data or attestations, trusted-list checks, and certificate validity or revocation status.
GDPR evidence includes records of processing activities, notices, lawful-basis records, processor terms, retention rules, rights logs, DPIAs where high-risk processing requires one, and security control records.
Keep validation proof and personal-data proof linked but distinct. A successful wallet or certificate validation does not prove the retained data was necessary, transparent, or stored for an appropriate period.
eIDAS focuses on reliability and security of identity means, wallets, trust services, certificates, validation services, and supervised qualified services; wallet breaches can trigger suspension, withdrawal, user and relying-party notifications, and supervisory handling.
GDPR focuses on risk to natural persons from personal-data processing, including appropriate security measures and supervisory-authority notification where a personal-data breach is likely to create risk.
eIDAS issues go through eIDAS supervisory bodies, wallet supervisory and certification routes, trusted-list and qualified-status mechanisms, and national implementation structures.
Route escalation by the failure type. Misleading wallet relying-party registration and unlawful personal-data collection may need both eIDAS and GDPR escalation paths.
EUDI Wallet rules include user-facing controls such as selecting, deleting, sharing, presenting, viewing relying-party connections and exchanged data, requesting erasure by a relying party, reporting suspicious data requests, and using data portability features.
GDPR provides the broader rights framework for , including transparency, access, rectification, erasure, restriction, portability, objection, complaint, and judicial remedy routes where applicable.
Design user journeys so wallet controls and GDPR rights requests are routed coherently. A wallet dashboard action may need a GDPR fulfilment workflow behind it.
Accept eIDAS evidence for what it proves: identity assurance, trust-service status, wallet role, relying-party registration, certificate validity, signature or seal validation, attestation status, or legal effect.
Accept GDPR evidence for what it proves: purpose, lawful basis, transparency, minimisation, controller or processor accountability, security, retention, rights handling, breach handling, and transfer safeguards where relevant.
A compliant identity journey needs both columns when is involved: eIDAS proof that the identity or trust artifact is valid, and GDPR proof that the processing around it is lawful and limited.
GDPR governs processing of , including identity attributes, identifiers, authentication events, wallet connection logs, certificate-holder data, support records, and security records when they relate to an identified or identifiable natural person.
Key eIDAS actors include Member States, wallet providers, relying parties, trust service providers, qualified trust service providers, issuers of electronic attestations, supervisory bodies, and conformity assessment bodies.
Key GDPR actors are controllers, processors, joint controllers, data protection officers where required, representatives where required, recipients, and supervisory authorities.
A relying party can also be a GDPR controller for its attribute request and retention. A trust-service provider can also be a controller or processor for certificate and validation data.
eIDAS supplies identity and trust-service legal effects, such as recognition of notified eID schemes, qualified signature and seal effects, certificate validity checks, and wallet relying-party requirements.
GDPR still requires a lawful basis for each personal-data processing purpose, such as consent, contract, legal obligation, public task, vital interests, or legitimate interests where available and not overridden.
Do not cite eIDAS status as the whole privacy justification. Keep a GDPR lawful-basis entry for each identity-data collection, validation, storage, sharing, monitoring, and deletion purpose.
EUDI Wallet relying parties must register their intended wallet use and indicate the data to be requested; they shall not request data beyond that registered indication. Wallet design must support selective disclosure where the relevant attestation can disclose attributes selectively.
GDPR requires to be adequate, relevant, limited to what is necessary, and protected by design and by default so only necessary personal data is processed for each purpose.
Build the attribute-request review around the stricter practical result: ask only for registered, purpose-linked, necessary attributes, and prefer selective disclosure or a derived proof where it satisfies the use case.
eIDAS evidence includes relying-party registration, intended wallet use, requested data, authentication and identification of the relying party, validation of person identification data or attestations, trusted-list checks, and certificate validity or revocation status.
GDPR evidence includes records of processing activities, notices, lawful-basis records, processor terms, retention rules, rights logs, DPIAs where high-risk processing requires one, and security control records.
Keep validation proof and personal-data proof linked but distinct. A successful wallet or certificate validation does not prove the retained data was necessary, transparent, or stored for an appropriate period.
eIDAS focuses on reliability and security of identity means, wallets, trust services, certificates, validation services, and supervised qualified services; wallet breaches can trigger suspension, withdrawal, user and relying-party notifications, and supervisory handling.
GDPR focuses on risk to natural persons from personal-data processing, including appropriate security measures and supervisory-authority notification where a personal-data breach is likely to create risk.
eIDAS issues go through eIDAS supervisory bodies, wallet supervisory and certification routes, trusted-list and qualified-status mechanisms, and national implementation structures.
Route escalation by the failure type. Misleading wallet relying-party registration and unlawful personal-data collection may need both eIDAS and GDPR escalation paths.
EUDI Wallet rules include user-facing controls such as selecting, deleting, sharing, presenting, viewing relying-party connections and exchanged data, requesting erasure by a relying party, reporting suspicious data requests, and using data portability features.
GDPR provides the broader rights framework for , including transparency, access, rectification, erasure, restriction, portability, objection, complaint, and judicial remedy routes where applicable.
Design user journeys so wallet controls and GDPR rights requests are routed coherently. A wallet dashboard action may need a GDPR fulfilment workflow behind it.
Accept eIDAS evidence for what it proves: identity assurance, trust-service status, wallet role, relying-party registration, certificate validity, signature or seal validation, attestation status, or legal effect.
Accept GDPR evidence for what it proves: purpose, lawful basis, transparency, minimisation, controller or processor accountability, security, retention, rights handling, breach handling, and transfer safeguards where relevant.
A compliant identity journey needs both columns when is involved: eIDAS proof that the identity or trust artifact is valid, and GDPR proof that the processing around it is lawful and limited.
Name the eIDAS artifact or role before naming privacy controls: wallet provider, relying party, trust service provider, qualified certificate, attestation, signature, seal, validation service, or trusted-list check.
For each personal-data field, record the GDPR purpose, lawful basis, controller or processor role, retention rule, security measure, and rights route; add an Article 9 condition or national-law basis where the data and purpose require one.
Reject attribute requests that are not registered for the relying-party use case or not necessary for the GDPR purpose.
Escalate incidents through both tracks when they affect trust-service or wallet reliability and personal-data confidentiality, integrity, availability, or rights.
Use eIDAS first to classify the identity or trust-service function: notified electronic identification scheme, EUDI Wallet, relying party, qualified trust service provider, qualified certificate, electronic signature, seal, timestamp, registered delivery, website authentication certificate, or electronic attestation of attributes.
Use GDPR next to classify the processing of inside that function. The eIDAS text itself says the regulation is without prejudice to GDPR, so a valid eIDAS identity or trust-service flow still needs GDPR records when personal data is collected, stored, validated, shared, logged, or retained.
eIDAS evidence shows why the identity or trust-service artifact can be relied on.
GDPR evidence shows why each personal-data processing step is lawful, limited, secure, transparent, and reviewable.
Do not use a qualified certificate, wallet registration, or trusted-list entry as a blanket lawful basis under GDPR.
For an EUDI Wallet or trust-service integration, the first product decision is not a generic privacy label. It is whether the product is acting as a wallet provider, relying party, trust service provider, certificate validator, issuer of attestations, processor, controller, or joint controller for each step.
The second decision is the exact data request. Under eIDAS wallet rules, relying parties register intended wallet uses and the data they request; under GDPR, controllers must keep adequate, relevant, and limited to what is necessary, and apply data protection by design and default. Those tests should be reviewed together before adding an attribute request, account-linking field, retention rule, or analytics event.
Identity data is not automatically special-category data under GDPR. Biometric data falls under Article 9 only when it is processed for uniquely identifying a natural person, and processing national identification numbers is subject to Member State conditions under Article 87. A wallet field can therefore need an Article 6 lawful basis, an Article 9 condition, national-law review, or a combination, depending on the data and purpose.
Record the relying-party purpose and requested attributes before requesting wallet data.
Map each identity attribute to a GDPR purpose and lawful basis. Where Article 9 special-category data is involved, record the separate Article 9 condition as well; do not bundle unrelated purposes into the same request.
Keep separate records for certificate validity checks, signature validation, wallet-presented attributes, support logs, and fraud/security monitoring.
Test whether pseudonyms, selective disclosure, or proof of a fact can satisfy the use case without collecting the full attribute set.
A single audit folder can hold both regimes, but the proof points should remain labelled. eIDAS evidence is about identity assurance, wallet registration, trusted-list status, certificate status, qualified service status, validation outputs, conformity assessment, and trust-service supervision. GDPR evidence is about processing purpose, lawful basis, controller or processor role, notices, records of processing activities, rights handling, security measures, breach assessment, and retention.
This separation matters when a relying party keeps wallet transaction data. The eIDAS-side record may show that the relying party registered the intended wallet use and identified itself to the user. The GDPR-side record must still explain why the stored attributes or logs are needed, who controls them, how long they are retained, who receives them, and how rights requests are handled.
Label each evidence item with the legal question it answers: eIDAS status, wallet role, trust-service validity, GDPR lawful basis, GDPR rights, or GDPR security.
Store certificate and attestation validation results separately from raw identity attributes where possible.
Keep a change log for new wallet attributes, relying-party registrations, processor terms, retention rules, and security controls.
Use data-protection review when eIDAS evidence contains or creates persistent linkability risk.
Security duties overlap but are not identical. eIDAS focuses on the reliability of electronic identification means, EUDI Wallets, trust services, certificates, validation, and supervised qualified services. GDPR focuses on the risks to people from personal-data processing and requires appropriate technical and organisational measures for controllers and processors.
Rights handling also overlaps. The EUDI Wallet framework includes user-facing wallet capabilities such as viewing relying-party connections and requesting erasure from relying parties. GDPR supplies the broader rights framework, including access, rectification, erasure, restriction, portability, objection, and complaint routes where the processing falls within GDPR.
Treat a wallet or trust-service security incident as both a service-reliability question and a personal-data breach question when is affected.
Give users a route to understand what identity data was requested, by whom, for what purpose, and how to exercise GDPR rights.
Use the EUDI Wallet ARF privacy guidance to test attribute minimisation, relying-party linkability, and whether fixed identifiers can be discarded after validation.
Escalate separately to the eIDAS supervisory path and the data-protection authority path when both regimes are implicated.