GDPR and data protection
Overview
GDPR applies to all personal data processed in connection with a LuxID integration; this page explains how obligations are split between LuxID (POST Luxembourg) and the Partner as independent controllers, and what each must do.
Regulation (EU) 2016/679 (opens in a new tab) (GDPR) applies to all personal data processed in connection with a LuxID integration. This page provides guidance for Partners on how GDPR obligations are allocated between LuxID and the Partner, what the Partner must do independently, and how LuxID supports Partners in meeting their obligations.
This page is not legal advice. Partners should consult their own data protection counsel and DPO (where one is appointed). All references to GDPR articles are to Regulation (EU) 2016/679 (opens in a new tab).
Controller and processor roles
Understanding the allocation of GDPR roles is the starting point for every other obligation. The LuxID Agreement makes the allocation explicit, and it has consequences for every other section of this page.
POST Luxembourg as controller
POST Luxembourg is the controller for:
- Authentication event data - the record of every login attempt, MFA step, token refresh and logout associated with a user's LuxID Account. POST determines the purpose (security, fraud prevention, user account management) and the means (log format, retention period, access controls). This data never leaves POST's systems; Partners access a view of it via the Event Hub, but do not receive the underlying records.
- Account profile data - the user's email address, phone number, name, language preference and linked credentials (passkeys, MFA methods) held at https://account.luxid.lu/ (opens in a new tab). POST sets the purposes for holding this data (account management, authentication) and the means (database, encryption, retention).
- Consent records - records of the user's consent to release claims to specific Partners. POST is the controller for the consent event; the Partner is responsible for its own record of what lawful basis it relies on for processing those claims after receipt.
The Partner as independent controller
The Partner becomes an independent controller for:
- Claims received from LuxID - from the moment a claim (email, name, phone, etc.) is delivered to the Partner's application in a token or userinfo response, the Partner controls that data. The Partner sets its own purposes, retention period and processing means.
- Partner-side authentication records - any log the Partner maintains of LuxID authentication events (for example, "user X signed in at time T via LuxID") is Partner-controlled data.
- Derived data - any data derived from the received claims (for example, a user profile created using the LuxID-provided email) is Partner-controlled.
LuxID E.I.G. does not process user personal data
The LuxID E.I.G. is a party to the LuxID Agreement as the brand licensor and invoicing entity. Under the agreement, the LuxID E.I.G.'s processing activities are explicitly limited to invoicing-related data about the Partner. The LuxID E.I.G. does not process user personal data, neither as controller nor as processor.
This is a deliberate architectural choice. It means GDPR obligations relating to users sit on POST (as operator) and the Partner (as recipient of claims), not on the LuxID E.I.G.
No joint controllership, no processor relationship
The LuxID Agreement is explicit on two points:
- The relationship between POST and the Partner is controller-to-controller. Each party determines the purposes and means of its own processing; neither instructs the other. The conditions for joint controllership under GDPR Article 26 (opens in a new tab) are not met.
- There is no sub-processing relationship between POST and the LuxID E.I.G., nor between either of them and the Partner, within the meaning of GDPR.
The practical consequence is that there is no separate Data Processing Agreement (DPA) to sign. The LuxID Agreement itself is the data protection framework - the security obligations normally found in an Article 28 DPA are built into the agreement body and security annexes. See Legal Agreements and Templates - Why there is no separate DPA for more on this design choice.
If your integration requires an arrangement that would meet the joint-controllership test (for example, a co-designed processing flow), contact LuxID to discuss an amendment.
Lawful basis
LuxID's lawful basis
LuxID relies on the following lawful bases for processing user data:
| Processing activity | Lawful basis |
|---|---|
| Authentication (verifying credentials) | Contract (Art. 6(1)(b)) - necessary to provide the LuxID authentication service the user has registered for |
| MFA (OTP, TOTP, passkeys) | Contract (Art. 6(1)(b)) - necessary to provide secure authentication |
| Account management (profile updates, password reset) | Contract (Art. 6(1)(b)) |
| Releasing claims to Partners | Consent (Art. 6(1)(a)) - user consents via the LuxID consent screen before claims are released |
| Security logging and fraud prevention | Legitimate interests (Art. 6(1)(f)) - LuxID has a legitimate interest in maintaining platform security; this interest is not overridden by the user's rights given the security purpose |
| Legal obligations (GDPR, NIS2 compliance) | Legal obligation (Art. 6(1)(c)) |
The partner's lawful basis
The Partner must independently identify and document its lawful basis for processing each claim received from LuxID. The LuxID consent screen covers the release from LuxID to the Partner; it does not provide the Partner's lawful basis for what it does with the claim thereafter.
Contract (Article 6(1)(b)) is the appropriate basis for claims that are objectively necessary to deliver the service the user has signed up for:
- Email address: almost always necessary for account creation, communication and account recovery in the Partner's system
- Name: necessary only if the service cannot function without it (for example, a service that issues named certificates or requires identity for legal compliance)
The necessity test is strict. If the service could function without the claim - even if the claim would be convenient - contract is not the correct basis.
Consent (Article 6(1)(a)) is appropriate for claims that enhance the service but are not strictly necessary:
- Profile photo
- Date of birth (unless required for age verification as a legal obligation)
- Phone number (if the Partner offers optional 2FA using the LuxID-provided number)
Because the user has already consented via the LuxID consent screen to the release of the claim, the Partner does not need to ask again at the point of receipt. However, the Partner must record that it relies on consent and must honour consent withdrawal.
Legal obligation (Article 6(1)(c)) applies where the Partner is required by law to verify the user's identity (for example, Know Your Customer obligations in financial services). In this case the legal obligation is the Partner's own regulatory requirement, not a GDPR basis granted by LuxID.
Legitimate interests (Article 6(1)(f)) should be used with caution. It requires a documented legitimate interests assessment (LIA) demonstrating that the Partner's interests are not overridden by the user's fundamental rights. It is unlikely to be appropriate as the sole basis for processing authentication claims.
Special categories of data
LuxID does not release special category data (Article 9 GDPR: health, biometric identity, racial or ethnic origin, etc.) as standard claims. LuxID Verified may involve the processing of identity document data during the verification process; that processing is conducted by LuxTrust and LuxID under their respective controllers' frameworks, not by the Partner. The Partner receives only the verification outcome (for example, "identity verified" and a name), not the underlying identity document.
If a Partner's use case involves special category data beyond the verification outcome, the Partner must identify its own Article 9(2) basis and document it separately.
Consent
The LuxID consent screen
Before releasing any optional claims to a Partner, LuxID presents the user with a consent screen. This screen:
- Identifies the Partner by name
- Lists the claims that will be released
- Distinguishes between claims that are required for the service and claims that are optional
- Allows the user to decline optional claims individually
- Records the user's consent with a timestamp
The consent screen is hosted by LuxID and cannot be bypassed or customised by the Partner. This design ensures that consent is collected under LuxID's controlled environment, independent of the Partner's UI.
See Privacy and consent for the technical mechanics of the consent flow.
What Partners should and should not do
Partners should:
- Accept the claims returned after consent - if the user declines an optional claim, the Partner receives that claim as absent and should handle this gracefully (for example, by prompting the user to provide the information directly in the Partner's UI)
- Record in their own system that the user authenticated via LuxID and what claims were received
- Maintain their own record of the lawful basis relied on for each claim category
Partners must not:
- Attempt to circumvent the consent screen by requesting claims via a different mechanism
- Re-request claims the user declined at the LuxID consent screen without a legitimate new purpose
- Use claims for purposes beyond those described in the privacy notice the user had access to when they consented
Consent withdrawal
A user can revoke a Partner's access to their LuxID Account at any time via https://account.luxid.lu/ (opens in a new tab) > Applications. When a user revokes access:
- LuxID stops releasing claims to the Partner on future authentication attempts
- The Partner should not rely on the absence of a future token as a signal; LuxID will send a revocation event via the Event Hub (see Events and Event Hub)
- The Partner must stop relying on the consent as a lawful basis for processing LuxID-received claims already in its system from the point it becomes aware of the revocation
- If consent was the Partner's only lawful basis for a particular claim, the Partner must cease processing and delete that claim
Data minimisation
GDPR Article 5(1)(c) requires that personal data be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed.
At the integration design stage
Partners should design their claim request to include only the claims they actually use in the Partner application. Requesting claims speculatively - "we might use this later" - is not compliant with the minimisation principle.
LuxID enforces claim minimisation at the configuration level: the LuxID Agreement specifies the claim templates the Partner is authorised to request, and the LuxID Console will not allow the Partner to request claims outside that scope. If a Partner genuinely needs an additional claim for a new feature, it must amend the LuxID Agreement before requesting it.
At the data storage stage
Once claims are received, Partners should consider:
- Avoid duplicating data unnecessarily. If the LuxID-provided email is the primary identifier, there is no need to also store it in a separate analytics profile unless that profile serves a distinct stated purpose.
- Avoid enriching LuxID claims with third-party data without a separate lawful basis and privacy notice update.
- Pseudonymise where possible. If the Partner's internal systems can function using a pseudonymous identifier (for example, the user's LuxID subject identifier
sub) for most purposes, the email should only be stored where it is specifically needed.
Retention
LuxID retention
LuxID retains authentication event logs (security and functional traces) for 6 months on a rolling basis in the Console. Partners can access their application's event log via the Console and Event Hub during this window.
Account profile data (email, name, phone) is retained for as long as the user's LuxID Account is active. After a prolonged period of inactivity the account is deactivated; profile data is retained only as long as necessary and in line with legal obligations. A deactivated account can be reactivated for a limited period by contacting LuxID support; after that the account is deleted and the data is erased, except the minimum LuxID must keep to meet legal obligations (for example, records of breach notifications or regulator correspondence). A user who deletes their own account does so immediately and permanently - there is no grace period and no reactivation. Cookie and navigation data is retained for a maximum of 13 months.
Partner retention
Partners are solely responsible for their own retention policy for claims received from LuxID. The retention period must be:
- Proportionate to the purpose (Article 5(1)(e) GDPR)
- Stated in the Partner's privacy notice
- Enforced by a deletion or anonymisation procedure
If a user deletes their LuxID Account, LuxID will send an account deletion event via the Event Hub. On receiving this event, the Partner should review whether it has a continuing lawful basis to retain the user's data or whether deletion is required.
User rights
GDPR Articles 15 to 22 grant data subjects a set of rights. The following table describes how each right is handled across the LuxID/Partner boundary.
| Right | LuxID-held data | Partner-held data |
|---|---|---|
| Art. 15 - Access | User accesses their authentication history and profile at https://account.luxid.lu/ (opens in a new tab). Partners can also request a log extract for the user via LuxID. | Partner must provide its own subject access mechanism. |
| Art. 16 - Rectification | User corrects their profile (name, email, phone) at https://account.luxid.lu/ (opens in a new tab). | Partner corrects Partner-held data. Note: correcting a claim at LuxID does not automatically update the Partner's copy; the user must also update it in the Partner's system or re-authenticate for LuxID to release the updated value. |
| Art. 17 - Erasure | User deletes their LuxID Account at https://account.luxid.lu/ (opens in a new tab). LuxID sends a deletion event to Partners via the Event Hub. | Partner must erase claims received from LuxID for which it has no continuing lawful basis. If the Partner relies on contract (the service agreement with the user) and the user is terminating that service, erasure follows. |
| Art. 18 - Restriction | Restriction requests for LuxID-held data: contact LuxID or the DPO at privacy@post.lu. | Partner handles restriction for its own data store. |
| Art. 20 - Portability | A self-service export is not yet available (planned). Users request a copy of their data via LuxID or the DPO at privacy@post.lu; the export covers profile data and, where technically feasible, authentication history. | Partner provides its own data export for Partner-held data. |
| Art. 21 - Objection | Objections to legitimate-interests processing by LuxID: contact LuxID. | Partner handles objections to its own legitimate-interests processing. |
| Art. 22 - Automated decisions | LuxID does not make solely automated decisions with legal or similarly significant effects on users. (A planned risk-scoring capability may influence authentication prompts; it will not refuse access without human review.) | Partners making solely automated decisions using LuxID-provided claims must comply with Art. 22 independently. |
Handling user rights requests that span both controllers
Where a user submits a rights request that involves both LuxID-held and Partner-held data, the recommended approach is:
- The party receiving the request (LuxID or Partner) responds for the data it controls within the GDPR one-month response deadline (Article 12).
- The receiving party forwards or directs the user to the other controller for data outside its control. Forwarding is permissible and the response deadline for the second controller runs from the date the request is received by that controller.
- LuxID and the Partner cooperate in good faith to avoid leaving the user without a response.
Cross-border transfers
LuxID's transfer position
User data managed by the LuxID platform is processed and stored within the European Union, on POST infrastructure. There is no transfer of user data to third countries (outside the EEA) as part of the standard authentication service.
Some specific tasks - such as delivering one-time codes and notifications by SMS, voice call and email - are carried out by sub-processors. A sub-processor receives only the data strictly necessary to perform that task (for example the destination phone number or email address and the message content), processes it under a GDPR Article 28 data-processing agreement, and does so within the EU. LuxID does not store or manage user accounts on a sub-processor's platform - the sub-processor only handles the transaction it is asked to perform and logs it as required by the GDPR. POST remains fully liable for its sub-processors' acts and omissions, and the current list is available to Partners on request - contact LuxID.
Partner transfer obligations
If a Partner processes LuxID-received claims in systems hosted outside the EEA, the Partner is responsible for:
- Identifying an appropriate transfer mechanism under GDPR Chapter V (adequacy decision, standard contractual clauses, binding corporate rules, or an Article 49 derogation)
- Documenting the transfer and the mechanism in the Partner's privacy notice
- Conducting a transfer impact assessment where required
LuxID does not validate Partner infrastructure geography. This is entirely the Partner's responsibility.
Breach notification
There are two distinct notification clocks that Partners need to keep separate. One is contractual, one is statutory; they start from different events and have different timeframes.
The contractual 24h clock - urgent security matter (POST → Partner)
The LuxID Agreement defines an Urgent Security Matter as any event that poses or could pose a security threat or vulnerability affecting the LuxID service or POST infrastructure. When such an event is detected, POST will notify Partners at the latest 24 hours after detection with the relevant details and the measures taken or to be taken.
This 24h clock is contractual between POST and the Partner. It starts at detection of the event by POST. It applies whether or not the event also qualifies as a personal data breach under GDPR.
The statutory 72h clock - GDPR article 33 (POST → CNPD)
Under GDPR Article 33 (opens in a new tab), if an Urgent Security Matter qualifies as a personal data breach likely to result in a risk to the rights and freedoms of natural persons, POST as controller must notify the CNPD (Luxembourg's supervisory authority) within 72 hours of becoming aware of the breach.
This 72h clock is statutory and runs in parallel. It starts at awareness of the breach (which is typically simultaneous with detection but conceptually distinct in GDPR doctrine). In most cases the contractual 24h Partner notification will already have occurred before the statutory 72h CNPD notification deadline.
Information provided to Partners
When POST notifies a Partner of an Urgent Security Matter that affects them, the notification typically includes:
- A description of the nature of the event
- The categories and approximate number of data subjects affected (where known)
- The categories and approximate number of personal data records affected (where known)
- The likely consequences
- The measures taken or proposed to address the situation
- The forensic analysis status; POST commits to root-cause investigation for major incidents
POST may redact specific technical details where disclosure would harm the security of the platform or other Partners, or where commercial confidentiality applies.
Partner notification to POST
Partners that become aware of any event they evaluate as an Urgent Security Matter affecting LuxID authentication data or LuxID user accounts must notify POST without undue delay at LuxID with the subject line SECURITY INCIDENT.
Partners should not delay notification pending their own investigation. An initial notification with limited information is preferable to a delayed notification with complete information.
Partner notification to users and supervisory authorities
The Partner is independently responsible for:
- Notifying the competent supervisory authority in its own jurisdiction (not necessarily the CNPD) of breaches involving Partner-controlled data, within 72 hours (GDPR Article 33 (opens in a new tab))
- Notifying affected data subjects directly where the breach is likely to result in high risk to their rights and freedoms (GDPR Article 34 (opens in a new tab))
POST's notifications under Breach Notification do not discharge the Partner's own Article 33 or 34 obligations for data the Partner controls.
DPO contact
POST holds the GDPR Data Protection Officer appointment for the LuxID platform. For data protection enquiries relating to POST's processing activities under LuxID, Partners and supervisory authorities can contact the DPO directly at privacy@post.lu. This mailbox also handles formal DPO correspondence: data subject rights requests forwarded from users, supervisory authority enquiries, and formal breach notifications.