Planning your authentik 2026.2 upgrade on the supported path
The 2026.2 upgrade changes how SCIM providers choose users and groups, so review every SCIM provider before cutover. If your self-managed authentik pushes users to SaaS or internal applications over SCIM, the provider may stop sending the same accounts after the upgrade. Starting with 2026.2, a SCIM provider filters users by the policies bound to its application, and when you select groups it syncs only those groups; otherwise it syncs all groups. Confirm the exact behavior against the authentik 2026.2 release notes before you schedule the change.
Upgrades should follow the sequential rule, so confirm the upgrade path from your current version to 2026.2 in those release notes rather than assuming a shortcut. The authentik security policy lists the 2026.5.x and 2026.8.x lines as the supported versions receiving security fixes, so a deployment that stays on an older line will fall out of security coverage. Also check the release notes for your current version, since each intermediate release can carry its own migrations and breaking changes.
Plan the window around the review, not the container swap. Export the SCIM provider configuration, list each application's bound policies and any group filters, and ask the target application's owner which accounts and groups must keep provisioning. Expect a configuration warning for any SCIM provider that still carries an old group filter and is deactivated for review. Keep a tested PostgreSQL backup before the upgrade, and ask your team to confirm who signs off on provisioning results after cutover.
Which 2026.2 changes affect your identity flows
This table lists each authentik 2026.2 change that touches SCIM provisioning, group access or the release process, with the impact to check and the action to take before upgrading. Read each row against your own SCIM applications, custom code and patch planning, and treat the action column as the review list for your change window.
| Change in 2026.2 | Impact to check | Action to take |
|---|---|---|
| SCIM users filtered by application policies | Users reaching a SCIM target may differ from before if the application's policy bindings change which users are selected. | Confirm the policy bindings on each SCIM application and test with a sample user set before enabling sync. |
| SCIM sync limited to selected groups when groups are chosen, otherwise all groups | If a provider has no group selection, it syncs all groups. If groups are selected, only those groups sync. | Record each provider's group selection now and decide whether the target should receive every group or a defined subset. |
| SCIM providers with an old group filter deactivated with a configuration warning | Providers carrying an old group filter are deactivated after the upgrade and show a configuration warning for review. | Review every warning in the admin interface, rebuild the group selection as needed, then reactivate and verify provisioning. |
| User.ak_groups deprecated in favor of User.groups | Custom code, blueprints, expressions or scripts that read User.ak_groups still run for now but should be reviewed for the replacement. | Search custom code and configuration for ak_groups, switch references to User.groups, and test those paths in staging. |
| Release cadence moving from about two months to about three months, with security coverage for the two most recent versions | Fewer releases per year and security fixes covered only for the two most recent versions change how long a deployment can stay on one version. | Set a patch calendar that fits the three-month cadence, and plan upgrades so your deployment stays on a supported version. |
What to inventory and back up before 2026.2
Most of the 2026.2 risk sits in configuration that the upgrade reads but does not warn about in advance. Work through these six items before changing any image tag, so that a restore point exists and every SCIM provider, custom reference and environment is accounted for.
Back up PostgreSQL and uploaded files
PostgreSQL stores all authentik configuration and data except uploaded files, so a database dump alone does not cover everything. Take a logical backup of the database and separately copy the location where uploaded files live, such as branding assets. Confirm you can restore both to a scratch host and that the authentik server starts against the restored data before you rely on the backup.
Inventory SCIM providers and group filters
List every SCIM provider, the application it serves and the group filter it uses. Under 2026.2, a SCIM provider with an old group filter is deactivated with a configuration warning, so a provider you do not review can silently stop syncing. Record which providers select specific groups and which sync all groups, because the two behave differently after the upgrade.
Map application policy bindings
Under 2026.2, a SCIM provider filters users by the policies bound to its application. Export the policy bindings for each SCIM-connected application and note which users currently pass them. Users outside those bindings may stop being provisioned to the downstream system, which can look like data loss in the target application if nobody expected it.
Search custom code for ak_groups
Search custom code, blueprints, scripts and API clients for references to ak_groups on the User object. The 2026.2 release deprecates this field in favor of groups. Include CI pipelines, internal dashboards and reporting jobs, since a deprecated field can keep working for a while and then fail in a path nobody tested.
Confirm a staging environment matches production
Rehearse the upgrade on a staging instance built from a recent production backup, with the same PostgreSQL version, configuration and connected applications. Confirm that SCIM syncs, group membership and login flows produce the same results before and after. Staging that differs in group data or policy bindings will not show the 2026.2 changes you need to catch.
Record deployment method and image tags
Confirm whether your instance runs on Docker Compose or Helm, and record the exact image tags for the server and worker containers and any outposts. The upgrade changes the version in several places, so a mismatched tag on one component is easy to miss. Keep the current tags written down so the rollback path is clear if the upgrade has to be reversed.
How SCIM sync decides which users and groups to send
Starting with authentik 2026.2, a SCIM provider decides which users to send by the policies bound to the application it serves. Users who pass those application policies are the ones the provider considers for provisioning, so the policy bindings on the application now define the user set directly. Before you upgrade, list every application that uses a SCIM provider and record which policies are bound to it, because a binding you did not expect will change who gets created or updated in the target system. Treat the policy bindings as the first thing to review, not the group filter.
Group selection follows a simpler rule. If you choose specific groups on the provider, only members of those selected groups are synced. If you choose no groups, the provider syncs all groups. This is a change for providers that relied on an old group filter. authentik 2026.2 deactivates those SCIM providers and raises a configuration warning so an administrator reviews them before they run again. Do not reactivate a provider until you have decided whether its groups should be explicitly selected, whether its application policies still match the intended users, and whether any group that used to be included is now missing.
Confirm the expected user and group sets in a staging environment before you enable the provider in production. Export or list the users the target system currently holds, run the provider against a staging copy of the directory, and compare the results with what the old filter produced. Pay particular attention to users who were previously included only through group membership and now depend on an application policy, and to nested or empty groups. Document the expected sets in your change record so the auditors and application owners can see what was approved. The release notes describe the behavior, but your directory, policies and target application determine the actual result.
Upgrade sequence with checks and rollback points
This sequence moves an authentik deployment to 2026.2 without surprises in SCIM provisioning or group-based access. Each step names a check that must pass and a rollback point, so the team knows when to proceed and when to stop.
Confirm current version and sequential path
The platform team records the running authentik version on the server and worker containers, then confirms that every intermediate release between that version and 2026.2 has been applied in order. Do not jump directly across several releases. If the deployment is more than one release behind, follow the catch-up path first and treat 2026.2 as the final step. Done when the team has a written version record and a list of releases still to apply. Rollback point: none needed, because this step changes nothing.
Back up PostgreSQL and media before any change
The database owner takes a full PostgreSQL backup, and the team copies the media directory and the deployment configuration files, including environment settings and reverse proxy configuration. PostgreSQL holds all configuration and data except uploaded files, so the database backup is the core restore point, and the media copy covers the files it does not hold. Verify that the backup restores to a scratch environment before continuing. Done when a restore test has completed and the backup location is recorded. Rollback point: this backup is the restore source for every later step, since the team restores from backup rather than downgrading.
Inventory SCIM providers and ak_groups usage
The identity administrator lists every SCIM provider, the applications each one is bound to, and whether it uses a group filter. The developer team searches custom code, scripts, policies, and integrations for references to the User ak_groups attribute, which 2026.2 deprecates in favor of User groups. Record each provider with its owner, target application, and the expected user and group population. Done when the inventory is signed off by the application owners and every ak_groups reference has an owner and a fix planned. Rollback point: none, because this step is read-only.
Upgrade staging and compare SCIM user and group sets
The team applies 2026.2 to a staging copy restored from the production backup, with the server and worker updated together. After the upgrade, they compare the users and groups that each SCIM provider now selects with the sets recorded in the inventory. Under 2026.2, providers filter users by the policies bound to their application, and they sync only selected groups when groups are chosen, or all groups otherwise. Differences in either direction must be explained before going further. Done when each provider's staging set matches the expected set or each difference has a documented decision. Rollback point: discard the staging copy and restore it from the backup if the comparison cannot be reconciled.
Resolve configuration warnings and deactivated providers
Providers that still carry an old group filter are deactivated with a configuration warning for review. The administrator opens each warning in staging, decides whether the filter should become a group selection, an application policy binding, or be removed, and records the decision. Re-enable each provider only after its user and group set has been confirmed. Done when no provider remains deactivated without a recorded owner and decision, and no configuration warnings are left open. Rollback point: a provider that was never re-enabled keeps its previous configuration, so the team can revert that single change in the database restore.
Upgrade production server and worker together
During an agreed maintenance window, the operator stops background provisioning, takes a fresh database backup, and updates the server and worker containers to the same 2026.2 version. Running mismatched server and worker versions is a risk the team should avoid, so both images change in one step. Confirm that the containers start, that migrations complete without errors, and that the admin interface loads. Done when both containers report the target version and the logs show a clean start. Rollback point: if migrations fail or the stack is unstable, restore the pre-upgrade database backup and the previous container images rather than attempting a downgrade of the database.
Verify SCIM pushes and logins
The operator triggers a sync for each re-enabled SCIM provider and checks the results against the staging comparison. Representative users from each application sign in through their normal flow, and the team confirms that application access follows the policy and group bindings. Monitor the worker logs and the provider sync status for errors over the first sync cycles. Done when every provider completes a push with the expected user and group set and a sample of logins succeeds for each application. Rollback point: if provisioning or sign-in fails for an application, pause that provider and restore the database backup if the fault cannot be corrected forward.
Plan production cutover and closeout
Before the next change window, the team writes a cutover plan that lists the approved upgrade time, the owners on call, the verification checks from earlier steps, and the restore procedure with its expected duration as measured in staging. They also record that 2026.2 moves authentik to a three-month release cycle, with security coverage for the two most recent versions, so the team should plan the next upgrade against that cadence. Done when the plan is approved and the closeout note records the final versions, backup locations, and open follow-ups for ak_groups code changes.
What makes this upgrade take longer
This table lists the factors that stretch or shorten an authentik 2026.2 upgrade, with what to confirm for each. Read it against your own estate: the rows that score high for you are where the planning time will go. Most of the effort sits in SCIM provider review and custom code that still reads the deprecated group attribute.
| Effort driver | Why it changes the work | What to confirm |
|---|---|---|
| SCIM providers and applications | Each SCIM provider is re-checked for its application policy bindings and group selection, and any provider with an old group filter is deactivated until someone reviews it. | How many SCIM providers exist, which applications they feed, and whether each one has group selection set. |
| Group structure size and complexity | Large or nested group trees make it harder to predict which users a provider will now sync, and group-based access may shift after the change. | Group counts, nesting depth, and which groups are used for application access versus provisioning. |
| Custom code using ak_groups | User.ak_groups is deprecated in favor of User.groups, so scripts, policies, blueprints or integrations that read the old attribute need changes and retesting. | Where ak_groups appears in your code, blueprints, expression policies and external tools, and who owns each piece. |
| Integrations and outposts to align | Outposts and integrations should run the same version as the core, so each one adds a version change and a verification step. | Count of LDAP, RADIUS, proxy and RAC outposts, and which integrations depend on group membership. |
| PostgreSQL data size and backup window | A verified backup is the rollback path, so a larger database lengthens the backup, restore test and maintenance window. | Current database size, measured backup and restore duration, and the maintenance window your change process allows. |
| Availability requirements | Users who depend on sign-in cannot be interrupted freely, which pushes work toward staged rollouts or a separate test instance. | Acceptable downtime, sign-in dependency for each application, and whether a parallel staging instance exists. |
| Testing depth required by change control | Regulated change processes often require documented test cases, sign-off and evidence of group access before and after the upgrade. | Required test evidence, approval steps, and whether group access checks must be recorded for auditors. |
Common questions before upgrading to 2026.2
What does an authentik 2026.2 upgrade cost, and who pays for what?
The cost is mostly labor, and it splits into two parts: your internal time and any partner fees for a fixed-scope engagement. Internal time covers reading the 2026.2 release notes, reviewing every SCIM provider and custom script, taking a backup, running the upgrade in a non-production copy, and checking sign-in afterward. A partner engagement is priced from a written scope that lists the environments, the number of providers and integrations, custom code to review, and the verification you require. The one-time work is the upgrade and its testing. Recurring costs come from running the platform afterward, such as patching and the more frequent releases described below. Ask any provider to itemize these components. DeployOpen does not publish prices, so a quote follows from the scope you agree in writing.
How long does an authentik 2026.2 upgrade take?
Duration depends on how much of your configuration the 2026.2 changes touch, not on the release itself. The main drivers are the number of SCIM providers, whether each one has an old group filter that will now deactivate, how many custom scripts or integrations read ak_groups, the size of your user and group base, and how many environments you must step through before production. Deployment method matters too: a Docker Compose stack and a Kubernetes install with a separately managed PostgreSQL differ in the rollout steps. Ask for the duration to be tied to a written list of providers, integrations and environments, and check whether the timeline includes a rehearsal in a staging copy.
What does the upgrade need from our team?
Your team needs to supply four things. First, a person who knows which applications use each SCIM provider and which application policies control access to them. Second, a list of custom code, automation and reports that reads User.ak_groups. Third, access to the production and staging authentik instances, database backups and deployment files. Fourth, a sign-off owner who decides which users and groups should keep access after the change. Plan time for those people in the schedule, because the group access decisions cannot be made by the upgrade engineer alone.
Can our team upgrade authentik to 2026.2 without outside help?
Yes, a team that already runs authentik in a non-production copy and has someone comfortable with its APIs can often do the upgrade itself. The work is well defined: the release notes list the changes, and you can test each one. Outside help makes most sense when no one has tested a restore, when many SCIM providers or custom integrations are in use, or when you need an independent record of what changed for a compliance review. Confirm the scope of any engagement in writing, including what is tested and handed over.
What happens to a SCIM provider that still has an old group filter?
According to the authentik 2026.2 release notes, a SCIM provider with an old group filter is deactivated and flagged with a configuration warning for review. Its sync stops until someone checks it. The 2026.2 model filters users by the policies bound to the application, and when groups are selected, the provider syncs only those groups. Before upgrading, list each SCIM provider, its selected groups and the application policies on its application, then decide which groups should still sync. After upgrading, confirm that each provider is active, that the warning is cleared, and that the target system receives the expected users and groups. Read the authentik 2026.2 release notes before changing the filters.
How should we handle the ak_groups deprecation in custom code?
Search your scripts, policy expressions, reports, and external tools for ak_groups and replace each use with groups, which is the field the 2026.2 release notes point to as the successor to User.ak_groups. Treat this as a code change with tests, not a find-and-replace. Check that the new field returns the same membership your code expects, because group relationships in authentik can differ from what older scripts assumed. Run each changed script against staging data and keep the deprecated name only until the replacement is verified. Record each change so a reviewer can trace it.
What does the move to a three-month release cycle mean for our planning?
The 2026.2 release notes announce a move from roughly two-month releases to three-month releases, and state that security coverage will continue for the two most recent versions. Your planning should assume a minor version becomes unsupported sooner than your change calendar may allow, so you need a repeatable upgrade routine rather than an occasional project. The authentik security policy lists the currently supported versions and says security releases are announced at least 24 hours in advance, so subscribe to that notice and set a standing window for review. Check the authentik security policy for the current supported list before each planning cycle.
What the three-month release cycle changes for planning
The 2026.2 release notes announce that authentik is moving from releases roughly two months apart to a three-month cycle, and that security coverage will apply to the two most recent versions. For planning, this means a deployment can fall out of security coverage sooner than the release calendar suggests if upgrades wait for a convenient window. Record which release line each environment runs, including test and staging, so that the team can see how far behind production is before a support gap appears.
The authentik security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, so any deployment on an older line is outside that coverage. Security releases are announced at least 24 hours in advance, which is a short lead time for a production identity provider that signs users into other systems. Plan a standing change path that can take a security patch within a day: a staging rehearsal, a confirmed backup, and a named approver who can authorize the change without convening a full change board.
The policy page is the authority on which lines are supported, so check it on the day you schedule work instead of relying on an earlier plan. Confirm the current latest release on the GitHub releases page as well, since the latest release at the time of writing was 2026.8.4, published October 14, 2026. A deployment still on 2026.2 should be treated as needing a move to a supported line, and the path to get there should be checked against the sequential upgrade guidance before any change is scheduled.
How DeployOpen scopes and delivers an authentik upgrade
DeployOpen treats the authentik 2026.2 upgrade as a planned change to how SCIM provisioning and group access behave, not only a version bump. We start from your current SCIM providers, group filters and custom code, then agree in writing what gets changed, tested and handed over.
How we scope
- Inventory every SCIM provider, its application policy bindings and whether it uses an old group filter.
- Identify custom code, scripts and integrations that read User.ak_groups and need moving to User.groups.
- Agree in writing which environments, providers and deliverables the fixed-scope engagement covers, with timelines confirmed before work starts.
How we build
- Run the upgrade first in a non-production copy, reviewing each SCIM provider flagged with a configuration warning.
- Compare which users and groups each SCIM provider sends before and after the change, so access shifts are visible.
- Update custom code to User.groups and test the results against the group membership you expect.
How we hand over
- Document each SCIM provider's final group selection and application policy bindings with the reason for each change.
- Provide a record of the test runs, the configuration warnings reviewed and the decisions your team approved.
- Walk your team through the three-month release cycle and the security coverage for the two most recent versions.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- Use the retainer to plan the next authentik release against the security policy and the release calendar.
- Ask us to confirm the scope, deliverables and support terms in writing before any work begins.
