It is a set of rules that controls how passwords behave for a group of people.

A simple definition

Okta is a cloud service that manages who people are and which applications they may use. This field is called Identity and Access Management, or IAM. In Okta, a person usually signs in with a password, and often a second proof as well. A password policy is a collection of settings that defines what an acceptable password looks like, how it is protected, and how it can be changed or recovered.

Rather than leaving each person to invent their own habits, the company sets the rules once. Okta then checks every new password against those rules. If someone tries to choose “123456”, Okta can refuse it. If someone enters the wrong password too many times, Okta can lock the account for a while. All of this behaviour comes from the password policy.

What a policy is made of

A password policy has settings about strength, age, history, lockout, and recovery. It is applied to chosen groups of people, and it has a priority so that Okta knows which policy wins when more than one could apply. Every Okta organisation also comes with a default policy that covers anyone not matched by another policy.

Because left alone, people choose short, predictable passwords, and attackers know it.

How people really choose passwords

Most people pick passwords that are easy to remember: a pet’s name, a birth year, a keyboard pattern, or a small change to an old password. They also reuse the same password across many sites. This is human nature, not stupidity, because remembering dozens of unique passwords is hard.

How attackers exploit this

Attackers do not sit and guess one password at a time. They use programs that try millions of common passwords against many accounts. They also take lists of leaked passwords from old breaches and try them on new sites, betting that people reused them. A weak password falls to these attacks very quickly.

What a policy achieves

A password policy lifts the floor. It prevents the worst choices, slows down guessing attacks through lockouts, reduces the damage of leaked passwords, and gives people a safe way to recover access without calling the help desk. It does not make a system perfectly safe, but it removes the easiest openings.

A few words appear in every conversation about password rules. Learn them once and the rest is simple.

A policy is built from a small number of clear parts. Understanding each one removes the mystery.

Part 1: The policy itself

The policy has a name and a description, and it is active or inactive. It decides which groups of people it applies to. Think of it as a labelled folder holding the rules.

Part 2: The settings

Inside the policy are the settings that shape passwords: how long, how complex, how old, how often changed, and how lockouts work. These are the main dials an administrator turns.

Part 3: The rules

A policy can also contain rules that apply in different situations. For example, one rule may describe what happens for people on the office network, and another may describe what happens for people elsewhere. Rules often decide how password recovery, password change, and account unlock behave.

Part 4: The scope and priority

A policy is applied to chosen groups. When an organisation has more than one policy, they are ordered by priority. Okta looks from the top, finds the first policy that applies to the person, and uses it. The default policy sits at the bottom as a safety net for everyone else.

flowchart TD
  P[Password Policy] --> S[Settings: length, complexity, age, history]
  P --> L[Lockout settings]
  P --> R[Rules: recovery, change, unlock]
  P --> G[Applies to chosen groups]
  P --> PR[Priority order among policies]
        

These settings decide how hard a password is to guess. They are the most visible part of any policy.

Minimum length

Length is the single most useful strength setting. Each extra character multiplies the number of possible passwords, so a longer password is much harder to guess than a shorter one with the same mix of letters. Many modern security recommendations encourage longer passwords, such as long phrases, rather than short ones stuffed with symbols.

Complexity rules

Administrators can require a mix of character types: lowercase letters, uppercase letters, numbers, and symbols. They can also forbid the password from containing parts of the person’s username, first name, or last name. These rules stop the most obvious choices, though they can also push people toward predictable tricks like adding a number and exclamation mark at the end.

Blocking common passwords

Okta can check passwords against a list of very common ones and refuse them. This is a powerful setting because it blocks the passwords attackers try first, regardless of length or character mix. Many modern guidelines place more value on blocking known weak and leaked passwords than on strict complexity rules.

These settings control how long a password lives and whether old ones may come back.

Maximum age (expiry)

An administrator can require that passwords expire after a number of days. When the time comes, the user must choose a new one. Okta can warn users some days before expiry so they are not surprised. For many years expiry every sixty or ninety days was standard, but current guidance questions it, because forced frequent changes lead people to make tiny, predictable edits to the old password.

Minimum age

A minimum age stops people from changing their password several times in a row to cycle back to an old favourite. It forces a gap between changes. This setting works together with history.

Password history

