Ory Network, Ory Kratos, Ory Polis v26.4.15 released

DATE: November 10, 2026

AUTHOR: Ory Team

Ory Network

Configure session risk rules on Ory Network

Projects on an Enterprise plan can now configure session risk rules. Ory Kratos Identities evaluates the rules when it checks a session at /sessions/whoami or /sessions/whoami-jwt/{template}. Each rule is a CEL condition over the session and the request, including the client IP address, its reputation labels, and its location, and an action: require_aal2 requires a second factor for the rest of the session, and revoke revokes the session.

Edit the rules in the Ory Console under Authentication > Sessions. The condition editor completes session and request fields and marks problems as you type. You can also configure the rules with ory patch identity-config under session.whoami.rules, or through the normalized project API in the kratos_session_whoami_rules field.

Saving fails with a 400 Bad Request error if a new or changed rule is invalid, for example if its condition doesn't compile or its ID is used twice. The error names each rule that fails. Rule errors appear in your event streams as SessionRiskRuleFailed events.

Throttled sign-ins return to the login form

When brute-force protection refuses a sign-in, a browser that submitted the login form now returns to the form instead of the error page. The form shows message 4010012, which tells the user how long to wait, for example "Too many failed login attempts. Please try again in 60 seconds." The message context holds retry_after, the number of seconds until the user can try again, and the time the block ends as retry_at and retry_at_unix. Custom login UIs that translate messages by ID can add a translation for 4010012.

API and native clients, and browsers that submit JSON, still receive error login_throttled with status 429. The response now also carries a Retry-After header with the same number of seconds.

This is now available on Ory Network.

Ory Kratos

Configure session risk rules on Ory Network

Emit every SessionChecked event

SessionChecked is deduplicated per identity per UTC day on a best-effort basis. Enable the kratos.session_checked_emit_all feature flag to emit it for every session check instead, for example to detect session hijacking from your event stream. This can increase your event volume considerably.

Live events report session expiry, revocation reasons, and check outcomes

SessionIssued, SessionChanged, and SessionLifespanExtended now carry SessionExpiry, the session's expiry in RFC 3339 UTC. SessionExpiresAt keeps its existing format.

SessionRevoked is now emitted on every path that ends an active session early, including identity deletion and deactivation through the admin API and SCIM. It carries SessionRevokedScope (session or identity) and SessionRevokedReason.

SessionChecked carries SessionCheckOutcome and, when the check fails, SessionCheckFailureReason (revoked, expired, or identity_inactive). SessionTokenizedAsJWT carries the token's jti and exp after claims mapping.

You can filter live events by all new attributes.

Throttled sign-ins return to the login form

API and native clients, and browsers that submit JSON, still receive error login_throttled with status 429. The response now also carries a Retry-After header with the same number of seconds.

This is now available on Ory Network.

Ory Polis

A failed SCIM group PATCH now takes back the changes it had already written

A PATCH on /Groups/{id} that fails partway now takes back the name and membership changes it had already written, instead of leaving them applied. Until now each operation was written as it was applied, so a failure after an earlier write kept that write: a request renaming a group and changing its membership could answer an error with the new name stored and the membership untouched. The identity provider recorded the sync as failed while Ory kept half of it, and the two drifted apart. This affected every group PATCH shape — a pathless add or replace carrying both displayName and members, a members path operation, and any request whose later operation failed after an earlier one succeeded.

The recovery is limited, and the limits matter before you rely on it:

Changes another request makes to the same group at the same time are kept, with three exceptions. The name is put back only while the group is exactly as the failed request wrote it, so after a concurrent change the failed request's rename stays in place. A member the failed request added is removed unless another PATCH has added it since; a PUT that found the member already present does not count. A member the failed request removed is added back even if another request removed it meanwhile. And when two concurrent PATCH requests add the same member and both fail, the member stays in the group.
It covers up to 10,000 changed memberships in one request. A larger change is taken back only in part.
Events already delivered for the operations that did succeed are not withdrawn, so a webhook consumer can still receive a group.updated or group.user_added for a request that then failed.

Reconcile against the group itself rather than treating each event as final.

Admin Portal admins sign in again once after upgrading

The Admin Portal no longer uses NextAuth.js. Its session cookie keeps the same name and 30-day lifetime but has a new format, so every admin is signed out once when you upgrade and signs in again as before.

Credentials, magic links and SSO sign-in work as before with the same NEXTAUTH_URL, NEXTAUTH_SECRET, NEXTAUTH_ACL and NEXTAUTH_ADMIN_CREDENTIALS variables. Magic links sent before the upgrade still work, and the Admin Portal SSO connection keeps its callback URL.

Identity Federation apps accept more than one ACS URL

An Identity Federation app now takes extra Assertion Consumer Service endpoints in additionalAcsUrls, alongside the acsUrl it already had. Use it when a service provider owns several ACS endpoints under one entity ID, such as an SAP Cloud Identity Services tenant reachable on both the accounts.ondemand.com and accounts.cloud.sap superdomains.

acsUrl and additionalAcsUrls together form an allow-list, matched exactly. A sign-in request that names an ACS URL is answered at that URL only if the URL is on the allow-list. A request that names none, and an IdP-initiated sign-in, is answered at acsUrl.

acsUrl keeps its meaning and is not deprecated. An app whose service provider receives assertions at a single endpoint needs no change, and leaving additionalAcsUrls empty is the same as not setting it.

Polis no longer logs expected duplicate-key failures as query errors

With a SQL database, Polis logged a query failed error for every insert that found its record already there, such as an INSERT ... Duplicate entry on MySQL. Those failures are how Polis detects an existing record, not faults, but they filled logs and hid real errors. Polis now leaves unique-key violations out of its query error log and logs every other failed query as before.

This is now available for the Ory Enterprise License and will be part of the next Ory Open Source release.

Ory Hydra, Ory Keto, Ory Oathkeeper, Ory Elements, and Ory Terraform

No significant changes in this release.