authentik customization services: flows and policies

What authentik customization involves

Customizing authentik means changing how people sign in, enroll and recover their accounts without changing authentik's code. The work sits in five places: flows, which are the ordered sequences a user passes through; stages, the individual steps inside a flow such as identification, password, MFA or prompts; expression policies, which decide whether a flow or stage applies to a user based on attributes or context; property mappings, which translate identity data into the claims or attributes sent to applications; and branding, which covers the sign-in page, logos, themes and email templates. Each of these is configured in the admin interface or as code, so the result depends on how carefully it is recorded.

Most organizations outsource this work when a trigger forces a change to a live login path. Common triggers include new enrollment rules, such as restricting self-registration to a verified email domain; an MFA step-up requirement for administrators or for access from unmanaged devices; a branded sign-in page for a customer or partner portal; or a changed recovery procedure after a security assessment flagged account recovery as a weak point. Each trigger touches several flows at once, so the change needs a test plan covering every affected path, including the ones users rarely take.

Whether to build this in-house depends on who on your team can read the flow graph, write and test expression policies, and review changes before they reach production. A team with those skills and a staging environment can usually handle small changes itself. A partner is more useful when the change crosses several flows, needs a documented rollback, or must be reproducible across development, staging and production.

Before designing around any feature, confirm your edition's terms. The authentik core is licensed under the MIT license, but code in the authentik/enterprise/ directory is under a separate enterprise license. Some capabilities you may want in flows or policies, such as certain provider integrations or audit features, belong to that enterprise code. Ask the authentik team or read the license in that directory, then confirm in writing which features your edition allows before you commit to a design.

What the customization work includes

Each card is a deliverable you can open, read and test after the engagement ends. Together they cover the login, enrollment, recovery and MFA paths, plus the configuration that makes them reproducible in every environment.

Flow designs for core journeys

A written map of the login, enrollment, password recovery and MFA enrollment flows, showing each stage, its binding order and the branch taken for each user state. Check that every journey has a defined path for a locked account, a user without a second factor and a failed verification.

Stage configuration records

An inventory of every authentik stage bound to each flow, with its settings, such as identification, password, MFA, prompt and user write behavior. Review the stage order and the conditions that skip or repeat a stage, because a misplaced stage is the most common cause of a login loop or an unexpected prompt.

Expression and policy logic

The expression policies and policy bindings that decide who reaches which flow or application, with a note on the inputs each expression reads. Review each expression for its failure behavior, since an error in an expression can deny access or allow it unintentionally, and confirm which group or attribute checks it depends on.

Property mappings for user attributes

The property mappings that set or transform user attributes, group membership and claims sent to applications, with a table of source, target and format for each. Check that claim names match what each relying application expects and that no mapping exposes an attribute the application does not need.

Branding and template files

The brand settings, custom templates and static assets used on login, enrollment and recovery pages, with a list of every text string that users see. Test each page in the browsers and languages your users use, and confirm that error and email messages carry the wording your help desk expects.

Version-controlled configuration export

A blueprint export of flows, stages, policies, mappings and brand settings stored in a Git repository, with a documented apply step for each environment. Confirm which secrets and environment-specific values are kept out of the repository and how a change moves from a test instance to production.

Test evidence for each journey

Recorded results for the login, enrollment, recovery and MFA paths, including negative cases such as wrong credentials, expired recovery links and a missing second factor. Ask for the test scripts and the environment and version each run used, so your team can repeat the checks after a future change or upgrade.

Handover documentation for operators

A runbook that explains how each flow is built, how to change a stage or expression safely, how to roll back a blueprint and who approves changes. Ask whether the document covers the authentik version the configuration was built on, so future upgrades can be checked against it.

What drives cost and duration

This table lists the factors that change how much flow, stage and policy work an authentik customization needs, why each one matters, and how to keep it contained.