History tells Okta to remember a number of recent passwords and refuse to accept any of them again. Without history, a person told to change their password could just switch back and forth between two favourites.

Lockout makes it painfully slow for attackers to try many passwords against one account.

How lockout works

An administrator sets a number of allowed failed sign-in attempts. When someone exceeds that number, Okta locks the account. After that, the account stays locked until it is unlocked by an administrator, by the user through self-service, or automatically after a waiting period, depending on how the policy is set.

Automatic unlock

Many organisations choose to unlock accounts automatically after some minutes. This stops attackers from guessing endlessly but also saves the help desk from constant unlock requests. The waiting period is a trade-off: a longer period slows attackers more but may annoy real users who simply mistyped.

Notifying the user

Okta can send an email to the user when their account is locked. This is helpful because an unexpected lockout may be a sign that somebody else is trying to sign in as them. A quick alert gives the person a chance to report it.

People forget passwords every day. A good policy lets them recover safely without a phone call.

Self-service password reset

When a person forgets their password, they use a “forgot password” link. Okta first asks them to prove who they are using a method that has been set up in advance, such as a code sent to their email or phone, an approval on a phone app, or a security key. Only then can they choose a new password. This saves large amounts of help desk time.

Which recovery methods to allow

Not all recovery methods are equally safe. A code sent by text message can be intercepted. A reset link sent to a personal email is only as safe as that email account. Stronger methods such as a phone app or a hardware key are harder for attackers to abuse. Administrators choose which methods are allowed, and may allow weaker ones for ordinary staff but stronger ones for powerful accounts.

Unlocking accounts

Policy settings also decide how a locked account can be reopened. It may be allowed through self-service using a trusted method, or it may require an administrator. High-risk groups often need stricter paths.

sequenceDiagram
  participant U as User
  participant O as Okta
  participant V as Verification Method
  U->>O: Click forgot password
  O->>U: Ask for proof of identity
  U->>V: Use email, phone, or app
  V->>O: Proof confirmed
  O->>U: Allow new password
  U->>O: Enter new password
  O->>O: Check against policy rules
  O->>U: Password changed
        

One organisation can have several password policies. Okta decides which one applies to each person.

Applying policies to groups

A password policy is attached to one or more groups of people. A company might create a stricter policy for administrators and a more relaxed one for general staff. People in the administrator group receive the strict rules, and everyone else receives the standard ones.

Priority decides conflicts

A person may belong to several groups, and several policies may target them. Okta solves this with a priority order. It checks policies from the top of the list, finds the first one that applies, and uses it. This is why the order of policies matters. A very specific policy should usually be placed above a broad one.

The default policy

Every organisation has a default password policy. It applies to anyone who is not covered by a higher-priority policy, and it cannot be removed. Many teams leave it as a sensible baseline and create extra policies only for groups that need something different.

flowchart TD
  U[User signs in] --> Q1{In Admin Policy group?}
  Q1 -->|Yes| A[Apply strict Admin policy]
  Q1 -->|No| Q2{In Contractor Policy group?}
  Q2 -->|Yes| B[Apply Contractor policy]
  Q2 -->|No| C[Apply Default policy]
        

Not every password is checked by Okta. It depends on where the user’s account is mastered.

Okta-mastered users

Some users exist only inside Okta. For them, Okta stores the password in a protected form and applies its own password policy directly. All the settings in this guide apply to them in full.

Users mastered in another directory

Many companies already keep user accounts in another directory, such as Microsoft Active Directory or another identity source, and connect it to Okta. In these cases the original directory may remain the place where passwords are stored and checked. The rules of that directory then govern things like complexity and expiry, and Okta works with it rather than replacing it.

Why you must know which case you are in

If you change an Okta password policy and nothing seems to happen for some users, the likely reason is that their passwords are controlled elsewhere. Always find out where a person’s account is mastered before troubleshooting password behaviour.

A password policy is one layer. Modern security stacks several layers together.

Why MFA matters

Multi-factor authentication asks for at least two different kinds of proof, such as a password plus an approval on a phone. If a password leaks, the attacker still lacks the second proof. Security studies from large technology companies have repeatedly found that MFA blocks the vast majority of automated account takeover attempts. A password policy without MFA leaves the door only half protected.

Sign-in rules versus password rules

