Service provider onboarding
Overview
Becoming a LuxID Partner is a structured process. It is not a self-serve sign-up - LuxID is a shared sovereign identity service used across the Luxembourg ecosystem, and every integrating Organization and Partner goes through a review before receiving production credentials. This page walks through the full journey from initial contact to an active production integration and describes the ongoing relationship thereafter.
The typical timeline from initial contact to production is 4 to 8 weeks, depending on the complexity of the integration, how quickly legal review is completed and how fast the Partner's development team implements and tests the integration. Regulated-sector Partners with additional compliance requirements may take longer.
Journey overview
Phase 1 - initial contact
Who to contact: LuxID or your dedicated POST Luxembourg account manager if your organisation already has a POST commercial relationship.
What to include in your initial enquiry:
- Organisation name and legal entity type
- A brief description of the service or application you intend to integrate with LuxID
- The expected user base (approximate number of users, whether B2C or B2B)
- The minimum
auth_levelyou anticipate requiring (see Authentication levels if you are unsure - broadly: 2 for password-only access, 3/4 for MFA, 9 for LuxTrust-required actions) - The protocol you intend to use (OIDC, OAuth 2.0 or SAML 2.0)
- Your target go-live date if known
LuxID will acknowledge your enquiry and assign a partner onboarding contact.
Phase 1 checklist
| Item | Your action |
|---|---|
| Draft initial enquiry | Describe your service and integration intent |
| Identify internal contacts | Technical lead, legal/DPO contact, commercial contact |
| Identify integration protocol | OIDC, OAuth 2.0 or SAML 2.0 |
Estimate required auth_level | 2 / 3-4 / 8 / 9 (see Authentication Levels) |
| Identify target go-live date | Rough estimate sufficient |
Phase 2 - KYB and due diligence
Before the LuxID Agreement is signed, LuxID conducts a Know Your Business (KYB) review of the prospective Partner. This is a standard commercial and legal verification, not a technical audit.
What LuxID will ask for:
- Proof of legal entity registration (Luxembourg RCS extract or equivalent for foreign entities)
- Names and contact details for the legal signatory, technical lead and data protection contact (DPO or equivalent)
- A description of the service and the intended use of LuxID authentication, including which claims you intend to request
- A URL of the Partner's current privacy notice (or a draft if the service is pre-launch)
- For regulated-sector Partners (financial, healthcare, telecom): evidence of sector authorisation (CSSF licence number, professional authorisation reference, etc.)
What LuxID is assessing:
- That the applicant is a legitimate legal entity operating in good faith
- That the intended use of LuxID authentication is within the acceptable use policy
- That the service has a genuine need for identity authentication (not a speculative or data-harvesting application)
- That there are no obvious conflicts with LuxID's governance obligations or the LuxID E.I.G.'s interests
KYB review begins once all required documents are received.
Phase 2 checklist
| Item | Your action |
|---|---|
| Provide legal entity registration | RCS extract or equivalent |
| Identify legal signatory | Name, title, authority to bind |
| Identify technical lead | Name, email, availability for integration calls |
| Identify DPO or privacy contact | Name and contact email |
| Describe intended claims | List the user attributes you intend to request |
| Provide current privacy notice URL | Or draft if pre-launch |
| Regulated sectors | Provide sector authorisation reference |
Phase 3 - sign the LuxID Agreement
Once KYB is complete, LuxID prepares the LuxID Agreement - a single tripartite contract signed by POST Luxembourg (operator and GDPR controller), the LuxID E.I.G. (brand and invoicing party), and your Organisation.
What the LuxID Agreement covers:
- Permitted use of LuxID authentication and the claims released
- Security and privacy obligations on the Partner side (via the security annexes)
- Data protection: each party acts as an independent controller (see below)
- Intellectual property (LuxID brand usage, logo and "Sign in with LuxID" button)
- Liability, indemnification and insurance
- Term (indefinite from signature) and termination (three months' notice)
- Escalation and dispute resolution
On data protection - there is no separate DPA. LuxID and the Partner are independent data controllers, so no Article 28 processor agreement applies. The data protection commitments (security measures, breach notification, controller-to-controller disclosure) are built into the LuxID Agreement and its security annexes. See Legal agreements and templates and GDPR and data protection for the full rationale.
Negotiation: The LuxID Agreement contains standard terms. Minor amendments are accommodated; structural changes to liability or controller roles require review by the LuxID legal team and may extend the timeline. Regulated Partners (financial, healthcare) with their own standard vendor agreements should raise this at the KYB stage.
Signatures: The agreement is executed electronically by all three parties.
Phase 3 checklist
| Item | Your action |
|---|---|
| Internal legal review | Circulate agreement to your legal/DPO team |
| Raise amendment requests | Flag any required changes early |
| Confirm your controller obligations | Verify the independent-controller model matches your GDPR posture |
| Obtain signature authority | Ensure the legal signatory is available |
| Execute agreement | Sign the LuxID Agreement |
Phase 4 - receive UAT credentials
Once the LuxID Agreement is signed, LuxID provisions a Partner application in the UAT environment and issues credentials:
- Client ID - the application identifier
- Client Secret - for confidential clients (server-side applications); not issued to public clients
- UAT Discovery URL -
https://login-uat.luxid.lu/.well-known/openid-configuration(OIDC) or the SAML metadata endpoint - UAT redirect URI allowlist - pre-populated with the URIs you specified; add more via LuxID
The LuxID Console is provisioned with Partner-level access at this point, giving your team access to the UAT environment, authentication logs and application configuration. See Logs and audit trails.
What UAT credentials are for:
UAT credentials work only against the UAT environment (login-uat.luxid.lu). You cannot use UAT credentials to authenticate real users. The UAT environment runs the same software as production but on dedicated test infrastructure.
What UAT is not:
UAT is not a permanent sandbox for internal testing tools. It is a pre-production environment for integration testing prior to go-live. Long-term test tooling should use the production sandbox features available post-go-live.
Phase 4 checklist
| Item | Your action |
|---|---|
| Receive client ID and secret | Store securely; never commit to source control |
| Review your Application configuration | Confirm redirect URIs, claim template, branding |
| Confirm redirect URIs | Verify pre-configured URIs are correct; add any missing |
| Confirm claim template | Verify requested claims match your agreed use case |
| Review UAT test user accounts | Obtain or create test accounts for integration testing |
Phase 5 - integrate and test
With UAT credentials in hand, your development team implements the integration. The integration guides for each protocol are:
- OIDC / OAuth 2.0: Start with Get started and the OIDC authentication guides
- SAML 2.0: See the SAML integration section
- No-code integrations (WordPress, Odoo, ServiceNow, etc.): See the Quick Integrations section
- Framework-specific quickstarts: Available per the platform guides
Testing expectations:
During UAT, your team should test at minimum:
- Happy path: successful login and claim receipt for each assurance level you will use
- Logout: clearing the local application session, and LuxID session expiry (LuxID does not offer OIDC RP-initiated logout - see OpenID Connect)
- Error cases: rejected redirect URIs, cancelled login, expired tokens
- MFA step-up: if your application uses Substantial or High assurance
- Token refresh: if your application uses refresh tokens
- Consent: the consent screen appearance and what happens when a user declines
LuxID can provide a set of test accounts covering different user states (MFA enrolled, not enrolled, LuxID Verified) upon request.
UX and branding:
Your implementation must comply with the LuxID UX and branding guidelines, particularly the "Sign in with LuxID" button specifications. Non-compliant branding will be raised as a blocker in the go-live review. See the UX and Branding section for guidelines.
Phase 5 checklist
| Item | Your action |
|---|---|
| Implement authentication flow | Per the relevant protocol guide |
| Test happy path | Login, claim receipt, logout |
| Test error and edge cases | Cancelled login, invalid state, expired tokens |
| Test MFA if required | Step-up to Substantial or High assurance |
Validate acr claim | Confirm your application checks the assurance level |
| Implement "Sign in with LuxID" button | Per UX and branding guidelines |
| Update privacy notice | Describe LuxID integration, claims received, legal basis |
| Test consent flow | Verify consent screen renders and consent revocation works |
Phase 6 - go-live review
Before production credentials are issued, LuxID conducts a go-live review. This is a structured check across four dimensions: technical, UX, commercial and legal.
Technical review
LuxID will review:
| Check | Pass criterion |
|---|---|
| Redirect URIs | All production redirect URIs are registered and use HTTPS |
| Client type | Public clients use PKCE; confidential clients store secrets server-side |
| Claim minimisation | Only claims covered by the LuxID Agreement are requested |
acr validation | Application validates the acr claim against the declared minimum assurance level |
| Token handling | Access tokens not stored beyond their expiry; refresh token rotation implemented |
| Logout | Sign-out clears the local application session; the app does not rely on OIDC RP-initiated logout (LuxID does not expose an end_session_endpoint) |
| HTTPS | All callback and API endpoints enforce HTTPS; no HTTP fallback in production |
| Error handling | Application handles authentication errors gracefully without exposing LuxID internals to end users |
Claim minimisation review. The go-live review includes an explicit check of every Claim Template declared on each of the Partner's Applications. LuxID staff verify that each requested claim is proportionate to the Application's stated purpose - if a claim looks excessive, ambiguous, or inconsistent with what was agreed during onboarding, LuxID will raise it as a remediation item and the Application will not be promoted to production until the claim set is revised or justified. This is a documented design principle of the platform: because claim entitlement is set at configuration time rather than at runtime, the go-live review is the primary point at which over-collection is caught. Partners should expect to explain the business purpose for each non-trivial claim (e.g. birthdate, address, luxid_professional_title) and should plan their claim set with data minimisation in mind from the start of the integration project.
UX review
| Check | Pass criterion |
|---|---|
| "Sign in with LuxID" button | Button uses the approved asset and meets minimum size requirements |
| Button placement | Not obscured; appropriate prominence on the login page |
| Consent screen awareness | Application does not attempt to suppress or customise the LuxID-hosted consent screen |
| Error messages | LuxID-returned error codes are translated to user-friendly messages in the Partner UI |
Commercial review
| Check | Pass criterion |
|---|---|
| LuxID Agreement | Signed by all three parties and on file |
| Billing | Billing contact confirmed and invoicing details provided |
Legal review
| Check | Pass criterion |
|---|---|
| Privacy notice | Published and correctly describes the LuxID integration |
| Claims described | Each claimed attribute listed with its lawful basis |
| User rights | Privacy notice describes how users can exercise their rights |
| Data retention | Retention period for LuxID-received claims is stated |
| LuxID attribution | "LuxID, operated by POST Luxembourg" attribution present where required by the LuxID Agreement |
If issues are found: the go-live review outcome is either Approved or Needs Remediation. Remediation items are listed clearly; the Partner addresses them and requests a re-review. There is no limit on the number of re-reviews.
Phase 6 checklist
| Item | Your action |
|---|---|
| Register production redirect URIs | Submit to LuxID as part of the pre-production configuration |
| Confirm assurance level declaration | Production application configured |
| Confirm claim template | Matches LuxID Agreement and privacy notice |
| Publish updated privacy notice | Before requesting go-live review |
| Submit go-live review request | Via LuxID |
| Address remediation items | Fix any issues and request re-review |
Phase 7 - production credentials issued
Once the go-live review is approved:
- LuxID provisions a production application in the production environment
- Production credentials (client ID, and client secret for confidential clients) are issued securely
- The production Discovery URL is
https://login.luxid.lu/.well-known/openid-configuration - The Partner is listed in LuxID's Partner registry (internal; not necessarily public-facing)
From this point, your integration is live. Users can authenticate to your application via LuxID.
First production checks: After go-live, perform a live smoke test with a real user account (not a test account) to confirm the end-to-end flow works in production. Check authentication logs with LuxID to confirm events are appearing. See Logs and audit trails.
Phase 7 checklist
| Item | Your action |
|---|---|
| Store production credentials securely | Rotate immediately if there is any doubt about exposure |
| Update configuration to production endpoints | Point your application at login.luxid.lu |
| Perform live smoke test | Authenticate at least one real user and verify the claim set |
| Verify audit logs appear | Check the Console confirms events are being recorded |
| Notify your internal stakeholders | Confirm go-live to your team and any dependent teams |
Phase 8 - ongoing relationship
Becoming a LuxID Partner is not a one-time transaction. The ongoing relationship includes the following:
SLA and incident management
Partners are covered by the LuxID service level agreement from the moment production credentials are issued. See SLA and support for availability targets, incident severity classification and escalation paths.
Change management
LuxID communicates platform changes (API updates, protocol deprecations, new features) via the developer mailing list and Console banners. Partners are expected to subscribe and respond to deprecation notices within the documented timeline. See Change management and roadmap.
Configuration changes
Changes to a Partner's configuration (new redirect URIs, additional claims, change of assurance level) are made via LuxID for minor changes, or via LuxID for changes that require agreement review (for example, requesting access to additional claim templates not covered by the current agreement).
Escalation contacts
| Contact type | Channel |
|---|---|
| Technical support (P2/P3) | LuxID |
| Security incidents | LuxID with subject line "SECURITY INCIDENT" |
| Commercial and account management | Your POST Luxembourg account manager |
| P1 out-of-hours escalation |
See Contact and support channels for full escalation guidance.
Annual review
LuxID may request an annual review of the Partner integration to verify that the current configuration remains aligned with the LuxID Agreement, that claims usage has not expanded beyond the agreed scope, and that the Partner's privacy notice remains accurate.