How scheduled user offboarding in authentik closes the gap after a leaver's last day
HR usually knows a leaver's last day weeks in advance, yet account access often stays live until someone remembers to act on the ticket. authentik 2026.8 adds Enterprise scheduled user offboarding, which lets an administrator set a user to be deactivated or deleted at a chosen date and time, with an option to revoke that user's sessions and tokens when it runs. The scheduled action can be reviewed or cancelled before it executes, and the outcome is recorded in the event log. The Enterprise features page lists this capability as a preview feature, so confirm its current status and its licensing terms with authentik before you make it a control your auditors will rely on.
Teams need this when leavers are processed in batches, when offboarding tickets are handled across time zones, or when a manager asks for access to end at a specific moment rather than at the next admin shift. It is most useful as a backstop: the scheduled action makes the authentik identity stop working on time, even if the ticket is late. It does not replace the rest of the leaver process. Application-side accounts that authentik does not manage, group and role memberships that may need separate cleanup, and devices or local credentials that sit outside the identity provider all still need their own steps. Map each of these to an owner and a checklist item before you rely on the scheduled action alone.
Before go-live, confirm three points with your own tests in a non-production tenant: whether revocation covers every session and token type your applications use, what happens to downstream accounts that depend on the deactivated user, and how the event log entry reads when an auditor asks who scheduled the action and who cancelled it. Document the answers in your joiner, mover and leaver procedure so the evidence trail is clear from the first leaver onward.
Deactivate or delete, and whether to revoke sessions and tokens
This table compares deactivation with deletion, and revoking sessions and tokens with leaving them in place, across audit, recovery and downstream effects. Read each row as a decision: the technical default is usually clear, but the final setting for retention and recovery should follow your written retention policy.
| Choice | Deactivate (keep the account) | Delete (remove the account) |
|---|---|---|
| Audit trail for the leaver | Account and its history remain in authentik, so event log entries can be tied back to the same user record. | The user record is removed. Confirm how your event log retains entries that reference a deleted user before relying on it as evidence. |
| Recovery if the date was wrong | Reactivating the account restores sign-in, but group memberships and assignments may need checking after the change. | Recovery means recreating the user and re-establishing memberships, assignments and any identifiers applications depend on. Treat it as a new account. |
| Downstream applications | Applications that hold the user's record locally may keep it, so confirm how each app handles a disabled identity. | Applications keyed to the user's identifier or pushed by provisioning may see a removal event. Test deletion against each connected app first. |
| Revoking active sessions | Revoking sessions ends current logins immediately. Confirm which sessions the scheduled run covers in your version. | Deleting a user also ends its sessions, but confirm the event log still records the revocation for your evidence. |
| Revoking API tokens | Revoking tokens stops scripts and integrations acting for the leaver. Check which token types your deployment issues. | Token removal follows deletion, but confirm any long-lived credentials held by downstream systems are rotated separately. |
| Leaving sessions and tokens in place | Faster to schedule, but a leaver may keep access through an open browser session or a live token until it expires. | Same exposure risk as deactivation without revocation. Acceptable only where your policy accepts a defined residual window. |
| Who decides | Your retention policy and HR records determine whether accounts must be kept for a period before any deletion. | Legal hold, record retention periods and the rules for regulated data decide whether deletion is allowed on a set date. |
| Evidence for an assessor | Scheduled entry, review, run result and event log record show the control operated on the planned date. | Deletion evidence depends on what the event log keeps after removal. Confirm this with your auditor before choosing deletion as the default. |
Setting up scheduled offboarding for leavers
This sequence confirms the platform version and licensing, defines where leaver dates come from, and proves that a scheduled deactivation or deletion runs, can be reviewed or cancelled, and leaves a usable audit trail with session and token revocation.
Confirm version and Enterprise licensing
Confirm that the authentik instance runs version 2026.8 or later and that it holds an Enterprise license that covers scheduled user offboarding. The feature is listed among Enterprise capabilities in the release notes for 2026.8, so an Open Source or lower-tier deployment cannot use it. Check the version in the admin interface and record the license status with the person who owns the subscription. The step is done when the version and license are written in the change record for the offboarding control.
Confirm preview status with the vendor
Ask authentik whether scheduled user offboarding is still listed as a preview feature in the Enterprise features documentation for your version, and whether the vendor considers it suitable for production leaver processes. Ask what behavior changes are planned for later releases and how the vendor announces breaking changes. Record the answers, the date you asked, and the name of the person who replied. Your control owner should accept that status in writing before the feature is used for real leavers, or keep manual deactivation as the primary process.
Define the leaver date source
Decide which system is the source of truth for leaver dates, usually the HR system, and how that date reaches authentik. Options include a manual entry by a designated administrator, a field copied from HR records, or an export that the identity team reviews before scheduling. Document who may create a schedule, who approves it, and what happens when HR changes a date after scheduling. Confirm the exact field names, time zone handling, and the format each system uses. The step is done when the rule is written down and an HR owner has agreed to it.
Schedule a test user
In a non-production or dedicated test tenant, create a test user with a test application assignment and a group membership that matches a real leaver profile. Schedule deactivation for that user at a date and time a short distance ahead, choose whether to revoke sessions and tokens, and select deactivation rather than deletion for the first run. Record the schedule identifier and the exact time it is set to run. The step is done when the scheduled item appears in the admin interface with the expected user, action, and time.
Review and cancel a second schedule
Create a second test user and schedule an offboarding action for it. Open the review view, confirm that the user, action, time, and revocation options match what you entered, and then cancel the schedule before it runs. Check that the user remains active, keeps its sessions, and that a cancellation entry is written to the event log. This proves that a mistaken leaver date can be stopped. The step is done when the cancelled schedule shows the expected state and the user is unchanged.
Let a second test run complete
Create a third test user with an active session and an issued token, then schedule its offboarding. Leave the schedule in place and allow the run to complete without intervention. Watch the scheduled item change state and confirm whether the run finished successfully or reported a failure. If the run fails, note the error, check whether the platform retries, and do not assume a retry happened without evidence in the record. The step is done when the run has a final state recorded for the test user.
Verify event log entries
Open the event log and filter for the test user and the schedule identifier. Confirm that entries exist for scheduling, review or cancellation, and execution, and that each entry shows the time, the actor, and the outcome. Export or copy these entries into the evidence folder for the control. Check that your SIEM or log forwarding receives the same events if you rely on central retention. The step is done when the entries for each test action are present and can be exported.
Verify revocation on session and token
Using the third test user, confirm that the session active before the run no longer works after the run, and that the token issued earlier is rejected by the application or by the introspection endpoint you use. Test with a real application client, not only the admin view. Record the time of the last successful request and the first rejected request. If revocation does not take effect, record the gap and block production use until the cause is understood. The step is done when both the session and the token are shown to be revoked, and the results are filed with the event log evidence.
Risks in scheduled offboarding that auditors and attackers both test
Scheduled offboarding removes a leaver's access on a set date, but the schedule is only as good as the date, the retention decision and the evidence behind it. The cards below cover the failure points that auditors sample and attackers look for, and the checks that show each one is controlled.
Wrong dates from HR feeds
A leaver date copied incorrectly from an HR export, or a date entered in the wrong time zone, can deactivate an active employee or leave a leaver connected for days. Before go-live, compare a sample of scheduled dates against signed HR records and confirm who approves each batch. Review the schedule for dates that are in the past, far in the future or clustered on a single day, since those patterns often signal a data problem rather than real departures.
Deletion without a retention decision
A leaver scheduled for deletion loses the account record that audit trails, ticket history and access reviews may reference. Decide per role or region whether the account should be deactivated for a retention period or deleted outright, and record that choice before scheduling deletion. Confirm with your legal and records team how long leaver identity data must be kept, because that answer, not the offboarding tool, sets the rule.
Sessions that outlive deactivation
Deactivating a user stops new sign-ins, but an existing session or token in a connected application can keep working until it expires. Enable session and token revocation in the schedule where the option fits your policy, then test with a real leaver account in each high-risk application. Check that revocation reaches the applications you actually sign users into, not only authentik itself.
Unmanaged service tokens
API tokens, app passwords and agent credentials tied to a leaver can outlive the person who created them and keep reaching systems. Inventory the tokens and automation that belong to each user before the schedule runs, and assign an owner or a rotation step for anything that must continue. Ask whether revocation covers the token types your teams use, and test that a revoked token fails.
Cancellations without a record
A reviewer who cancels a pending offboarding run can stop a deactivation that a manager requested, or cancel a run that was never justified, and no one notices. Require a named reviewer, a reason for each cancellation and a periodic check of cancelled runs against HR records. Confirm in the event log that cancellations, reschedules and reviews each leave an entry that a second person can query.
Event log gaps for auditors
Auditors test whether each leaver was removed on time and whether the removal can be shown after the fact. Scheduled actions, executions, failures and retries should all appear in the event log, and that log should be forwarded to storage you control. Enterprise audit logging is listed as an Enterprise feature on the authentik pricing page, so confirm that your edition includes the log detail your auditors will request.
Retries, failures and proving the leaver control worked
The supplied material confirms that scheduled offboarding records its results in the event log, but it does not describe what happens when a scheduled run fails, partially completes or is retried. Before you rely on this feature for leavers, confirm those behaviors in your own environment with a test account. Ask the authentik team or check the authentik 2026.8 release notes for each question: if a deactivation fails partway, does the run stop or continue, is it retried automatically, and how many times? Does a failed session or token revocation leave the account deactivated with live sessions still valid? Can an administrator re-run a failed job without creating duplicate entries? Write the answers into your runbook, because the answer determines whether your manual fallback is a checklist for the whole leaver or only for the step that failed.
Build the evidence from the event log, not from memory of what the administrator intended. For each leaver, you should be able to point to a scheduled entry showing who created the offboarding, the target account, the effective date and whether sessions and tokens were to be revoked; a reviewed entry if someone checked it; a cancelled entry if the request was withdrawn, such as a rehire or an HR correction; an executed entry showing deactivation or deletion; and revoked entries for sessions and tokens. Export or reference these records and keep them with the HR ticket that authorized the leaver, so the HR date, the approval and the system action can be matched on one trail. Check that a test run produces every entry you expect, and that a missing entry is treated as a failed control, not a gap to explain later.
This section prepares evidence for a joiner, mover and leaver control. It does not establish that the control is operating effectively, and it is not an audit opinion. Independent auditors decide whether your design and operating evidence meet the criteria they apply. Your job is to show a complete trail for a sample of leavers, to show what you did when a run failed, and to name the owner who reviews exceptions. Because scheduled user offboarding is listed as a preview feature in the authentik Enterprise features documentation, also decide whether your leaver process can fall back to a documented manual step if the feature changes or is unavailable.
Limits to confirm before you rely on scheduled offboarding
Scheduled offboarding in authentik 2026.8 is useful for leavers, but it sits on top of several limits you should confirm before it becomes a control. The cards below cover the feature's maturity, licensing, external accounts, and what happens downstream once the account is disabled or removed.
Preview status and stability
authentik lists scheduled user offboarding as a preview feature on its Enterprise features page. Ask authentik how the feature is expected to change before general availability, which upgrade notes apply, and whether any known defects affect scheduling, cancellation or retries. Pilot the feature on a non-production instance running the version you plan to deploy, and record the behavior you observe so your change record reflects the feature as tested.
Enterprise license scope
Scheduled offboarding is an Enterprise capability, and code under the enterprise directory is covered by a separate license from the MIT-licensed core. Confirm with authentik which license terms and subscription tier cover this feature, how many users the subscription counts, and whether external users are billed separately. Keep the license decision with the same owner who approves the leaver control, so the feature is not lost at renewal.
Behavior for external users
Your leaver population may include contractors and external accounts that are not billed or managed like employees. Test how scheduled deactivation or deletion treats these accounts, whether they can be scheduled from the same HR-driven source, and whether session and token revocation applies to them. Document any population that must be handled manually until the behavior is confirmed.
Downstream deprovisioning in applications
Disabling the authentik user stops new sign-ins, but it does not prove that every application removed access. Determine which applications receive account changes through SCIM or another provisioning path, and which keep local accounts that need a manual disable step. Build a per-application checklist with an owner and evidence for each one, and test a leaver end to end against each application type you run.
Group and role removal
Offboarding should also remove group memberships and role assignments that grant access, so a reactivated or recreated account does not inherit old rights. Confirm whether the scheduled action changes group and role membership or only the account state. If it does not, define a separate step that removes these links and capture it in the same evidence record.
Revocation coverage by provider type
Session and token revocation may not reach every provider type with the same effect. Test OAuth2/OIDC, SAML, LDAP, proxy, RADIUS, RAC and SCIM-connected applications separately, and check whether already-issued tokens stop working, whether SAML sessions end, and whether LDAP or RADIUS clients lose access on the next bind. Record the results per provider so you know which applications need additional revocation at the application level.
Questions buyers ask before scheduling leaver offboarding
Is scheduled user offboarding included in the free authentik edition?
No. Scheduled user offboarding is an Enterprise feature in authentik 2026.8, and the Enterprise features documentation lists it as a preview feature. The authentik pricing page lists three editions: Open Source (free, with community Discord support only), Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Confirm the current price and which edition covers the feature on the pricing page before you budget, because the feature list and preview status can change between releases. Also confirm whether your user count includes external users, since that changes the monthly figure.
What drives the cost of scheduled leaver offboarding?
The cost has three parts. First, licensing: the Enterprise per-user price applies on the authentik side and recurs for as long as you run the feature. Second, one-time integration work: connecting your HR system's termination dates to authentik, mapping the fields, and agreeing how rehires and date changes are handled. Third, testing and evidence design: deciding which events, sessions and tokens must be revoked, proving the behavior in a non-production environment, and defining what the event log must show for an auditor. Costs rise with the number of HR sources, the number of applications with their own sessions or tokens, and the number of approval or exception paths. Ask any partner for a fixed-scope quote that lists these three parts separately.
How long does it take to schedule leaver offboarding?
The duration depends on your HR integration, not on the offboarding feature itself. A team that already has clean termination dates in an HR system and a working authentik deployment will spend most of the time on mapping, testing revocation against each connected application, and agreeing the review step. A team that must first build a data feed from HR, or clean up dates and duplicate identities, will need longer. No duration is set for this work in the supplied facts, so ask for a timeline in the written scope and confirm the dependencies that could move it, such as HR access, change windows and application owner availability.
What must we provide before offboarding can be scheduled?
Four inputs are needed before work starts:
- The HR source of truth for termination dates, with the field names, time zone and who maintains the date.
- Retention rules that say whether leavers are deactivated, deleted, or deactivated first and deleted after a defined period.
- A named owner for each application that holds its own session or token, so you can confirm revocation works for that app.
- Approval rules for changing or cancelling a scheduled action, including who may review it before it runs.
If any of these is missing, the scope should record it as an open decision, because each one changes what the schedule does.
Can our internal team set up leaver offboarding without a partner?
Yes, if your team already runs authentik in production, has someone comfortable with its APIs or blueprints, holds an Enterprise license, and can take ownership of the HR feed. The harder parts are rarely the authentik settings. They are agreeing the retention policy, proving revocation for each application, and building the evidence that an audit will ask for. Teams that have not done this before often underestimate testing across applications with long-lived tokens. Decide early which of these your team will own, and which you would hand to a partner under a fixed-scope agreement.
How do we prove that leavers were offboarded on time?
authentik records the results of scheduled offboarding in its event log, which is the primary evidence source. Your evidence design should define which events you export, how long you retain them, who reviews them, and how you match a leaver's HR termination date to the logged deactivation or deletion. Add a test record that shows sessions and tokens were revoked, not only that the account was disabled. Map the resulting evidence to your own joiner, mover and leaver control, and confirm with your auditor which artifacts they accept. DeployOpen prepares systems, controls and evidence for compliance assessments, but auditors and certification bodies issue the reports.
What goes wrong when a scheduled offboarding fails or is cancelled?
The common failures are a wrong or late HR date, an account that is cancelled after the review window, a rehire whose old schedule still runs, and a session or token that survives because the application caches it. Plan for each one. Confirm how a failed run is retried and how an operator is alerted. Test a cancellation and a date change in staging. Check that the event log records the failure and the retry, so a missed leaver is visible rather than silent. Keep a manual deactivation procedure for urgent exits, since a scheduled run cannot cover a same-day termination.
Is there a support plan for scheduled offboarding after go-live?
Support depends on two separate agreements. The authentik edition determines what the vendor provides: the Open Source edition offers community Discord support only, while Enterprise includes ticket-based support for subscriptions over $1k, and Enterprise Plus adds dedicated support with SLAs. Separately, DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask for a written list of what happens when an HR feed changes, when a new application is connected, and when authentik releases a version that changes this feature. Confirm which versions receive security fixes before you schedule an upgrade.
How DeployOpen scopes and delivers leaver controls in authentik
DeployOpen plans and implements scheduled leaver controls under a fixed written scope, agreed before work starts. The scope names which HR dates feed the schedule, which account states the schedule may set (deactivation or deletion), whether sessions and tokens are revoked at the same time, and which users, groups or sources are excluded. Because the feature is listed as a preview on authentik's Enterprise features page, the scope also records the Enterprise license dependency and the version the client will run, so the agreed behavior is tied to a specific release rather than to general assumptions.
The delivery work covers HR date mapping, a set of supervised test runs and the design of event log evidence. Test runs use non-production users to confirm that a scheduled deactivation takes effect at the right time, that sessions and tokens are revoked as configured, that a review or cancellation step behaves as the client's process expects, and that failures are visible to the team that must act on them. The evidence design defines which event log entries the client's controls owner will retrieve, how they are retained and forwarded, and how a leaver's record links back to the HR request that triggered it. DeployOpen prepares these systems, controls and records for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
Ongoing support, upgrades and continuous testing are available as retainers, which suit clients who want the schedule checked after each authentik release. DeployOpen does not publish a price list. A quote follows from the written scope, so the reader should ask for the HR integration points, test environments, evidence deliverables and handover items to be listed separately, along with which of them are one-time and which recur.
