Changelog

This feature allows to add locally generated RSA keys to service users. Until now, both public and private key material was generated by ZITADEL and the private key was downloaded by the user. Eliminating private key transmission over the network strengthens security. Users can now generate private machine keys locally for service users and avoid sending the sensitive key material over the network.

This update simplifies the configuration of email delivery within ZITADEL by introducing SMTP provider templates. These templates offer pre-defined settings for popular email service providers (ESPs) like Amazon SES, Mailgun, Mailjet, Postmark, Sendgrid, and a Generic SMTP option.

Benefits:

• Faster configuration: Leverage pre-configured settings to streamline the setup process for supported ESPs. You only need to provide your specific account details, significantly reducing configuration time.
• Reduced errors: Pre-defined templates minimize the risk of configuration errors associated with manual setup.
• Improved maintainability: Centralized templates ensure consistency and simplify future updates for supported ESPs.

We strongly recommend replacing the pre-configured SMTP service in ZITADEL Cloud for production environments. These default settings are for demonstration purposes only and may not provide the necessary level of security or reliability for critical deployments. Configuration with SMTP provider templates facilitates the transition to a secure, production-ready SMTP configuration.

This update introduces enhancements to the lockout policy, providing finer-grained control over user access attempts. Similar to the existing functionality for passwords, administrators can now configure automatic lockouts after a specified number of consecutive failed Time-based One-Time Password (TOTP) checks. The new feature strengthens security posture by mitigating brute-force attacks targeting TOTP verification.

Lockouts are applied independently for each TOTP method. This ensures users retain the ability to attempt alternative verification methods (e.g., email OTP) even after exceeding the threshold for a specific TOTP method (e.g., mobile app).

Example Scenario:

If the lockout policy is set to trigger after 3 failed attempts, a user who enters an incorrect mobile app TOTP code twice would still have the opportunity to try email verification or another configured TOTP method. Only after exceeding the attempt limit for all available methods would the account be locked.

Feature flags allow users to opt-in or opt-out of experimental features that are not intended to be generally available. Our intention is to provide means to access and test early features for users to test and provide feedback.

Feature settings are available in the default settings through the Console and via our Feature Service API.