Let’s build a clear, plain-English understanding before looking at the individual rules Keycloak offers.

The Simple Definition

A Password Policy in Keycloak is a configurable set of rules that every password in a given realm must satisfy before it’s accepted — whether that password is being set during registration, changed by the user, or reset by an administrator. Rather than being a single fixed rule, Keycloak’s password policy is built by combining smaller, individual rules together, like snapping together building blocks, until the combination matches exactly what an organization wants to enforce.

Why It’s Configurable, Not Fixed

Different organizations have very different security needs. A small internal tool used by five trusted employees might need only a basic minimum length, while a healthcare platform handling sensitive patient data might require long, complex passwords that expire regularly and can never be reused. Keycloak doesn’t force one universal standard on every deployment — instead, it exposes password policy as a flexible, per-realm setting that administrators tune to match their own risk tolerance and compliance requirements.

Weak passwords remain one of the single most common causes of account compromise — understanding why makes the case for a solid policy obvious.

Attackers rarely need to “hack” a password in the dramatic, movie-style sense. Far more often, they simply guess it, using lists of the millions of passwords leaked from other breached websites over the years, or by trying every word in a dictionary, or by testing simple variations of common words. A password policy exists specifically to make these easy, automated guessing strategies fail, by requiring passwords that don’t show up on those common lists in the first place.

Keycloak’s password policy isn’t one setting — it’s a toolbox of individual rules an administrator picks from and combines.

Composable by Design

None of these rules exist in isolation. An administrator opens the realm’s Authentication section in the Admin Console, and adds as many of these individual rules as needed, each with its own configurable parameter — for instance, “Minimum Length: 12” combined with “Digits: 1” combined with “Not Username.” Keycloak evaluates every rule in the policy each time a password is set, and rejects the password unless it satisfies all of them at once.

Understanding exactly where and when the policy gets checked clarifies what it can and can’t protect against.

flowchart TB
    U[User Sets or Changes Password] -->|1 Submits New Password| KC[Keycloak Server]
    KC -->|2 Loads Realm Policy Rules| CFG[(Realm Configuration)]
    KC -->|3 Evaluates Each Rule| CHK{All Rules Pass?}
    CHK -->|Yes| HASH[Password Hashed and Stored]
    CHK -->|No| REJ[Password Rejected With Reason]
        

Realm-Level Configuration

Password policy configuration lives inside a realm’s settings, meaning it applies uniformly to every user who belongs to that realm. This configuration is stored alongside other realm settings in Keycloak’s database, the same place that holds users, clients, and roles.

Enforcement at the Moment of Change

The policy is actively checked at the exact moment a password is being set or changed — during initial registration, a user-initiated password change, an administrator-triggered reset, or a required “update password” action. It is not re-checked on every login; a password that was valid when it was created can remain in use afterward, even if the policy is later tightened, until that user next changes their password.

Password Hashing After Acceptance

Once a password passes every rule in the policy, Keycloak never stores the plain text version. Instead, it runs the password through a one-way cryptographic hashing algorithm and stores only that hash, meaning even Keycloak’s own database never contains a readable copy of anyone’s actual password.

Let’s trace what happens, step by step, when a user tries to set a new password.

A password policy is one layer of protection, not the whole picture — it’s most effective when combined with Keycloak’s other security features.

This layered thinking reflects a broader security principle called defense in depth: no single control, however well configured, should be relied on as the only line of protection. A password policy makes weak passwords much rarer, brute-force detection catches repeated guessing attempts, and multi-factor authentication provides a safety net even if a password is somehow still compromised.

A password policy that’s too strict can backfire — understanding this balance is key to designing one well.

It might seem like stacking every possible rule — long minimum length, every character type required, frequent forced expiry — would produce the strongest possible security. In practice, security research has shown this often backfires. Users facing overly complex, frequently expiring password requirements tend to write them down, reuse slight variations of the same base password, or pick predictable patterns just to satisfy the rules, all of which can actually weaken real-world security rather than strengthen it.

Configuring a password policy, like any security control, involves real trade-offs worth weighing deliberately.

A few deeper security considerations are worth understanding beyond the basic rule list.

Even a well-designed password policy benefits from ongoing visibility into how it’s actually performing in practice.

Keycloak’s event logging can capture password update and reset events, giving administrators the raw data needed to evaluate whether a policy is striking the right balance between security and everyday usability, and to spot unusual patterns that might warrant a closer look.

Years of real-world deployments have surfaced clear guidance on what makes a password policy actually work well.

Practical, actionable habits for configuring a password policy that’s both secure and livable.

Password policy configuration shows up differently depending on the industry and the sensitivity of what’s being protected.

Across all these examples, the underlying mechanism stays the same — a realm-scoped, composable set of rules — while the specific combination chosen reflects each organization’s own balance of risk, regulation, and user experience.

Yes. Password policy is configured per realm, so a single Keycloak server can enforce completely different rules for different populations of users, such as employees versus customers.

No. A tightened policy only applies the next time a user sets or changes their password, unless paired with a required action that forces an immediate update.

Not entirely. It significantly raises the difficulty of guessing a password, but it works best alongside brute-force detection and multi-factor authentication as complementary layers of defense.

No. Any password set for a user, whether by the user themselves or by an administrator, must still satisfy the realm’s currently active password policy rules.

Generally, security guidance favors length as a stronger, more user-friendly lever than demanding many different character types, though a reasonable combination of both is common in practice.

It’s found under the Authentication section for the currently selected realm, where individual policy rules can be added, configured, and reordered as needed.

A Password Policy in Keycloak is a realm-scoped, fully configurable set of rules — built from composable building blocks like minimum length, character requirements, and history restrictions — that every password must satisfy before it’s accepted. It exists to raise the baseline strength of every password against common guessing and reuse attacks, but works best as one layer within a broader security strategy that also includes brute-force detection and multi-factor authentication. Designing a good policy means balancing genuine security benefit against real-world usability, favoring generous length and clear rules over excessive complexity or overly frequent forced changes that can quietly backfire.