Driver	Why it changes effort	How to keep it down
Distinct user journeys	Each journey (sign-in, enrollment, recovery, consent, invitation) is a separate flow with its own stage order, bindings and test cases, so effort grows with every new path.	Agree the full list of journeys before build starts and reuse shared stages across flows instead of cloning flows.
Policy logic complexity	Expression policies that combine group membership, attributes, IP ranges and risk signals are harder to write, read and test than simple group or application bindings.	Keep expressions short, move reusable logic into named policies, and record the intended outcome for each rule so reviewers can check it.
User attribute sources	Property mappings that pull from LDAP, upstream identity providers, SCIM or manual input each need field mapping, data-type checks and handling for missing or conflicting values.	Limit sources to the ones that own the data, document which source wins for each attribute, and test records with incomplete attributes.
Applications and providers bound to each flow	Every application or provider that uses a custom flow can change behavior, so each binding adds a regression check when flows or stages change.	Bind one shared flow to many applications where the behavior is the same, and keep a register that maps each flow to its providers and applications.
Environments and promotion method	Separate development, test and production instances need the same flows, stages, policies and mappings. Manual copying between them is slow and error-prone.	Manage flow and policy definitions as exported configuration under version control, promote them through the same pipeline each time, and keep environment-specific values outside the exported files.
Edition-dependent features	Some capabilities (such as certain directory integrations, mTLS, privileged access management and enhanced audit logging) require the Enterprise edition, and a design that depends on them needs a licensing check first.	Confirm the required features against the current pricing and edition documentation before designing flows, and avoid building journeys that depend on a feature the chosen edition lacks.
Compliance evidence requirements	Assessors may ask for records of who changed a flow, when, and how the change was tested. Producing that evidence adds work to every change.	Define the evidence needed before build, keep changes traceable through version control and review, and confirm with your assessor which artifacts they accept.
Depth of regression testing	Login and recovery paths affect every user, so testing must cover each journey, each bound application and failure cases such as expired codes or locked accounts. Deeper coverage takes longer.	Scope tests to the journeys and bindings that changed, automate repeatable sign-in checks, and keep a short manual checklist for branding and edge cases.

Project phases and outputs

The sequence moves authentik flows, stages and policies from a documented user journey to a tested, version-controlled configuration that your team can run after handover.

Inventory journeys and capture requirements
We map every login, enrollment, MFA and recovery journey your users take, the applications behind each one, and the rules that apply to them. Your security and application owners confirm the list. The output is a journey inventory with requirements per journey, including which flows must stay unchanged and which policies must block access.
Design flows, stages and policies
We design each flow as an ordered set of stages, then define the bindings, expression policies, property mappings and branding that shape it. Each design choice is traced back to a requirement from the inventory. The output is a flow design document that lists every flow, its stages, its policy bindings and the expected outcome for each user path.
Build in a non-production instance
We build the flows, stages and policies in a non-production authentik instance that matches your target version and deployment pattern. Changes are made through the admin interface or blueprints under one agreed convention. The output is a working non-production build with a change log that maps each object to its design requirement.
Export configuration and version control
We export the configuration as blueprints and store them in your version control system with review rules, so each change has an author and an approval. Secrets are kept out of the repository and injected per environment. The output is a repository in which a clean instance can be rebuilt from the blueprints and the same commit yields the same configuration.
Test, including negative cases and recovery
We test the happy path for each journey, then the failure paths: wrong passwords, expired or missing MFA devices, users outside policy scope, disabled accounts and interrupted enrollment. We also test recovery paths, including lost MFA devices and administrator-assisted reset. Your acceptance owners sign off against the written test cases. The output is a test record with pass or fail results and any defects logged for correction.
Promote and cut over
We promote the tested blueprints to production through the same pipeline used in testing, with a documented rollback step for each change. Cutover order follows the journey inventory, and applications are switched to the new flows one at a time. The output is a production configuration matching the tested commit, plus a cutover log that records each change and its verification.
Hand over with maintenance guidance
We train your administrators on the repository layout, the review process and how to add a flow or policy without breaking existing journeys. We document the recovery procedures and agree how future upgrades will re-run the test cases. Ongoing support can be scoped separately. The output is a handover pack with runbooks, the test suite and a named list of owners. Ask for a schedule with each phase in the written scope.

What stays in-house and what goes to a partner

This table shows which authentik customization work your identity team usually keeps and which parts a partner typically builds, with the skills each part requires, so you can divide the work before scoping.