In Okta, password rules say what a good password looks like. Separate sign-in rules, often called authentication policies, say when a password alone is enough and when a second proof or stronger method is needed. The two work together: one makes the password solid, the other decides how much more to ask for.

The move toward passwordless

Many organisations are reducing their reliance on passwords. With passwordless sign-in, a person unlocks a trusted device using a fingerprint or face scan, and the device proves their identity without a password ever being typed. This removes whole classes of attack, such as phishing for passwords. Even then, password policies still matter for people who have not moved yet and for fallback and recovery paths.

A good policy starts with thinking about people and risk, not with ticking boxes.

A policy is not finished when it is saved. You must watch how it behaves in real life.

What Okta records

Okta writes log entries when people sign in, fail to sign in, change a password, reset a password, get locked out, or get unlocked. These records help administrators see patterns, such as a sudden burst of failed sign-ins that may signal a guessing attack, or many lockouts in one day that may point to a confusing policy change.

Signals worth watching

Troubleshooting a user who cannot set a password

Password policies bring real protection, but every rule carries a cost in convenience.

Finding the balance

The central trade-off is between safety and ease. A policy so strict that people cannot cope will be bypassed. A policy so loose that anything is accepted protects nothing. The practical middle is a long minimum length, a blocklist of weak passwords, few forced changes, sensible lockout, strong recovery, and MFA as the main second layer.

Other organisations have already made the mistakes. You can learn from them.

Helpful patterns

Anti-patterns to avoid

A compact checklist for anyone designing or reviewing an Okta password policy.

Here are everyday scenes that show password policies at work.

Why this matters beyond security

Many laws and industry standards ask organisations to demonstrate sensible password controls and the ability to investigate incidents. A clear policy with records of sign-ins, lockouts, and resets gives auditors the evidence they look for.

A password policy defines what a password must look like and how it is managed. An authentication policy, sometimes called a sign-in policy, defines which proofs are required to access an app or sign in, such as a password plus a second factor. They work together.

Yes. You can create several policies, attach each to different groups, and order them by priority. The first matching policy in the list applies to a person, and the default policy covers everyone else.

Generally yes. Length multiplies the number of possibilities quickly, and long phrases are easier to remember than short strings full of symbols. Modern guidance prefers length plus a blocklist of known weak passwords.

Current guidance leans against frequent forced expiry, because it encourages predictable small changes. Many organisations use long expiry periods or none at all, and force a change when there is evidence of compromise. Choose according to your risk and any rules you must follow.

It makes Okta remember a number of recent passwords and refuse them if the person tries to reuse them. It prevents simply flipping between a couple of favourite passwords.

The person cannot sign in until the account is unlocked. Depending on policy, it may unlock automatically after a delay, through self-service with a trusted method, or by an administrator. Okta can also email the user about the lockout.

Common reasons are that a higher-priority policy applies to them, they are not in the groups you targeted, or their passwords are mastered in another directory whose rules govern. Check group membership, priority order, and the password source.

Stronger methods include an approval from a phone app and a hardware security key. Codes sent by text message or links sent to personal email are weaker. Allow weaker methods only where the risk is low, and be stricter for powerful accounts.

Not for the passwordless sign-in itself, since no password is typed. However, the policy still matters for people who still use passwords and for fallback and recovery paths, so it should not be neglected.

Yes. Administrators can require a user to change their password, for example after a suspected compromise. This is the reason many modern setups prefer forced changes on suspicion instead of on a fixed calendar.

No. Passwords can still be stolen through phishing or reused elsewhere. A password policy is one layer, and it works best with multi-factor authentication, risk-based sign-in rules, monitoring, and user education.

Use a test organisation. Create a simple policy for a small test group, try setting passwords that break each rule, trigger a lockout with a test user, and walk through the recovery flow. Seeing each rule’s effect builds understanding quickly.

A password policy in Okta is the rulebook that decides how strong passwords must be, how long they last, what happens after repeated mistakes, and how forgotten passwords are recovered. It is attached to groups of people and ordered by priority, with a default policy as the safety net. The best policies favour length and blocklists over heavy complexity, avoid needless forced changes, set sensible lockout, protect the recovery path, and always work together with multi-factor authentication. If you remember the front-door lock from the beginning, you already hold the main idea: a lock should be hard for thieves and easy for the family.