On this page
An identity platform has to handle the day a user loses every authenticator, an invitation needs another approval, or an application depends on a claim that should no longer be disclosed. Those journeys deserve the same attention as normal sign-in.
ProAuth 3.2.0 shipped on 8 October 2026, following the rebuilt AdminApp in 3.1.0 on 29 September. This is a guide to the released capabilities and their operational boundaries, with separate articles for teams planning implementation.
Passwordless becomes a governed lifecycle
The passkey support introduced in 3.0 now has controls for enrollment, credential compliance and maturity, password removal, recovery, attestation and independent approval. Four recommendations provide starting configurations, from coexistence with passwords to regulated hardware-bound authentication.
Policy belongs to the UserStore IDP instance. Applying a recommendation writes reviewable options; upgrading does not automatically choose a policy or remove passwords. The passkey policy guide explains readiness and the difference between primary passkeys and MFA.
Recovery includes verified security contacts, saved codes, temporary access passes and identity-proofing integration points. Restricted recovery sessions let users complete their bound recovery task without authorizing ordinary application access. See recovery and access passes.
Account changes acquire explicit evidence
Unified invitations support UserStore and federated routes, expiry, cancellation, approvals and assignments. Only one route can complete an invitation. Governed identity replacement proves the current and replacement identities while preserving the stable ProAuth subject.
Scoped session and renewable-grant revocation support account security responses. These workflows are described in invitations and identity continuity.
Applications receive an explicit claim contract
ProAuth separates trusted authentication context from claims disclosed to applications. Optional issuer identifiers, profile data and federation claims follow explicit permissions and destinations. A claim removed by filtering is not silently restored afterward.
Enterprise rules are preserved. Starter and Business defaults permit requested standard profile data and specific optional claims under documented conditions. An ID-token request does not add those optional claims to an API access token. The claim-disclosure article explains the resulting application review.
The release also strengthens registered client authentication, S256 PKCE enforcement, DPoP requirements and shared-storage grant consumption. Protocol controls are separate obligations: a confidential client still authenticates when using PKCE or DPoP.
The client-authentication guide explains the registration contract. The token-lifecycle guide covers grant consumption and revocation across instances.
Review compatibility before activating policies
Several changes require a planned deployment:
- EdDSA/Ed25519 passkeys must be replaced; arrange an alternative access route before upgrading affected users.
- Client-security migrations revoke existing codes and refresh tokens. Update affected BFF packages and plan application reauthorization.
- Nodes sharing the FIDO trust cache must upgrade together because older binaries cannot read the compact snapshot.
- Existing UserStore instances adopt hardened semantics through an explicit migration and activation workflow. Typed password-policy activation is separate.
- Committed password removal is irreversible. After UserStore hardening activation, rollback to a pre-hardening binary is unsupported.
Use the release notes, client migration guide and UserStore rollout article as the deployment starting point. Conformance testing supports product quality and certification preparation; it does not establish certification or verified authentication-assurance values beyond the published release contract.