Part of the work	Usually kept in-house	Usually outsourced and skills required
Login, recovery and enrollment rules	Defining which sign-in methods, recovery paths and self-enrollment options the organization allows, and who approves them. Requires identity policy ownership and a clear view of user populations.	Translating those rules into flow and stage designs. Requires identity architecture, familiarity with authentik stage bindings and security review of the resulting authentication logic.
Policy decisions and access rules	Approving which groups, applications and risk conditions a policy must enforce, and signing off on exceptions. Requires access governance and application owner input.	Writing expression policies and binding them to flows and applications. Requires Python-style expression writing, testing against sample users and an understanding of authentik's policy evaluation order.
Property mappings and claims	Deciding which user attributes must appear in tokens and assertions for each application and which attributes are sensitive. Requires data classification and application owner knowledge.	Building property mappings for OIDC claims, SAML attributes and LDAP output. Requires Python-style expression writing and protocol knowledge for OAuth2/OIDC and SAML.
Branding and user-facing templates	Approving logos, wording, legal text and language requirements. Requires brand and communications ownership.	Customizing flow templates and styling for the login and recovery pages. Requires frontend templating, accessibility checks and testing across browsers.
Configuration pipeline and environments	Choosing the source repository, approval gates and which environment promotes to production. Requires change management ownership.	Exporting flows, stages, policies and mappings as code and wiring promotion between environments. Requires GitOps practice, secret handling for environment-specific values and repeatable restore testing.
Security review of changes	Making the final call on each authentication change and keeping evidence of approval. Requires security governance and authority to block a release.	Reviewing flow logic for bypass paths, weak fallbacks and unintended policy results before release. Requires security review of authentication logic and knowledge of common flow misconfigurations.
Testing and rollout verification	Defining acceptance cases for real users and confirming sign-in outcomes after each release. Requires operational ownership and support staff involvement.	Writing automated and manual test cases for each flow path and running them against staging. Requires test design, authentik administration experience and scripting for regression checks.

What usually goes wrong

Most authentik customization problems start with a change that looks small in the admin interface but affects every login, recovery path or application that depends on that flow.

Stage ordering locks users out

A flow that places an identification, password or MFA stage in the wrong sequence can block every login, including the administrator account used to repair it. Test each modified flow with a non-admin test user and a break-glass administrator account before binding it to the default flows. Keep a copy of the last working flow export.

Recovery flow bypasses MFA

A recovery or password reset flow that skips the MFA stage can let anyone who controls an email address reset a password and sign in without a second factor. Review every flow that ends in a session, not only the main login flow. Confirm that recovery requires the same factors as sign-in for protected applications, and test with an account that has MFA enrolled.

Expression policy denies access silently

An expression policy that raises an error or returns an unexpected value can deny access without a clear message to the user, and administrators may see failed logins with little context. Test each policy with expected users and edge cases, such as missing attributes or disabled groups. Review the event log entries that record policy results, and keep expressions short enough for a second reviewer to read.

Configuration drifts between environments

Changes made by hand in the admin interface exist only in one instance's database, so staging and production gradually diverge. Export flows, stages, policies, property mappings and brands, and keep those exports in version control. Apply them through the same pipeline in every environment, and allow manual production edits only as documented emergency changes. Confirm which export format your version supports.

Upgrade breaks flows and branding

A new release can change stage behavior, default flows or how brand assets are served, so custom flows and themes that worked on the previous version may fail after an upgrade. Read the release notes for each target version, and check that your target is on a supported line in the security policy. Test flows and branding on a copy of production before upgrading.

Design assumes enterprise features

Designs that rely on Google Workspace or Microsoft Entra ID integrations, mTLS client certificates, password history or enhanced audit logging may not work on Open Source, because the pricing page lists these as enterprise features. Check each required feature against the current edition list and the license terms for the enterprise code directory before the design is approved. Get the edition confirmed in writing.

How the work changes by starting point

A new Docker Compose deployment is the quickest place to shape flows and policies, but the vendor positions Compose for test setups and small-scale production, so the design should assume the configuration will move later.

Keep definitions in version control: Store flow, stage and policy definitions in a repository from the first session so a later move does not start from screenshots.
Size the host to the guide: The vendor guide calls for at least 2 CPU cores and 2 GB of RAM. Plan more if test traffic should resemble real login volume.
Own the database from day one: PostgreSQL runs alongside the other services on one host, so backup and restore testing is your responsibility from the start.
Define the exit trigger: Agree in advance which conditions, such as user count or uptime expectations, trigger a move to a managed database and a larger topology.

What the client needs to provide

Before any flow, stage or policy is changed, the client must provide access and decisions that the work cannot proceed without. The most important is admin access to a non-production authentik instance, plus access to every environment the configuration will later be promoted into. Confirm early who holds the superuser and admin roles, whether those accounts are protected by MFA, and how break-glass access will work during the build.

The client should also hand over the current login, enrollment and recovery procedures as they actually run today, including the help desk scripts, identity verification steps and any manual exceptions. Alongside these, supply the policy rules that security or compliance owners have approved, such as password requirements, MFA conditions, device or network restrictions and account lockout thresholds. Where those rules are not written down, the owners need to decide them before expression policies are drafted, because a policy that encodes an unapproved rule is a security defect, not a configuration detail.

