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.
Supports EUDI Wallet and electronic attestation additions to the eIDAS framework.
European Digital Identity Framework
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.
Supports EUDI Wallet relying-party and wallet-provider role concepts.
Where a relying party intends to rely upon European Digital Identity Wallets
Key GDPR actors are controllers, processors, joint controllers, data protection officers where required, representatives where required, recipients, and supervisory authorities.
Supports controller, processor, and joint-controller responsibility concepts.
determines the purposes and means
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.
Supports eIDAS legal-effect and trust-service concepts.
legal framework for electronic signatures
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.
Supports Article 6 lawful-basis categories for processing personal data.
Processing shall be lawful only if
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.
Supports selective disclosure, collection limitation, and user approval in wallet presentations.
collection limitation
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.
Supports GDPR data minimisation and data protection by design and default.
only personal data which are necessary
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.
Supports trust-service and certificate validation evidence concepts.
validity or revocation status
GDPR evidence includes records of processing activities, notices, lawful-basis records, processor terms, retention rules, rights logs, data protection impact assessments (DPIAs) where high-risk processing requires one, and security control records.
Supports GDPR records of processing, accountability, DPIA, security, and rights evidence.
maintain a record of processing activities
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.
Supports wallet breach, suspension, withdrawal, and notification concepts.
breached or partly compromised
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.
Supports GDPR supervisory-authority, complaint, remedy, compensation, and fine mechanisms.
right to lodge a complaint
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.
Supports wallet user controls for sharing, deleting, viewing relying-party connections, erasure requests, and reporting suspicious requests.
request the erasure by a relying party
GDPR provides the broader rights framework for , including transparency, access, rectification, erasure, restriction, portability, objection, complaint, and judicial remedy routes where applicable.
Supports data-subject rights, complaint rights, and remedies under GDPR.
Right to erasure
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.
Supports treating eIDAS evidence as proof of identity and trust-service status or legal effect.
trust service providers established in the Union
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.
Supports treating GDPR evidence as proof of lawful, accountable personal-data processing.
lawfully, fairly and in a transparent manner
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.
Supports EUDI Wallet and electronic attestation additions to the eIDAS framework.
European Digital Identity Framework
GDPR identity-data rules
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.
Supports that eIDAS wallet rules operate without replacing GDPR obligations.
without prejudice to Regulation (EU) 2016/679
Covered actors
eIDAS and EUDI Wallet rules
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.
Supports EUDI Wallet relying-party and wallet-provider role concepts.
Where a relying party intends to rely upon European Digital Identity Wallets
GDPR identity-data rules
Key GDPR actors are controllers, processors, joint controllers, data protection officers where required, representatives where required, recipients, and supervisory authorities.
Supports controller, processor, and joint-controller responsibility concepts.
determines the purposes and means
Operational implication
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.
Supports assigning GDPR responsibility by purposes and means, not only by product role.
the purposes and means of processing
Identity legal effects and processing basis
eIDAS and EUDI Wallet rules
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.
Supports eIDAS legal-effect and trust-service concepts.
legal framework for electronic signatures
GDPR identity-data rules
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.
Supports Article 6 lawful-basis categories for processing personal data.
Processing shall be lawful only if
Operational implication
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.
Supports selective disclosure, collection limitation, and user approval in wallet presentations.
collection limitation
GDPR identity-data rules
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.
Supports GDPR data minimisation and data protection by design and default.
only personal data which are necessary
Operational implication
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.
Supports using selective disclosure to limit attributes presented to relying parties.
approve or deny the presentation
Evidence record
eIDAS and EUDI Wallet rules
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.
Supports trust-service and certificate validation evidence concepts.
validity or revocation status
GDPR identity-data rules
GDPR evidence includes records of processing activities, notices, lawful-basis records, processor terms, retention rules, rights logs, data protection impact assessments (DPIAs) where high-risk processing requires one, and security control records.
Supports GDPR records of processing, accountability, DPIA, security, and rights evidence.
maintain a record of processing activities
Operational implication
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.
Supports keeping evidence that demonstrates processing compliance.
be able to demonstrate compliance
Security and breach handling
eIDAS and EUDI Wallet rules
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.
Supports wallet breach, suspension, withdrawal, and notification concepts.
breached or partly compromised
GDPR identity-data rules
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.
Supports documenting breach facts, effects, and remedial action.
document any personal data breaches
Enforcement
eIDAS and EUDI Wallet rules
eIDAS issues go through eIDAS supervisory bodies, wallet supervisory and certification routes, trusted-list and qualified-status mechanisms, and national implementation structures.
Supports GDPR supervisory-authority, complaint, remedy, compensation, and fine mechanisms.
right to lodge a complaint
Operational implication
Route escalation by the failure type. Misleading wallet relying-party registration and unlawful personal-data collection may need both eIDAS and GDPR escalation paths.
Supports separate eIDAS handling for relying-party misuse while preserving GDPR reporting routes.
competent national data protection authority
User controls and individual rights
eIDAS and EUDI Wallet rules
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.
Supports wallet user controls for sharing, deleting, viewing relying-party connections, erasure requests, and reporting suspicious requests.
request the erasure by a relying party
GDPR identity-data rules
GDPR provides the broader rights framework for , including transparency, access, rectification, erasure, restriction, portability, objection, complaint, and judicial remedy routes where applicable.
Supports data-subject rights, complaint rights, and remedies under GDPR.
Right to erasure
Operational implication
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.
Supports treating user requests as controller obligations when GDPR applies.
The data subject shall have the right
Practical decision rule
eIDAS and EUDI Wallet rules
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.
Supports treating eIDAS evidence as proof of identity and trust-service status or legal effect.
trust service providers established in the Union
GDPR identity-data rules
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.
Supports treating GDPR evidence as proof of lawful, accountable personal-data processing.
lawfully, fairly and in a transparent manner
Operational implication
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.
Supports the conclusion that EUDI Wallet obligations and GDPR processing obligations must be read together.
without prejudice to Regulation (EU) 2016/679
Practical decision rule
How to use this comparison
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.
Supports the parallel GDPR record for personal-data processing.
the purposes of the processing
1
Section 1
The core distinction
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.
Supports the GDPR processing principles, controller and processor duties, rights, security, breach notification, and accountability requirements.
protection of natural persons with regard to the processing of personal data
2
Section 2
Identity-data decisions to make before launch
For each step in an EUDI Wallet or trust-service integration, assign the actual roles: wallet provider, relying party, trust service provider, certificate validator, attestation issuer, processor, controller, or joint controller.
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.
Supports GDPR minimisation, lawful basis, privacy by design and default, and accountability obligations.
adequate, relevant and limited to what is necessary
3
Section 3
Evidence that should not be merged
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.
Supports records of processing activities, controller accountability, security, and rights handling for identity-data processing.
be able to demonstrate compliance
4
Section 4
Security and rights overlap
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.
Official architecture reference used for wallet implementation details around selective disclosure, collection limitation, relying-party registration certificates, and linkability risk.
Supports implementation detail for selective disclosure, relying-party registration certificates, user approval, and linkability risks.
Supports the privacy risk discussion for selective disclosure, collection limitation, relying-party registration, and linkability.
Show 2 more
Supports selective disclosure, collection limitation, and user approval in wallet presentations.
Supports using selective disclosure to limit attributes presented to relying parties.