Change management and roadmap
Overview
LuxID manages platform changes with backward compatibility by default and contractual notice windows scaled to a change's urgency and compatibility, so Partners can plan integrations against predictable deprecation timelines.
LuxID is a live platform. Protocols evolve, security requirements raise the bar, and new features are added in response to Partner and user needs. This page describes how LuxID manages platform changes so Partners can plan their integrations with confidence.
The core principles are:
- Backward compatibility by default. Additive changes (new endpoints, new optional claims, new event types) are treated as non-breaking and ship without requiring Partner action.
- Notice windows scaled to urgency and impact. Breaking changes are announced ahead of the release date, with the notice period scaled to whether the change is urgent (security-driven) and whether it forces Partners to adapt their applications. The contractual minimum windows are documented in Notice Windows and Adaptation Periods.
- Proactive communication. Partners are notified of changes via multiple channels before they take effect.
- Partner input. Partners can influence the roadmap through structured channels.
Change categories
LuxID classifies every change along two axes drawn from the LuxID Agreement, because the combination determines how much notice Partners receive.
Urgency axis
| Category | Definition |
|---|---|
| Urgent Mandatory | A change POST must implement to protect the security of the platform, mitigate a foreseeable security risk, support evolving technology, meet interoperability requirements, or maintain stable and performant service. |
| Non-Urgent Mandatory | A change necessary to comply with certification requirements applicable to the service. |
| Other | Any other change that is not security-driven or compliance-driven. |
Compatibility axis
| Category | Definition |
|---|---|
| Backward Compatible | A technical change that does not require Partner applications to be modified. |
| Non-Backward Compatible | A technical change that does require Partner applications to be modified or adapted. Routine items like certificate replacement and parameter-value changes are excluded from this category. |
Examples
| Example | Category |
|---|---|
| New optional claim added to an existing scope | Other / Backward Compatible |
| New supported signing algorithm added; existing algorithm still supported | Other / Backward Compatible |
| New Event Hub event type | Other / Backward Compatible |
| Certificate rotation on a metadata endpoint | Routine, excluded |
| Removal of a deprecated grant type | Other / Non-Backward Compatible |
| Removal of a claim from a claim template | Other / Non-Backward Compatible |
Change to the sub claim format | Other / Non-Backward Compatible |
| Removal of a signing algorithm that has become insecure | Urgent Mandatory / Non-Backward Compatible |
| Re-issuing the JWKS to address an exposed key | Urgent Mandatory / Backward Compatible (if kid rotation handled) |
Versioning by interface
Different LuxID interfaces have different versioning characteristics:
OIDC discovery document (/.well-known/openid-configuration)
The discovery document is always additive. New supported scopes, new ACR values and new endpoint URLs are added as new array entries; existing entries are never removed without a deprecation cycle. Partners should cache the discovery document with a sensible TTL (recommended: 24 hours) and re-fetch on cache miss rather than hard-coding values.
Claim Templates
Claim Templates (the named sets of claims Partners can request) are additive. New templates are announced and available for Partners to opt into. Existing templates are never modified in a breaking way; if a structural change to a template is required, a new template version is created and the old one deprecated.
Event Hub schema
Event Hub events are versioned per event type. Each event payload includes a schema_version field. LuxID supports at least the current version and one previous version simultaneously, allowing Partners time to migrate their event consumers. New event types are added without deprecating existing ones.
Partner API (Console API)
Console API endpoints are versioned (/v1/, /v2/ etc.) where structural changes are required. Partners using the Console API should target a specific version and migrate when a new version is released. Version /v1/ is maintained for 12 months after the release of /v2/.
SAML metadata
LuxID's SAML metadata (IdP metadata XML) is updated in place for additive changes (new signing key, new binding URL). Structural changes (removal of a binding, deprecation of a signing algorithm) are versioned and communicated in advance.
Communication channels
Developer mailing list
The developer mailing list is the primary channel for change announcements. All Partners are enrolled at the technical contact email address provided during onboarding.
Partners should ensure the mailing list address is:
- Delivered to a monitored inbox (not filtered to spam)
- Reviewed by a team member with authority to initiate integration changes
To update the subscribed email address, contact LuxID.
Planned in-product notices
Once the LuxID Console ships, a banner will appear for the Partner administrator when they log in for changes affecting the active integration:
- Deprecation notices affecting the Partner's current configuration
- Upcoming maintenance windows
- Security alerts requiring Partner action (for example, a signing algorithm being deprecated)
Until then, the same notices arrive via the developer mailing list.
Incident communication
During an active incident, LuxID communicates status by email to each Partner's registered technical contact. Keep that contact list current (see Contact and support channels).
Partner report
The quarterly Partner report (see SLA and Support - Partner Reporting) includes a change calendar: a summary of changes that have taken effect in the preceding quarter and changes scheduled for the coming quarter.
POST Luxembourg account manager
Partners with a dedicated POST Luxembourg account manager receive change communications directly. Account managers are briefed on major releases and deprecation cycles and can advise on the impact for specific Partner integrations.
Notice windows and adaptation periods
The contract sets minimum notice windows for technical changes, scaled by urgency and compatibility. The clock measures the gap between the change notification and the Release Date.
Notice Matrix (contractual minimums)
| Urgency | Backward Compatible | Non-Backward Compatible |
|---|---|---|
| Urgent Mandatory | 2 Business Days | 40 Business Days (approx. 8 weeks) |
| Non-Urgent Mandatory | 5 Business Days | 90 Business Days (approx. 18 weeks) |
| Other | 10 Business Days | 120 Business Days (approx. 24 weeks) |
Business Days exclude weekends and Luxembourg public holidays.
The notification is accompanied by a detailed analysis of the change and an indication of whether the change is Backward or Non-Backward Compatible. For Non-Backward Compatible changes the notification also includes the expected Release Date.
Adaptation and test period
For Non-Backward Compatible changes, the time between announcement and Release Date is the Adaptation and Test Period. During this period:
- The new behaviour is available in UAT so Partners can validate their updated integration before the Release Date
- Partners may request POST collaboration to test the adaptations against UAT, on dates agreed case-by-case
- At expiry, the Partner is obliged to use the changed CIAM Solution. POST is entitled to discontinue support for versions that do not incorporate the change.
Delay, incapacity or refusal to adapt is at the Partner's risk.
Practical deprecation flow
In addition to the contractual minimums, LuxID's product practice is to announce changes earlier where possible, and to follow up with reminder notices before the Release Date:
| Stage | Typical action |
|---|---|
| Announcement | Notice sent via developer mailing list. Includes what is changing, why, the replacement (if any), the Release Date, and a UAT preview. |
| Adaptation and Test Period | UAT preview available throughout. Partners migrate and test. |
| Reminder | Second notice sent 30 days before Release Date for Non-Backward Compatible "Other" changes. |
| Release Date | The change goes live in production. Partners that have not adapted experience integration failures. |
Worked examples
| Scenario | Category | Minimum notice |
|---|---|---|
| New optional scope added | Other / Backward Compatible | 10 Business Days (in practice, often longer) |
| Removal of a signing algorithm to remediate a published CVE | Urgent Mandatory / Non-Backward Compatible | 40 Business Days (about 8 weeks) |
| Removal of an OIDC grant type for product hygiene | Other / Non-Backward Compatible | 120 Business Days (about 24 weeks) |
Change to the sub claim format | Other / Non-Backward Compatible | 120 Business Days (about 24 weeks) |
| Certification-mandated change to claim encoding | Non-Urgent Mandatory / Non-Backward Compatible | 90 Business Days (about 18 weeks) |
Roadmap visibility
Public roadmap
LuxID publishes a quarterly roadmap update covering the next two quarters.
The roadmap distinguishes between:
- Committed: features scheduled for delivery in the next quarter with a confirmed release target
- Planned: features targeted for the following quarter, subject to change
- Exploratory: items under investigation with no committed timeline
The roadmap does not include security-sensitive features (for example, details of upcoming security hardening that could inform an attacker if disclosed in advance).
Current feature status
A planning-level snapshot of capability availability, consolidated from the feature pages (each linked page is authoritative for its own status):
| Capability | Status today | Details |
|---|---|---|
| Universal Login | Available | Universal Login |
| Multi-factor authentication (OTP, TOTP, passkeys, LuxTrust) | Available | Multi-factor authentication |
| Passwordless and passkeys | Available | Passwordless and passkeys |
| Breached password detection | Available | Breached password detection |
| Single sign-on and LuxID Pro federation | Available | Single sign-on and LuxID Pro |
| LuxID Verified (via LuxTrust) | Available | LuxID Verified |
Event Hub - ClaimValuesChanged | Available | Events and Event Hub |
| Event Hub - further event types | Planned | Events and Event Hub |
Attribute enrichment (incl. age_over_16) | Not currently offered | Attribute enrichment |
| Device flow (RFC 8628) | Not enabled for Partners; on request | OpenID Connect - Device flow |
| Front-channel / back-channel logout | Under review | OpenID Connect - Logout |
| LuxID Console self-service | Planned | LuxID Console |
| EUDI Wallet as a verification path | Future | LuxID Verified |
The table is a navigation aid, not a contract: availability commitments come from the quarterly roadmap and your LuxID Agreement.
Partner advisory input
Partners can influence the LuxID roadmap through two channels:
Partner advisory group: LuxID convenes a Partner advisory group at which Partners can present their use cases, raise feature requests and review upcoming roadmap items. Participation is open to all Partners; notify your POST Luxembourg account manager to join.
Dedicated account manager: Partners with a POST Luxembourg account manager can raise feature requests and roadmap input directly. The account manager aggregates input and presents it to the LuxID product team.
Feature requests are evaluated against the platform's strategic direction, the complexity of implementation, and the breadth of Partner interest. Requests from multiple Partners for the same capability are given higher priority.
Backwards compatibility commitment
LuxID treats backward compatibility as the default. The contractual notice windows in Notice Windows and Adaptation Periods are the minimum notice Partners receive for any change that would require code adaptation; in practice the platform aims to give Partners longer planning horizons for major protocol changes than the contract floor.
The current authentication flow (OIDC Authorization Code with PKCE) is the primary integration path and is not under deprecation consideration.
Versioning reference table
The following table summarises the versioning approach for each LuxID interface. "Full Adaptation Period" means the notice windows from Notice Windows and Adaptation Periods apply.
| Interface | Breaking change treatment | Additive change treatment | Notification |
|---|---|---|---|
| OIDC discovery document | Full Adaptation Period | Additive, no action required | Mailing list |
| Claim Templates | New template version; old deprecated | New template added; opt-in | Mailing list |
| OIDC token endpoint parameters | Full Adaptation Period | New optional params added freely | Mailing list |
| Event Hub event schema | Schema version field; dual-version support | New event types added freely | Mailing list + Partner report |
| SAML IdP metadata | Full Adaptation Period for structural changes | New keys/bindings added in-place | Mailing list |
Migration support
When LuxID releases a breaking change, Partners are not expected to navigate the migration alone.
LuxID provides:
- Migration guide: a document describing exactly what changed, what the Partner needs to update, and how to test the migration in UAT before applying it to production
- UAT preview: the new behaviour is available in UAT from the announcement date, giving Partners the full Adaptation and Test Period to test the migration in a safe environment
- Support: Partners may raise migration questions via LuxID; complex migrations (for example, a Partner with a deeply customised SAML integration) may be supported via a dedicated migration call with the LuxID technical team
For changes initiated by the Partner (rather than by LuxID), the Change Request procedure applies: the Partner submits a written description, POST analyses it for ethical, technical and feasibility compatibility, and if accepted POST and the LuxID E.I.G. jointly determine pricing and business conditions. Change Requests outside the standard scope may be implemented as Add-Ons developed by POST or another LuxID Member on top of the platform.
Partners should not apply migration changes directly to production without testing in UAT first. The UAT environment (login-uat.luxid.lu) is available for this purpose throughout the deprecation period.