Contact and support channels
LuxID uses separate mailboxes for separate audiences. Sending a question to the wrong mailbox is the single most common cause of slow responses. This page is the canonical routing reference - other developer pages link here rather than embedding contact details inline.
Mailbox routing
| Audience | Purpose | Mailbox | Phone |
|---|---|---|---|
| Partner - operational | Production and UAT incidents, configuration change requests (redirect URIs, claim templates, credential rotation), technical questions from a Partner already under contract | servicedesk@post.lu | +352 2424 3030 |
| Partner - commercial | Pre-contract enquiries, contract amendments, pricing, billing queries, feasibility discussions for new integration use cases, brand licence questions | hello@luxid.lu | n/a |
| End user | LuxID Account holders (sign-in trouble, account recovery, data exports, complaints). Partners should redirect end users here rather than opening tickets on their behalf | support@luxid.lu | n/a |
| Security disclosures | Responsible disclosure of vulnerabilities affecting LuxID. Coordinated disclosure - see Reporting a security vulnerability | csirt@post.lu (CSIRT POST CyberForce) | +352 2424 4000 |
| Data protection / DPO | GDPR data subject rights forwarded from users, supervisory authority enquiries, formal breach notifications | privacy@post.lu | n/a |
When in doubt
- You have signed the LuxID Agreement and something operational is wrong → servicedesk@post.lu (phone for P1).
- You are still exploring whether LuxID fits your use case, or you need a contract change → hello@luxid.lu.
- An end user contacted you with a LuxID problem → redirect them to support@luxid.lu; do not open the ticket yourself.
Reporting a security vulnerability
Security vulnerabilities affecting LuxID are handled by CSIRT POST CyberForce, the Computer Security Incident Response Team operated by POST Luxembourg. Please report under coordinated (responsible) disclosure and do not disclose the issue publicly until POST CyberForce has confirmed remediation or agreed a disclosure date.
| Detail | Value |
|---|---|
| csirt@post.lu | |
| Phone | +352 2424 4000 |
| Preferred languages | English, French, German |
| PGP fingerprint | 6586 B96E D307 700C 3034 75C6 B6B3 D39C 1C94 BB50 |
| Disclosure policy | CSIRT POST CyberForce (opens in a new tab) |
Encrypt sensitive reports to the PGP fingerprint above. These details are also published in machine-readable form, per RFC 9116 (opens in a new tab), at /.well-known/security.txt.
Channels
Email - POST customer service centre (Partner operational)
Address: servicedesk@post.lu
This is the first point of contact for Partner operational matters. Use for: incident reports, configuration change requests (which today are still handled manually by LuxID - see LuxID Console for the planned self-service surface), claim release questions, technical questions during integration.
Always include the Support ID, the affected Application name, and the environment. See What to include in a ticket.
Phone - critical incidents
Number: +352 2424 3030
For P1 (complete loss of service) it is highly recommended to call in addition to opening a ticket by email. The phone line is staffed during Business Hours (08:00-16:00 CET on Luxembourg Business Days); out-of-hours coverage applies to P1 incidents through the on-call escalation path.
Email - LuxID commercial (hello@luxid.lu)
Address: hello@luxid.lu
Use for everything before or alongside the operational relationship: feasibility discussions, contract amendments, pricing, brand licence, partnership development. The LuxID E.I.G. invoices the service; questions about the invoice itself also go here.
Future console "submit ticket"
Once the LuxID Console ships (planned), a Console-resident "Submit Ticket" form will pre-fill Partner identity, Application context, and contact details. Until then, every request goes through the mailboxes above.
What to include in a ticket
Every ticket should include the following, in this order:
- Environment. UAT or Production. Mixing the two causes most "phantom" support requests.
- Application name and Client ID. Without this LuxID cannot look up your audit logs.
- The on-screen identifier the user saw. For a failed sign-in ("Connection error with LuxID" dialog), that is the Error ID plus the long-hex Transaction ID. For a request blocked or masked at LuxID's edge (WAF block / "technical error" page), it is the Support ID. Quote whichever the user saw, exactly, so LuxID can trace the corresponding logs - this is the single most important piece of information you can provide. If your own code captured the Global Transaction ID from the HTTP response headers, include that too. See the identifiers reference for how the four differ.
- Timestamp window. Either your local time with timezone (
2026-05-22 14:23 Europe/Luxembourg) or UTC. A narrow window (5 to 15 minutes) is much more useful than a full day. - Reproduction steps. As short as possible. "User opens app, clicks Sign in with LuxID, enters credentials, sees X" is enough.
- Expected vs actual. One sentence each.
- Browser and OS for end-user-facing issues. Browser version matters more often than developers expect.
- Network traces for protocol-level issues. HAR file, Burp/Charles export, or raw curl request/response. Redact any access tokens, refresh tokens, or client secrets before sending - LuxID does not need the secret values.
A short, complete ticket gets a faster answer than a long, vague one.
What Partner support cannot help with
Partner support at servicedesk@post.lu is for Partner administrators and developers. It does not help individual end users.
If an end user reaches you with a LuxID problem (cannot sign in, lost 2FA device, locked out, did not receive an activation email), redirect them to:
- The LuxID Account dashboard at https://account.luxid.lu/ (opens in a new tab) for self-service actions.
- The public help site at https://www.luxid.lu/en/ (opens in a new tab) (and the language-equivalent paths
/fr/,/de/,/lb/) for documented user flows. - LuxID end-user support at support@luxid.lu. The user must contact this mailbox themselves; you cannot open a ticket on a user's behalf and expect LuxID to act on it (GDPR consent boundary).
Examples of issues that go to the user, not to you:
- "I lost my phone with the authenticator app."
- "I want to delete my LuxID Account."
- "I want to revoke an Application's access to my data."
- "The activation email did not arrive."
- "I want to download a copy of my LuxID data."
Response targets
The contractual incident targets (P1-P4) live in SLA and support. In short:
| Priority | First response | Intervention starts |
|---|---|---|
| P1 - Critical | < 15 min | 1 hour |
| P2 - High | < 15 min | 2 hours |
| P3 - Medium | < 15 min | 4 hours |
| P4 - Low | best effort | best effort |
The clocks run during Business Hours (08:00-16:00 CET on Luxembourg Business Days). Out-of-hours coverage applies to P1 incidents via the on-call escalation path.
Status communication during incidents
During a declared incident, LuxID communicates by email to the Partner technical contact list registered with LuxID. Keep that contact list current so you receive incident notifications.
For P1 incidents, expect a first acknowledgement within 15 minutes and update cycles every 2 hours until resolution. Post-incident review is published within 5 Business Days for P1 and P2 incidents.
Account contact list
Keep your Partner contact list current with LuxID. Members of the contact list receive operational emails (incident notifications, change windows, deprecation announcements, contract renewals).
Recommended contacts:
- Technical contact (primary engineer responsible for the LuxID integration).
- Business contact (account owner, billing, contracts).
- Security contact (responsible for credential rotation, incident response on your side).
A stale contact list means you miss announcements. Audit it quarterly.
Common ticket templates
"Our users cannot sign in"
Environment: Production
Application: <name>
Client ID: <cid>
Support ID(s): <one or several from affected user error screens>
Timestamp window: <start> to <end> UTC
Affected users: <approximate count>
Reproduction:
1. User opens our app
2. Clicks "Sign in with LuxID"
3. Lands on LuxID login screen
4. Enters credentials
5. Sees: <error message text + screenshot>
Expected: Successful sign-in and redirect to our callback.
Actual: <one-line summary>
We have already verified:
- Our service is up
- Our redirect URI is unchanged
- Our Client Secret is unchanged
"We need a configuration change"
Environment: <UAT or Production>
Application: <name>
Client ID: <cid>
Requested change:
- <Add redirect URI: ...>
- <Add Claim Template: ...>
- <Rotate Client Secret>
- ...
Justification: <one paragraph>
Roll-out window: <when we'd like the change applied>
"How do I do x?"
Environment: <UAT or Production>
Application: <name>
We are trying to: <one-paragraph goal>
We have read: <links to documentation pages reviewed>
Specific question: <one or two sentences>
Cross-references
- Diagnose a failing request - decision tree and how to find the Support ID.
- SLA and support - the contractual SLA detail.
- Common errors - the catalogue of frequent integration mistakes (consult before opening a ticket).
- Logs and audit trails - where the Support ID correlates with the audit log (once the Console Logs view is available).