On this page
A stronger password rule cannot repair an ambiguous login name, a replayable invitation or a recovery change that leaves old grants usable. Account security depends on the lifecycle around the credential.
ProAuth 3.2.0 adds UserStore hardening across invitations, contacts, abuse controls, identity changes and scoped revocation. Existing UserStore IDP instances move to the new semantics through explicit preview, backfill and activation.
Deploying code and activating behavior are separate steps
Apply the ProAuth and UserStore database migrations and deploy the coordinated release to every serving component. Confirm that old pods, workers and rollback ReplicaSets cannot receive traffic before performing the guarded migration writes.
Multi-instance deployments require distributed state with the required compare-and-swap and time-to-live semantics. In-memory state is supported only for a single serving instance. Shared Data Protection keys and durable notification delivery also belong in the readiness review.
flowchart TD
Deploy[Apply migrations and coordinated release] --> Preview[Preview current UserStore inventory]
Preview --> Backfill[Run bounded backfill batches]
Backfill --> Resolve[Resolve identifier conflicts and legacy invitations]
Resolve --> Test[Verify representative user journeys]
Test --> Review[Refresh fingerprint and attest all nodes current]
Review --> Activate[Activate hardened semantics]
Activate --> Monitor[Monitor authentication and lifecycle outcomes]The migration and activation guide is the authoritative runbook. The diagram shows the order of decisions, not a substitute for its prerequisites.
Preview the data that changes the decision
The inventory reports missing canonical identifiers, quarantined conflicts, confirmed emails missing unified contacts and legacy reset artifacts. Its fingerprint represents the reviewed state. Refreshing a grid filter does not make an earlier inventory approval cover changed data.
Backfill runs in bounded, idempotent batches. It is already a security-state change: confirmed legacy emails acquire migration provenance as verified contacts, and old reset artifacts are invalidated. The all-nodes-current requirement applies before these writes, not only at final activation.
Canonical login-name conflicts need deliberate remediation. ProAuth does not select a winner based on database collation. Identify the people, assign distinct values through supported APIs, rerun backfill and verify that conflicts have cleared.
Activate password policy separately
Existing instances retain their legacy password regex until typed policy is previewed and applied or configured explicitly. UserStore hardening does not silently choose a typed recommendation.
Typed policy gives rules named settings and server-side evaluation rather than one opaque regex. The password policy guide explains recommendations, hashing and recovery. Review it as a separate change with its own compatibility boundary.
Hardening activation also enables layered abuse evaluation. It evaluates password login, passkey login and recovery across dimensions such as account, identifier and network, complementing existing lockout and CAPTCHA controls. See layered abuse protection for capacities and behavior.
Record the irreversible boundary
Activation requires current readiness, a matching fingerprint, a fleet attestation and impact acknowledgement. After activation, rollback to a pre-hardening binary is unsupported. Advanced security epochs, changed hashes, cancelled invitations and completed identity replacements are not undone by reverting an image.
Rehearse normal login, invitation delivery, recovery, identifier conflicts and revocation in a representative staging topology. Keep the database and state-store deployment evidence with the change record. Monitor outbox age, abuse decisions, failed proofs and cleanup after activation; a completed deployment job does not prove that users can complete every journey.