Next, provide sample user populations and the source of each attribute the flows will read: directory exports, HR feeds, group memberships and any custom attributes used in property mappings. Include brand assets, approved color and typography guidelines, and the wording standards for error and recovery messages. Provide an inventory of applications and providers that will depend on these flows, with the protocol each one uses and the owner who signs off on changes to it.

Changes to authentication behavior must be approved in writing by the named security owner, and by the compliance owner where a control is in scope. The client should also name an operational owner who accepts releases into production and a business owner who decides on user-facing wording and enrollment rules. Agree these roles, and the approval path for each change type, before the first flow is edited. Confirm the exact approval steps and any change board requirements with your own governance process.

Frequently asked questions

What drives the cost and effort of authentik customization work?

The biggest drivers are how many flows you change, how many distinct login, enrollment and recovery paths exist, how many expression policies and property mappings must be written and tested, and how many applications depend on the outcome. Branding is usually the smallest factor, while identity rules tied to HR data, approvals or device checks add the most design and testing time. Each of these shows up as a line in the written scope, so ask for the quote to list the flows, stages and policies by name and to separate design, build, testing and handover. Figures follow from that scope, not from a general estimate.

How long does a customized authentik flow project usually take?

Duration depends on the number of flows, the stage logic inside them and how many test cases your user groups require. A project limited to branding and a single enrollment path is much shorter than one that rebuilds recovery, step-up MFA and conditional access across several applications. DeployOpen fixes the timeline in the written scope before work starts, so the schedule reflects the agreed deliverables. Ask for milestones tied to testing in a staging environment and for a clear handover date. No general duration is given here because none has been supplied for this topic.

Can our in-house team customize authentik flows without outside help?

Yes, a team with administrator experience in authentik and some Python or expression-language skills can build flows, stages and policies itself. The work that most often stalls internal teams is testing every path, including failed logins, expired recovery links and users in several groups, and keeping changes reproducible across environments. Decide whether you want that test and export discipline in-house, then compare it with the cost of a partner. DeployOpen can take on the whole build or review and harden a configuration your team has already written.

Do custom flows and policies require an enterprise license?

No. The authentik repository places most of the code under the MIT license, and flows, stages, policies, property mappings and branding are part of that core. The enterprise license applies to code in the authentik/enterprise/ directory, and the pricing page lists features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, password history and enhanced audit logging as enterprise-only. Confirm feature by feature against the current license file and pricing page before you design a flow that depends on one of them.

Do our customizations survive authentik upgrades?

Most flow and policy customizations carry forward, but each release can change stage behavior, default flows or expression context, so every upgrade needs a test pass against your own flows. Versions are named by year and month, and the security policy lists 2026.5.x and 2026.8.x as the supported release lines. Keep custom expressions and mappings in version control, keep a staging copy, and read the release notes before each step. The upgrade path is covered in its own planning, which includes breaking changes such as the Redis removal.

How do we keep authentik configuration reproducible across development, staging and production?

Treat flows, stages, policies, mappings and branding as code: export the configuration, store it in version control, and promote it through environments with a documented process rather than by hand in the admin interface. Keep secrets and environment-specific values outside the exported files so each environment injects its own. Verify each promotion with the same test cases used during the build. Ask for this promotion method, and the test suite that goes with it, to be named in the written scope.

How DeployOpen delivers authentik customization

DeployOpen plans and builds authentik flows, stages, policies, property mappings and branding inside your own infrastructure, then documents and hands over the configuration so it can be reproduced across environments. Engagements are fixed-scope, with ongoing support available as a retainer.

How we scope

Written scope lists each login, enrollment and recovery flow, the stages and policies it uses, and the applications it affects.
We map which custom expression policies and property mappings need to exist before any build starts.
Scope names the environments (for example test and production) where configuration must match, and how changes will be promoted between them.

How we build

Flows and stages are built and changed in a non-production instance first, with each change recorded in version-controlled configuration.
Expression policies and property mappings are tested against sample users and groups, including denied and edge-case paths.
Branding and template changes are reviewed in the browser flows users will actually see, across the login and recovery paths.

How we hand over

Handover includes exported flow and policy configuration, a description of each stage order and binding, and the promotion procedure.
Runbooks explain how to add a stage, change a policy, or roll back a flow without breaking sign-in for existing applications.
Your team receives the test cases used to verify login, enrollment and recovery, so checks can be repeated after future changes.

How we support

Ongoing support covers reviewing flow and policy changes before they reach production, available as a retainer.
Customizations are re-tested when authentik releases a new version, with the upgrade path confirmed against the supported release lines.
Confirm with DeployOpen what your support agreement covers, response expectations and who approves changes to production flows.

authentik customization: flows, stages and policies