UserStore enterprise hardening

UserStore enterprise hardening closes security gaps that cannot be solved by a strong password or passkey policy alone. It protects the complete path around authentication: invitations, verified contacts, abuse controls, identity changes, session revocation, and upgrades from legacy data.

This page is the starting point for administrators. The linked reference pages contain the complete API and option details.

Why this feature exists

Authentication is only as strong as its weakest route. For example, a phishing-resistant passkey does not protect an account if an old invitation can be replayed, a recovery address can be replaced without proving ownership, or an existing refresh token remains usable after a security event.

The hardened model establishes these guarantees:

• an invitation has an explicit lifecycle and exactly one winning identity-provider route;
• changing a recovery address requires proof of the old and new addresses;
• distributed counters detect attacks across accounts, identifiers, networks, tenants, and nodes;
• replacing an identity proves both identities and preserves the stable ProAuth subject;
• security events invalidate the intended UserStore user, tenant, or client scope;
• legacy data is previewed and backfilled before new semantics are activated.

These guarantees are enforced by the server. A UI or API client can guide the user, but it cannot weaken them or supply its own authentication evidence.

Choose the right starting point

Your situation	Recommended action
New UserStore deployment	Start with ConsumerBalanced-v1, configure passkeys if required, then run the hardening status check before production use.
Existing deployment with custom password regex and lockout settings	Keep compatibility modes active, deploy the coordinated release to every node, preview the password policy and hardening inventory, then migrate deliberately.
Public consumer application	Use the consumer password recommendation, layered abuse controls, enumeration-safe recovery, mutable invitation identifiers only when the business journey needs them, and hide detailed lock feedback.
Workforce or B2B deployment	Prefer independent login names, passkeys or MFA, governed invitations with assignments, verified recovery contacts, and approvals for sensitive administrator operations.
Passwordless deployment	Prohibit password recreation through passkey policy, require an operational non-password recovery route, and verify that invitations enroll a passkey before activation.
Regulated deployment	Use phishing-resistant authentication, approval requirements, longer audit retention, strict change records, and deployment checks against your required controls before activation.

A practical default

Most customers should apply the balanced password recommendation, retain temporary lockout, activate layered abuse controls with their defaults, require at least one verified recovery contact or recovery-code route, and use immutable invitation identifiers unless users genuinely need to change them.

What is configurable

The existing option system remains the only policy authority. Options are scoped to the UserStore IDP instance unless a page states otherwise.

Area	Configuration model	Reference
Password rules and hashing	Mutable UserStore IDP options and versioned recommendations	Password policy and recovery security
Passkeys and recovery readiness	Mutable UserStore IDP options and recommendations	Passkey policy reference
Invitations	Fields on each Management API v2 invitation command; security invariants are fixed	Unified invitations
Security contacts	Purpose and primary-role fields on contact operations; verification rules are fixed	Verified security contacts
Abuse protection	Mutable UserStore IDP options; legacy lockout remains available	Layered abuse protection
Identity replacement and revocation	Operation fields such as approval count and lifetime; proof and revocation rules are fixed	Identity and session security
Upgrade and activation	Preview fingerprints, explicit attestations, and locked activation metadata	UserStore migration and activation

Fixed controls are intentional

Some security behavior is not exposed as a switch. Bearer secrets are hashed, proofs expire, redemption is single-use, assurance is derived centrally, ambiguous identifiers fail closed, and old nodes are prohibited after activation. These are platform invariants, not customer preferences.

How the pieces fit together

The central ceremony binds the result to the tenant, client, authorization request, browser context, IDP instance, purpose, and user. IDP modules submit observations; the central OIDC service derives the subject, active identity, authentication time, authentication methods, and assurance.

Recommended rollout order

1. Deploy the coordinated ProAuth release and database migrations to every node.
2. Verify the durable notification outbox and configured state-store provider.
3. Preview and apply a password recommendation, or retain LegacyRegex temporarily.
4. Review legacy lockout settings and the proposed layered abuse-control values.
5. Run the hardening inventory and bounded backfill batches.
6. Resolve every quarantined canonical-identifier conflict.
7. Inventory and reissue legacy invitations.
8. Verify deployment readiness and representative account journeys in staging.
9. Record the change reference and all-nodes-current attestation.
10. Activate hardened semantics and monitor authentication, recovery, invitation, revocation, and outbox metrics.

Activation boundary

Do not activate while an older ProAuth binary can still serve traffic. After activation, rollback to a pre-hardening binary is unsupported. Authentication epochs only advance, rehashed passwords do not downgrade, cancelled legacy invitations are not restored, and completed identity replacements retain their stable outward subject.

Administration surfaces

• AdminApp User Store → Security Operations provides approvals, temporary access passes, recovery and security-event queues. User Store → Migrations provides hardening inventory, bounded backfill and activation. Identity Operations provides legacy invitation reissue and identity-replacement workflows.
• Management API v2 is the authoritative automation surface for the same workflows.
• Account Management lets an authenticated user manage verified contacts, passkeys, recovery codes, identity proofs, and tenant application sessions without accepting a caller-supplied user ID.
• UserStore API v2 provides scoped provider-domain operations for security contacts, recovery, passkey readiness, and administrative user security.

Version 1 APIs remain compatibility surfaces. New hardening behavior is exposed through version 2 APIs and cannot be bypassed through version 1.