eIDAS vs GDPR identity-data obligations

eIDAS governs electronic identification schemes, EUDI Wallets, trust service providers, qualified trust services, electronic signatures, seals, timestamps, electronic registered delivery, website-authentication certificates, electronic attestations of attributes, and related legal effects.

GDPR governs processing of personal data, 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.

Start every project with two scope labels: the eIDAS role or artifact, and the GDPR processing activity. One does not automatically answer the other.

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 should not request data beyond that registered indication. Wallet design also supports selective disclosure.

GDPR requires personal data 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.

For an identity incident, run both analyses: whether wallet or trust-service reliability is affected, and whether personal data was breached under GDPR.

eIDAS issues go through eIDAS supervisory bodies, wallet supervisory and certification routes, trusted-list and qualified-status mechanisms, and national implementation structures.

GDPR issues go through data-protection supervisory authorities, corrective powers, administrative fines, complaints, compensation, and court remedies.

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 personal data, 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 personal data is involved: eIDAS proof that the identity or trust artifact is valid, and GDPR proof that the processing around it is lawful and limited.