Importing password hashes into authentik without forcing resets
A team moving users from a legacy identity store into authentik usually wants to avoid a mass password reset, and authentik 2026.5 can import pre-hashed Django passwords through AUTHENTIK_BOOTSTRAP_PASSWORD_HASH, the hash_password command, blueprints and the user password-hash API. The effort depends mainly on which hash formats the source system uses and how many applications still authenticate against that old store during the cutover. Start by exporting a sample of hashes, identifying the algorithm and parameters for each, and confirming with the release notes for your target version which formats authentik accepts directly. Formats that are not Django-compatible need conversion or a different approach, and that work should be scoped before any user is moved.
Plan for the limit that matters most: a hashed-password import updates only authentik's local password verifier. authentik never receives the raw password, so the import cannot write the new credential back to an LDAP or Kerberos source. Any system that still authenticates against that directory will keep the old password, and users will see two passwords until that system is retired or repointed. Map every consumer of the legacy store before cutover, decide whether each one moves to authentik's LDAP provider, stays on the source, or is changed, and tell users which password to use where. Confirm this behavior against your own environment in a test tenant before relying on it.
Before importing production hashes, test the full path with a small set of accounts: import, sign in, change the password, and check the audit trail. Confirm the hash parameters survive the export unchanged, because a single altered iteration count or salt encoding will fail every login for that format. Keep the import file and its source system access under the same controls you apply to other credential data, and remove temporary exports once the migration is verified. Ask your DeployOpen or internal team to document the rollback path, since reverting a partial import affects only the local verifier and must be coordinated with the legacy store.
Which password hashes map to authentik directly
This table compares common ways source systems store passwords against what authentik 2026.5 can import as a pre-hashed Django password. Read each row as a question to answer about your own export: if the format is not Django-compatible, plan a conversion or a user-driven reset before cutover.
| Source storage | Importable as Django hash | Migration note |
|---|---|---|
| Django PBKDF2 or other Django-format hashes | true | Import directly through the password-hash API, blueprints or bootstrap variable. Confirm the exact algorithm prefix against the 2026.5 release notes and test a sample user before bulk import. |
| Bcrypt, SHA-512 crypt or other common schemes | false | Not covered by the supplied 2026.5 import capability. Confirm with the release notes whether any other scheme is accepted, otherwise plan a staged reset or re-hash at next login. |
| Hashes with custom salts or application-specific wrapping | false | Usually needs a conversion step to a supported Django format, which requires the original algorithm parameters. Confirm the parameters from the source system before attempting conversion. |
| Reversibly encrypted or plaintext passwords | false | Import of raw values is not part of the supplied capability. Decryption keys and plaintext exports carry significant security risk, so treat them as a last resort and document the handling. |
| Passwords held in LDAP or Kerberos | null | Hash import updates only authentik's local verifier. The directory password is unchanged, so users may end up with two different passwords unless the directory remains the source of truth. |
| Accounts with no password, such as SSO-only or service accounts | null | Nothing to import. Confirm which accounts need a usable local password and which should sign in only through an upstream source or a token. |
Documented import paths for pre-hashed passwords
authentik 2026.5 documents four ways to load pre-hashed Django passwords into its local password verifier. Each route suits a different moment in a migration, from first bootstrap to ongoing user moves, and each needs different preparation from the operator. Choosing the right one depends on how many accounts you move, whether they arrive in batches, and who will run the import.
Bootstrap password hash
The AUTHENTIK_BOOTSTRAP_PASSWORD_HASH setting lets the initial administrator account start with a pre-hashed Django password instead of a plain-text value. It suits the first login on a fresh install, not bulk user loads. Before you rely on it, confirm the exact value format with the 2026.5 release notes and make sure the hash is supplied through your secret handling process, not a committed environment file. Test the first login in a staging instance before the production install.
The hash_password command
The hash_password command produces a Django-format hash that you can then use in other import paths. It is useful for generating or checking hashes outside the running user population, for example when you want to confirm that a hash from a legacy system is in a format authentik accepts. Run it in a controlled environment, keep its output out of shell history and logs, and verify the result by logging in with a test account before any batch work begins.
Blueprints for scripted loads
Blueprints let you declare users and their password hashes as configuration that authentik applies on start or on reconciliation. This suits repeatable, reviewable loads across environments, such as a staging rehearsal followed by production. Prepare a version-controlled file, restrict who can read the hash values, and run the blueprint against a copy of the data first. Check that re-applying the blueprint does not overwrite passwords users have since changed, and confirm the behavior for your 2026.5 setup.
The user password-hash API
The user password-hash API sets a pre-hashed password on an existing user account through authentik's API. It fits migrations where accounts are created by a separate script that exports users in batches, or where a source system pushes updates over time. Plan for authentication to the API with a scoped token, rate handling for large batches, and logging that records which accounts changed without storing the hashes themselves. Confirm the endpoint details in the release notes before writing code.
Sequence for a hash import with parallel running and cutover
This sequence moves users' password verifiers into authentik without forcing resets, proves logins work before any user depends on authentik, and ends with the legacy store retired. Each step has a named output so the team knows when it can move on.
Inventory hash formats and user counts
The identity or platform team exports, from the legacy store, a count of users grouped by password hash format and by the applications that authenticate against them. Formats that authentik can import directly, such as Django-format hashes, need no conversion. Any other format needs a decision: convert it through a documented process, or plan a forced reset or staged sign-in for those accounts. The step is done when every user is assigned to one format group with a named owner for the conversion or reset path, and the security team has signed off on how the hashes are handled during export.
Run a pilot import in non-production
The team builds a non-production authentik instance from the same version planned for production, then imports a small, deliberately mixed set of users using the hash import method that fits the format group, such as the user password-hash API or a blueprint. Imports update only authentik's local password verifier, so the pilot also confirms that no change is expected in the source directory. The step is done when every imported account appears in authentik with the expected groups and the import log shows no rejected records.
Validate logins against a sample of accounts
Testers sign in to each target application through authentik using a sample that covers every hash format group, locked or disabled accounts, accounts with MFA enrolled, and accounts with unusual characters in passwords. Each login is recorded as passed or failed with the protocol used, such as OIDC, SAML or LDAP. Any failure is traced to a format or import error before the full run. The step is done when every format group has a passing login in each application that depends on it, and failures have documented causes.
Import all users and start the parallel run
The team runs the full import against production authentik, then keeps the legacy store authoritative: it still accepts password changes, account creation and disablement. A named process copies these changes into authentik during the parallel period, because a password changed in the legacy store will not match the imported verifier until it is re-imported. Application sign-in continues through the legacy store. The step is done when a reconciliation report shows the user counts match and the change-sync job has run without errors for a defined observation window agreed by the team.
Cut over application sign-in to authentik
Applications are switched to authentik one group at a time, starting with low-risk applications and ending with those that hold the most sensitive data. The change for each application is the provider configuration and the login endpoint, and the legacy store stays available so that the switch can be reversed. Rollback means pointing the application back to the legacy store while the parallel sync continues, so that users who changed passwords in authentik during cutover are reconciled before the next attempt. The step is done when every application in scope signs users in through authentik and the rollback path has been tested.
Decommission the legacy store
Once every application has run on authentik for the agreed period without needing rollback, the team stops the change-sync job, makes the legacy store read-only, and archives its data under the retention rules that apply to your organization. Keeping the legacy store running is itself a risk, so its removal should be tracked as a formal change with approval. The step is done when the legacy store has no active application dependencies, its final export is archived, and access to it is removed.
What happens to passwords after import and why LDAP and Kerberos stay unchanged
A hash import changes only the password that authentik checks itself. authentik never receives the cleartext password during an import, so it has nothing it can send back to an LDAP directory or a Kerberos key distribution center. The imported Django hash becomes authentik's local password verifier, and that is the only credential the import touches. Users who still sign in through a directory source keep their existing directory password, and authentik has no way to alter it. Plan for two separate credential stores after cutover, and say so in the user communication so people do not assume one change covers both.
The practical effect appears in three places. Users who authenticate to authentik with the imported password will sign in with it, but any application or client that still binds to LDAP or obtains a Kerberos ticket will continue to require the directory password. A user who changes their password in authentik later updates only the authentik verifier, and a user who changes it in the directory later will not affect the authentik verifier unless the two are reconciled by another mechanism. Confirm with your directory and identity team which of these paths is still live during the transition, and check how the LDAP and Kerberos clients in your environment are configured before you announce that passwords are unified.
Decide before the import which credential is authoritative for each population, and document the answer for help desk staff. If the directory must remain the source of truth, verify that the imported authentik password is not treated as a second source of truth in your reset procedures. Review the Release 2026.5 notes for the exact import paths and confirm the behavior in a staging instance with a test user before relying on it in production. Your IAM team should also confirm how password history and password policy interact with a changed local verifier, since those settings may not match what the directory enforces.
What drives the effort and cost of a hash import
This table lists the factors that change the size of a password hash import and whether each one is paid once or recurs. Read it as a checklist for a written scope: each driver names what to ask the partner or your own team to estimate before work starts.
| Driver | Why it changes effort | What to request in a written scope |
|---|---|---|
| Hash formats needing conversion | Each source format (Django-native, bcrypt, PBKDF2 variants, MD5 or SHA-1 legacy hashes, LDAP-style schemes) may need a parser, a re-hash step or a documented exclusion. Formats that cannot be imported force a reset for those users. | Inventory of every hash format in the old store, with counts per format and a decision for each: import as is, convert, or reset |
| Number of users and account states | Disabled, dormant, service and shared accounts need rules. Large populations take longer to validate and to reconcile after a failed batch. | Account categories, the rule for each, and the reconciliation report format agreed before the first run |
| Applications and directories still on the old store | While other systems read from the legacy directory, both stores must stay aligned or users see different passwords. Each dependent system adds cutover and rollback work. | List of consumers of the old store, their authentication method, and who owns each cutover date |
| Passwords changing during the parallel period | If users change passwords in the old system while authentik is live, imported verifiers go stale. Sync or freeze rules add build and operations work that recurs until cutover ends. | Written decision on freeze, dual write or one-way sync, plus the owner who approves exceptions |
| MFA enrollment and reset needs | Imports carry only password verifiers. Users re-enroll second factors, and help desk load rises. Enrollment flows and communications are one-time build work, but support load recurs during rollout. | Enrollment flow design, recovery path for users without a device, and expected help desk procedure |
| LDAP and Kerberos write-back | Imported hashes update only authentik's local verifier. Any system that validates against LDAP or Kerberos keeps the old password, so each one needs its own plan. | Confirmed list of systems that stay on LDAP or Kerberos and their password change process |
| Testing scope | Test cases cover each hash format, each login path (web, API, LDAP bind if used), lockout behavior and rollback. Broader scope takes more time but reduces cutover risk. | Test matrix by format and application, with the environment used (staging copy of real data or synthetic data) |
| Deployment model | Docker Compose suits test and small production setups. Kubernetes with a separately managed PostgreSQL adds platform work, but the database and backup design are needed for either model. | Target model, PostgreSQL ownership and backup responsibility, and the authentik version used for both staging and production |
| Migration tooling and runbook | Import scripts, blueprint files and the password-hash API calls need version control, review and a rerunnable procedure. This is one-time build work that is reused for later batches. | Deliverables list: scripts or blueprints, runbook, rollback steps and audit log of imported records |
What usually goes wrong with password hash imports
Most password hash import problems are not technical failures in authentik itself. They come from assumptions about where passwords live, which parameters were carried across, and how the import was tested before users depended on it. Each card below names one risk and the check that prevents it.
Mismatched hash parameters after conversion
A hash that is converted into Django's format still has to verify with the same algorithm, iteration count and salt it was created with. If a conversion script rounds an iteration count, drops a salt, or assumes a default that differs from the source system, every affected user will fail to log in with a correct password. Before any bulk import, take a sample of accounts from each source hash type, import them into a test instance, and confirm that known passwords verify. Record the algorithm and parameters used for each hash family so the mapping can be reviewed.
Two systems holding different passwords
After import, authentik holds its own verifier for each user, separate from the directory or legacy system the user may still sign in to. If a user changes the password in one place, the other keeps the old value, and support tickets follow. Decide before cutover which system is the authoritative place for password changes, then disable or redirect the change path in the other system. Write this decision into the user communication and the runbook so help desk staff know where a reset must happen.
Assuming LDAP or Kerberos will update
Hashed-password imports change only authentik's local password verifier. Authentik never receives the raw password, so it cannot write the change back to an LDAP directory or a Kerberos realm. Teams that expect a password reset in authentik to appear in Active Directory, OpenLDAP or FreeIPA will see mismatched credentials for any service that still authenticates against those sources. Map every application to the system that verifies its logins, and confirm with the directory owner whether a separate sync or reset process is needed.
Exporting hashes to unprotected storage
Password hashes are sensitive even when salted, because they can be attacked offline. Export files, blueprint YAML and command output can end up in ticket attachments, shared drives or CI logs. Restrict the export to an encrypted, access-logged location, run the import from a controlled host, delete intermediate files after the import is verified, and keep the import out of pipeline logs. Ask your security team to review the handling procedure before the first export is generated.
Skipping a pilot import
A full cutover without a pilot exposes every user to a conversion error at once. A pilot with a small group of accounts from each source hash type shows parameter mismatches, flow or group assignment mistakes and unexpected login prompts before they affect the whole population. Plan a pilot with named test users, a fixed success check (each test user signs in with the old password and the expected application), and a rollback step that removes or disables imported accounts. Use the results to decide whether the full import is ready.
Questions teams ask before importing password hashes
What does a password hash import cost and what drives the effort?
The main cost is the internal or partner engineering time to export hashes, confirm their format, load them and test logins. Effort rises with the number of user stores, the number of hash formats in use, and how much of the cutover depends on the import working for every user. The supplied release information does not give a price or effort figure for this work, so ask any partner for a written scope that lists each step and who performs it. One-time work covers the import and testing. Recurring costs come from running authentik itself, which is a separate line item.
How long does a typical password hash import take?
Duration depends on planning factors rather than a fixed number. The main ones are how many user accounts and hash formats you have, whether every format can be imported as is or needs conversion first, how many applications must be tested after cutover, and whether you can run a staged pilot before moving all users. Confirm the schedule with your own team or a partner against your environment and your change windows. Plan time for a pilot group of accounts to prove logins work before the full population moves.
What does our team need to provide before the import starts?
You need an export of the password hashes and matching user records from the source system, along with the hash algorithm and parameters for each format. You also need a test authentik instance that matches the production version, a list of applications that sign users in, and an owner for cutover testing. Access to the source system must be approved under your own security controls. Confirm with your security team how hash exports are handled, stored and deleted after the import.
Can our own team run a password hash import without outside help?
Yes, if your team has the skills to export hashes, work with authentik's blueprints or the user password-hash API, and test logins end to end. The import uses documented mechanisms in authentik 2026.5, including the hash_password command and blueprints. Teams with limited identity engineering capacity often bring in a partner for planning, format checks and testing. Either way, agree who owns rollback and who signs off that every user population can sign in.
Do LDAP or Kerberos passwords change when we import hashes into authentik?
No. Imported hashes update only authentik's local password verifier. authentik never receives the raw password, so it cannot write the password back to an LDAP or Kerberos source. Users whose passwords live in LDAP or Kerberos will keep those credentials in those systems. Plan for that split, especially if some applications still authenticate against the directory directly. Confirm the behavior in the authentik 2026.5 release notes before you design the cutover.
Which password hash formats need conversion before import?
authentik 2026.5 supports importing pre-hashed Django password formats. Hashes from other systems in other formats generally need to be converted to a Django-compatible format before import, or the users must reset their passwords. Check the exact format details in the authentik 2026.5 release notes, then test a sample of accounts from each source system. Any format you cannot confirm should be treated as needing a conversion plan or a forced reset.
What are the main risks if a hash import goes wrong?
The most common risk is that some users cannot sign in after cutover, which generates support load and can block access to critical applications. A second risk is that a format is misread, so logins fail silently for a subset of accounts. A third is that hash exports are left in place longer than policy allows. Mitigate these with a pilot group, a documented rollback path, a login test for every hash format, and a deletion step for export files once the import is verified.
How DeployOpen scopes and delivers a password hash migration
DeployOpen plans password hash imports into authentik as part of a written scope, starting from an inventory of the hash formats your source directories actually store. We build, test and document the import path inside your own infrastructure, then hand over the runbook and the verification steps your team needs to run it again.
How we scope
- Inventory every source that holds password hashes and record the exact hash format each one uses.
- Identify which formats authentik can import directly and which need conversion before the import step.
- Agree in writing which user populations move by hash import and which keep their current sign-in path.
How we build
- Configure the import path with the hash_password command, blueprints or the password-hash API, matched to your scoped formats.
- Test the import on a copy of representative accounts, confirming that known test passwords sign in correctly.
- Check that imported accounts that were not migrated keep working in the original source during the transition.
How we hand over
- Deliver a runbook covering the import steps, rollback points and the order in which user batches move.
- Document that hashed-password imports update only the authentik password verifier and do not write back to LDAP or Kerberos.
- Walk your identity and operations staff through verification so they can repeat the import for later batches.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask your DeployOpen contact to confirm how a retainer would cover authentik version upgrades that touch the password verifier.
