Skip to main content
Zylon can require a recent authentication challenge before a principal performs a sensitive workspace or backoffice action. This control adds a time-bound reauthentication requirement on top of the user’s existing permissions and authorization checks.
Authentication freshness is not applied to API requests authenticated with tokens. Token-based integrations do not need additional reauthentication steps or changes to their existing flows.
The feature can be enabled and configured by risk level. When enabled, the action-specific challenge is valid only for the configured freshness window. The low, medium, and high windows are independent.

​
Protected actions

The following table reflects the current backend call sites of assertPrincipalAuthChallengeIsValid. The list is a code-level reference and should be reviewed after changes to sensitive authorization paths. API-token principals are exempt from this freshness check by design. This does not bypass the endpoint’s normal permission, scope, or ownership checks.

​
Authentication methods and failure handling

For interactive users, the frontend can answer an authentication challenge with the configured password or SSO flow. A missing or expired challenge prevents the protected action from proceeding until the user authenticates again. Google and Microsoft SSO may redirect the browser away from the original request; operators should account for the possibility that the user needs to repeat the action after returning. For configuration details and the exact freshness windows, see Authentication Freshness.