Curity Identity Server 11.4: FIPS 140-3, DPoP binding and Database Scopes in the Admin UI

Curity Identity Server 11.4 is out. Three things stand out: a FIPS-compliant mode, DPoP binding extended across the OAuth endpoints and Database Scopes moving into the Admin UI.

FIPS 140-3 compliance

On September 21, NIST moves every remaining FIPS 140-2 certificate to the historical list. Existing deployments keep running, but from that date a 140-2 validation no longer satisfies new federal procurement. Anything acquired after it needs an active 140-3 validation.

The Curity Identity Server can now be configured to run in FIPS-compliant mode, so cryptographic operations are performed using validated algorithms and modules. It ships as a FIPS-compliant Docker image, available with the FIPS support add-on.

This matters beyond US federal. If you supply organizations that sell into government or you work in defense, financial services or critical infrastructure, FIPS validation has become procurement shorthand for cryptographic assurance.

DPoP binding across the OAuth endpoints

The server now issues DPoP-bound access tokens for all client types and can bind the authorization code itself to the client's proof-of-possession key. Server metadata and the introspection endpoint reflect the binding. Both the Admin UI and the DevOps Dashboard expose DPoP configuration at the OAuth profile and client level, so you can roll it out per client rather than flipping a switch across the estate.

This is Token Intelligence in practice. A token only works for the client that earned it, which means a stolen one is worth nothing on its own. Bearer tokens assume the holder is the owner. Proof of possession removes the assumption.

Database Scopes in the Admin UI

Database Scopes introduced as an experimental feature in 11.3, can now be fully managed from the Admin UI. A setup wizard walks through enabling and configuring the feature, a simplified schema editor handles creating and editing scopes, with support for Ephemeral Clients. The GraphQL API also gains the ability to filter scopes by claim name.

The practical effect is that scope changes stop queueing behind the one person who knows the config. Teams managing large or fast-moving scope catalogs can make changes where they already work.

Also in 11.4

A new SDK service lets plugins publish their own metrics. The Passkeys and WebAuthn authenticators support configurable rpId. Persistent background jobs get continued hardening. Temporary Lockout now emits an event when it reaches its maximum, and there is tighter handling of activation-email resends and password-reset link invalidation.

Get the details

Full release notes are on the Developer Portal.

We are running a walkthrough webinar on August 17. Register to catch the session live.

Or go straight to it: start a free trial and see how 11.4 fits your architecture.