ZITADEL Technical Advisories
Technical advisories are notices that report major issues with ZITADEL Self-Hosted or the ZITADEL Cloud platform that could potentially impact security or stability in production environments. These advisories may include details about the nature of the issue, its potential impact, and recommended mitigation actions.
Users are strongly encouraged to evaluate these advisories and consider the recommended mitigation actions independently from their version upgrade schedule. We understand that these advisories may include breaking changes, and we aim to provide clear guidance on how to address these changes.
| Advisory | Name | Type | Summary | Affected versions | Date |
|---|---|---|---|---|---|
| A-10000 | Reusing user session | Breaking Behavior Change | The default behavior for users logging in is to be directed to the Select Account Page on the Login. With the upcoming changes, users will be automatically authenticated when logging into a second application, as long as they only have one active session. No action is required on your part if this is the intended behavior. | 2.32.0 | Calendar week 32 |
| A-10001 | Login Policy - Allow Register | Breaking Behavior Change | When disabling the option, users are currently not able to register locally and also not through an external IDP. With the upcoming change, the setting will only prevent local registration. Restriction to Identity Providers can be managed through the corresponding IDP Template. No action is required on your side if this is the intended behavior or if you already disabled registration on your IDP. | 2.35.0 | Calendar week 34 |
| A-10002 | Console - Branding | Breaking Design Change | Since Angular Material v15 many of the UI components have been refactored to be based on the official Material Design Components for Web (MDC). These refactored components do not support dynamic styling, so in order to keep the library up-to-date, the console UI will loose its dynamic theming capability. If you need users to have your branding settings (background-, button-, link and text coloring) you should implement your own user facing UI yourself and not use ZITADELs console UI. ZITADEL hosted Login-UI is not affected by this change. | 2.40.0 | Calendar week 44 |
| A-10003 | Login-UI - Default Context | Breaking Behavior Change | When users are redirected to the ZITADEL Login-UI without any organizational context, they're currently presented a login screen, based on the default settings, e.g. available IDPs and possible login mechanisms. If the user will then register themselves, by the registration form or through an IDP, the user will always be created on the default organization. With the introduced change, the settings will no longer be loaded from the instance, but rather the default organization directly. | 2.38.0 | Calendar week 41 |
| A-10004 | Sequence uniquenes | Breaking Behavior Change | Due to storage optimisations ZITADEL changes the behavior of sequences. This change improves command (create, update, delete) performance of ZITADEL. Sequences are no longer unique inside an instance. From now on sequences are upcounting per aggregate id. For example sequences of newly created users begin at 1. Existing sequences remain untouched. | 2.39.0 | 2023-10-14 |
| A-10005 | Expected downtime during upgrade | Expected downtime during upgrade | Migrating to versions >= 2.39 from < 2.39 will cause down time during setup starts and the new version is started.
This is caused by storage optimisations which replace the | 2.39.0 | Calendar week 41/42 2023 |
| A-10006 | Additional grant to cockroach database user | Breaking Behavior Change | Versions >= 2.39.0 require the cockroach database user of ZITADEL to be granted to the | 2.39.0 | Calendar week 41/42 2023 |
| A-10007 | Additional grant to cockroach database user | Breaking Behavior Change | Upcoming Versions require the SYSTEM_OWNER role to be available in the permission role mappings. Self-hosting ZITADEL users who define custom permission role mappings need to make sure their system users don't lose access to the system API. | Upcoming | Upcoming |
| A-10008 | New flag to prefill projections during setup instead of after start | Feature description | New flag | 2.44.0, 2.43.6, 2.42.12 | 2024-01-25 |
| A-10009 | Ensure lock distribution for FOR UPDATE-statements on Cockroachdb | Feature description | Fixes rare cases where updating projections was blocked by a | 2.53.0 | 2024-05-28 |
| A-10010 | Event type of token added event changed | Breaking Behavior Change | Version 2.53.0 improves the token issuance. Due to this there are changes to the event types created on token creation. | 2.53.0 | 2024-05-28 |
| A-10011 | Identity Provider options: allow "auto" only | Breaking Behavior Change | Version 2.59.0 allows more combinations in the identity provider options. Due to this there might be unexpected behavior changes. | 2.59.0 | 2024-08-19 |
Subscribe to our Mailing List
If you want to stay up to date on our technical advisories, we recommend subscribing to the mailing list. Go to the subscription form and add your email address.
As ZITADEL Cloud customer, you can also login to the ZITADEL Customer Portal and enable the Technical Advisory Notifications in your settings.
Categories
Breaking Behavior Change
A breaking behavior change refers to a modification or update that changes the behavior of ZITADEL. This change does not necessarily affect the APIs or any functions you are calling, so it may not require an update to your code. However, if you rely on specific results or behaviors, they may no longer be guaranteed after the change is implemented. Therefore, it is important to be aware of breaking behavior changes and their potential impact on your use of ZITADEL, and to take appropriate action if needed to ensure continued functionality.
Expected downtime during upgrade
Expected downtime during upgrade means that ZITADEL might become unavailable during an upgrade. ZITADEL is built for zero downtime upgrades at upgrades can be executed without downtime by just updating to a more recent version. When deploying certain changes a zero downtime upgrade might not be possible, for example to guarantee data integrity. In such cases we will issue a technical advisory to make you aware of this unexpected behavior.