How authentik access requests fit a just-in-time access model
Standing access is the default most organizations inherit, and it outlives the work that justified it. A contractor added to an application for a migration project keeps the role after the project closes, and an engineer who needed a database entitlement for one incident keeps it indefinitely because nobody owns the removal. Approvals for these exceptions often happen in email threads that are hard to find during an audit. authentik 2026.8 adds Enterprise privileged access management to address this pattern: users request access to applications and entitlements, approvers approve or deny the request, approved access expires automatically, and every action is recorded in the event log. Under a just-in-time model, the question shifts from who can ever reach this application to who may reach it now, for how long, and on whose authority.
Before you design around this feature, confirm three things with authentik and your own licensing. The Enterprise features page lists privileged access management as a preview feature, so check the current status, supported behavior and any preview limitations against the authentik Enterprise features documentation before you commit it to a control. The capability requires Enterprise licensing, which is a recurring cost to scope alongside your open-source deployment. Also confirm which request rule types, reviewer configurations and expiration limits your target release supports, using the authentik 2026.8 release notes as the starting point.
The practical decision is which applications and entitlements move from standing assignment to request-based access first. Start with high-impact or infrequently used access, such as administrative roles in production tools, where a time-limited grant removes the most risk for the least user friction. Map each one to an owner who can name reviewers, a maximum duration that matches the work, and an audit owner who will read the event log. Test the full cycle in a non-production instance: request, approval, expiry, and manual revocation. Record what you observe, because that test result becomes the evidence your reviewers and auditors will ask for.
Which request rule settings fit which governance need
This table compares the request rule settings in authentik access requests, from who approves to how long access lasts, and what each choice trades between approval speed and control. Read each row as a governance need, then check the matching setting and the trade-off before you fix the rule design. The main takeaway is that stricter reviewer rules and shorter expiry windows slow requests down, so set them by the risk of each application or entitlement.
| Setting | When it fits | Trade-off for speed versus control |
|---|---|---|
| Approval by users | Small, named set of owners who know the application, such as an application owner approving their own system | Fast when the named approver is available, but a single absent approver can stall requests and concentrates trust in few people |
| Approval by groups | Teams with a standing reviewer pool, such as a platform on-call group handling production database access | Spreads review across people and survives staff changes, but group membership must be kept accurate or the wrong people can approve |
| Approval by policies | Rules that depend on request attributes, such as routing high-risk entitlements to a stricter approver set | Lets approval follow conditions without manual routing, but policy logic needs testing and review as it changes |
| Minimum reviewer counts | High-impact entitlements where one approver is not enough, such as administrative roles in regulated systems | Adds independent sign-off and stronger evidence, but requests wait longer for a second reviewer and may stall in small teams |
| Request expiration limits | Requests that should be decided quickly, so an open request does not stay pending for weeks | Keeps the queue clean and stops stale requests from being approved late, but users may need to resubmit after a lapse |
| Grant expiration limits | Access needed only for a task or window, such as an incident response or a short migration | Limits standing privilege and exposure over time, but users may lose access mid-task if the window is set too short |
| Reviewer notifications and custom request flows | Cases where reviewers need context before deciding, such as the business reason or ticket reference | Improves decision quality and records the reason, but adds form steps that slow the request for simple cases |
How to configure access requests in authentik 2026.8
This sequence takes a team from confirming Enterprise licensing and version to a tested request, approval and expiry cycle with every action recorded in the event log. It produces a documented request workflow that reviewers and auditors can follow.
Confirm licensing and version
Confirm that your authentik subscription includes the Enterprise privileged access management feature, and that the deployment runs 2026.8 on a release line that receives security fixes. The supported lines named in the authentik security policy are 2026.5.x and 2026.8.x, so check the running version in the admin interface against the release notes before you go further. Ask your authentik contact to confirm that privileged access management is available on your subscription, because the Enterprise features documentation lists it as a preview feature. Done means you have a written record of the edition, the exact version and the preview status that your change ticket can reference.
Define applications and entitlements in scope
Decide which applications and entitlements can be requested, and list the users who may ask for them. Work with the application owners to name each target, the access level it grants and the group or role that represents it in authentik. Separate standing access, which stays in normal group membership, from time-limited access, which the request workflow will grant. Done means you have a scope list that maps each requestable application or entitlement to its authentik object and its owner, and that any entitlement without a clear owner is parked until someone accepts responsibility.
Create reviewer groups
Create one or more groups for approvers, and add the people who will approve or deny requests for each scoped resource. Keep reviewer groups separate from the groups that grant access, so that a requester cannot approve their own request by accident. Decide whether approval should come from named users, a group or a policy, since the request rules accept all three. Confirm that each reviewer has a working account, can sign in with the MFA you require and receives the notification channel you intend to use. Done means each reviewer group has a documented membership and a test reviewer has signed in successfully.
Build request rules with minimum counts and expiry
Create a request rule for each scoped resource. Set the approvers (users, groups or policies), the minimum number of reviewers who must approve, and the limits for how long a request can stay open and how long an approved grant can last. Set reviewer notifications so approvers know when a request arrives. Where a resource is high risk, a higher minimum reviewer count is a stronger control, but the right number is a decision for your risk owner. Done means each rule shows the approver source, minimum count and both expiry limits on the review screen, and a dry review with a test requester confirms the rule matches the intended resource only.
Add a custom flow for request details
If reviewers need more context than the default request form provides, such as a ticket number, a business reason or a planned end date, build a custom flow that collects those details before the request is submitted. Keep the fields to what reviewers actually use, and make required fields explicit so that incomplete requests do not reach the approval queue. Confirm the flow with the people who will read the requests. Done means a test request submitted through the flow stores every field you asked for, and the reviewer view shows those values without manual lookup.
Test a request end to end
Run one request from start to finish using a test account that is not an administrator. Submit the request, approve it with the required number of reviewers, confirm the grant takes effect, and then check that the access is removed when the grant expires. Test a denial as well, and confirm that a revocation performed by an administrator removes access before the expiry time. Record the request identifiers, timestamps and outcomes in your test log. Done means every path (submit, approve, deny, expire, revoke) has a dated record and the target application behaves as expected at each stage.
Confirm event log entries
Open the event log and confirm that each action from the test appears with the requester, reviewers, decision, resource and times. Check that the expiry and any revocation are also recorded, because the audit trail is the evidence reviewers and auditors will ask for. Export or forward the entries using your log pipeline if your retention policy requires it, and confirm that the enhanced audit logging feature is included in your edition. Done means you can reconstruct the full lifecycle of the test request from the event log alone, and you have written down where that evidence is kept and who can read it.
Security and audit considerations for privileged access
Access requests are only as trustworthy as the people and records behind them. The cards below cover who may approve, how thin reviewer pools weaken approvals, what the event log can and cannot prove, and how to confirm that revoked access actually stops working in the applications behind authentik.
Separate requesters from reviewers
Request rules can route approval to users, groups or policies, so the reviewer set must be defined so that no one can approve their own access or the access of a group they belong to. Review the rule for each protected application and entitlement and confirm that the requester population and reviewer population do not overlap. Test this with a non-production user before rollout, because overlapping group membership is easy to create by accident.
Size reviewer groups for coverage
Minimum reviewer counts set how many approvals a request needs, but a group with few members can leave requests waiting or push reviewers into approving without context. Ask who covers approvals during leave, on-call rotations and departures, and whether the minimum count can still be met on those days. Keep the group large enough to satisfy the minimum with a margin, and review membership on the same cadence as other access controls.
Use the event log as audit evidence
authentik 2026.8 records each action in the event log, including requests, approvals, denials and grants. Export or forward these events to the system your auditors use and confirm that the entries carry the requester, reviewer, target and timestamps your control narrative needs. Enhanced audit logging is listed as an Enterprise feature, so confirm the logging tier your subscription includes before you rely on it as evidence.
Keep request details in the record
Custom flows can collect the justification, ticket reference and duration a reviewer needs to decide. Make these fields mandatory in the flow design, so the stored record explains why access was granted. Without a justification, the event log shows that an approval happened but not what the reviewer relied on, which weakens the evidence during an investigation.
Verify expiry and revocation end to end
Approved access expires automatically, but an expired grant in authentik is only one step. Test that the connected application stops honoring the entitlement once it lapses or is revoked, including active sessions and any tokens the application already holds. Record the test result with the timestamp and application version so the check can be repeated after upgrades.
Treat privileged access as a preview
Enterprise privileged access management is listed as a preview feature. Confirm with authentik which parts of the request, approval and expiry behavior are stable for your version, and document any gaps that need a compensating manual review. Plan a retest after each upgrade, because preview behavior can change between releases.
What the audit trail records and what you still need to prove
Every action in the access request lifecycle is written to the authentik event log. According to the authentik 2026.8 release notes, that covers the request itself, reviewer approvals and denials, the grant, and its automatic expiry. Before you rely on this for evidence, confirm with authentik exactly which event types are emitted for each step, which fields each event carries (requester, reviewers, the application or entitlement, timestamps, and the approving identity), and whether revocations made by an administrator are logged with the same detail as expirations. Enhanced audit logging is listed among the Enterprise-only features on the authentik pricing page, so confirm your edition covers it before you design around it.
The event log inside authentik is a working record, not a retained evidence store. Plan to export or forward these events to a store your organization controls, with a retention period set by your policy and your assessor's expectations, and with access restricted so that administrators cannot quietly edit history. Test the pipeline end to end: request an access grant in a non-production instance, approve it, let it expire, then confirm each event arrives in the external store with the fields your reviewers need. Preview status for privileged access management, noted on authentik's Enterprise features documentation, also means you should re-run this test after every upgrade.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Whether this trail is sufficient for your obligations is a judgment that independent auditors make, and they will ask you to show the approval policy, the reviewer group membership at the time of each decision, the expiry limits in force, and a sample of requests traced from start to finish. Assemble that package before the assessment starts, and agree with your auditor in advance which evidence they will accept.
Limits and what to confirm in your environment
Access requests and privileged access management in authentik 2026.8 are new and labeled as a preview feature, so the questions below matter before any production rollout. Each card names one thing to verify with authentik and in your own test environment before approvals gate real entitlements.
Preview status for production
The Enterprise features page lists privileged access management as a preview feature. Ask authentik how the preview is expected to change before general availability, whether the feature carries stability commitments, and what support is available during the preview. Decide whether a preview feature can gate access to production systems in your organization or only pilot groups. Record the answer in your change approval.
Supported application types
Request rules are documented for applications and entitlements, but confirm which provider types and entitlement models the feature covers in practice. Test an OIDC application, a SAML application, an LDAP-backed resource and any proxy-protected app you depend on. Anything outside the tested set should be treated as unsupported until your own test proves otherwise.
Behavior on revocation
Expiry is documented, but manual revocation before expiry needs its own test. Confirm whether revoking a grant removes active sessions, tokens or group membership immediately, and whether the application honors the change without a re-login. Run a test where a grant is revoked mid-session and verify the result in the application logs.
Reviewer notification channels
Request rules support reviewer notifications, but the delivery channels available in your deployment need confirmation. Check whether notifications go by email, in-app, or through a webhook, and whether your mail relay and reviewer addresses are configured. Confirm what a reviewer sees when a request is pending for a long time and whether reminders exist.
Audit trail completeness
Every action is recorded in the event log according to the 2026.8 release notes. Before relying on it as evidence, confirm which events capture the request, the reviewer decision, the grant, expiry and revocation, and whether the record names the approver and the requested entitlement. Confirm how long events are retained and how you export them to your log platform.
Upgrade impact on live grants
Plan upgrades with the sequential upgrade rule in mind and test how existing grants, request rules and custom flows behave after moving to a newer release. Ask whether grants created on an earlier version survive an upgrade unchanged. Keep a staging copy of your configuration to replay the upgrade before production.
Questions buyers ask before setting up access requests
What does it cost to run access requests in authentik?
The software cost depends on the edition. The access request and privileged access management capability is an Enterprise feature, and the authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Open Source is free but does not include privileged access management. Enterprise Plus starts at $20k annually and adds dedicated support with SLAs. Ask your licensing contact how user counts are defined, including whether contractors count as external users. Your larger cost is usually labor: the people who define which entitlements are requestable, who approves them and how long grants last.
How long does it take to configure access requests?
Timing depends mostly on how many applications and entitlements are in scope and how many distinct approval paths you need. A single application with one reviewer group and a fixed expiry is a small configuration. Each additional application, approval chain, minimum reviewer count or custom request form adds design, testing and sign-off work. Before you start, agree on the list of requestable items, the reviewer for each, and the maximum grant length. A fixed-scope written plan with those inputs is the most reliable way to estimate duration. DeployOpen does not publish durations, so ask for a timeline tied to your written scope.
What must our team provide before the work starts?
Three inputs decide most of the design. First, identity owners: the people who own each application or entitlement and can say what access is appropriate. Second, reviewer groups: named groups in authentik, with the minimum number of approvers you require before a grant is made. Third, policy decisions: which requests can be approved by a user, a group or a policy, how long a request can stay open, how long an approved grant lasts, and what details a requester must give. Your security and compliance leads should also confirm who may revoke access early and where audit evidence must be kept.
Can our internal identity team set up access requests alone?
Yes, if your team already runs authentik and has someone comfortable with its flows, policies and Enterprise configuration. The product documentation covers request rules, reviewer settings and expiry. The harder part is organizational: agreeing on who approves what, which entitlements qualify and how grants are reviewed. Teams without recent authentik experience usually need time to learn the flow and policy model, and the feature is listed as a preview on the Enterprise features page, so confirm its current maturity against the release notes before you rely on it for regulated access. Test in a non-production instance first.
When does a partner help with access request design?
A partner is most useful when the approval model is complex or the audit requirements are strict. Typical triggers include several applications with different reviewers, minimum reviewer counts that must match a written policy, custom request flows that collect business justification, and integration with an HR or ticketing process. A partner can also prepare the test plan, rehearse approvals and expiries, and document the evidence trail. DeployOpen plans, implements, tests and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope and timelines agreed in writing before work starts.
What breaks most often when access requests go live?
The most common problems are configuration gaps rather than software faults. Reviewers may be missing from the group that receives notifications, so requests stall. A minimum reviewer count may be set higher than the number of people in the group, which blocks every approval. Expiry values may be left too long for sensitive entitlements. Custom request forms may not collect the fields your reviewers need. Test each path with a real requester, a real reviewer and a revocation before go-live, and confirm that the event log captures each step. Check the release notes for your version, since the supported versions for security fixes are listed in the authentik security policy.
How do we prove who approved access and when it ended?
authentik records each action in the event log, including requests, approvals, denials, grants, expiry and revocation, according to the 2026.8 release notes. Export these events to your log platform so they survive any changes to the identity system and can be searched during an audit. Define retention before go-live, and decide who can read the logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Your independent auditor decides whether the evidence is sufficient.
Does access requests work with our existing applications?
It works for applications that authentik signs users into through a configured provider, since access is granted against those applications and entitlements. Applications that authenticate outside authentik, through a local account store or a separate directory, may not be covered by the same grant. List each application, how users sign in today, and whether the entitlement lives in authentik or in the application itself. Entitlements held only in the application need a plan for how a grant is pushed or checked. Confirm each case against the authentik provider documentation before you commit to a scope.
When a team should adopt access requests now
Adopt authentik access requests now if your team handles frequent contractor onboarding, short-term elevated access, or entitlement grants that today are handled by ticket and manual group edits, and if you can accept that privileged access management is listed as a preview feature in the Enterprise features documentation. The strongest fit is an environment where every grant needs a named approver, an automatic end date and a record that an auditor can read without asking the platform team to reconstruct events. authentik 2026.8 added this capability with request rules that can route approval to users, groups or policies, a minimum reviewer count, request and grant expiration limits, reviewer notifications and custom flows that collect the justification. Those controls map directly onto the approval evidence regulated teams are usually asked for.
Be cautious if the grant pattern is simple and stable. When a person joins a team and keeps the same access for years, plain group membership managed through your normal joiner, mover and leaver process is easier to explain and has fewer moving parts. The same applies if you cannot staff reviewers who will respond within your own approval window, because a minimum reviewer count only helps when enough named people are available to act. Also wait if you need a control that your change board treats as generally available rather than preview. Before committing, confirm with authentik which parts of the request workflow your Enterprise license covers, how the preview label affects upgrade and support commitments, and whether your planned version line will carry the feature forward.
How DeployOpen scopes and delivers access request rollouts
DeployOpen plans, implements and documents authentik access requests and privileged access management inside your own infrastructure, starting from a written scope that names the applications, entitlements and reviewer groups in play. Engagements are fixed-scope, so deliverables and timelines are agreed before build work begins.
How we scope
- Inventory the applications and entitlements that users should request, and classify which ones need time-limited access at all.
- Map request rules to reviewer users, groups or policies, with the minimum reviewer count for each rule written down.
- Agree request and grant expiration limits, reviewer notification behavior and the custom request flow fields in the written scope.
How we build
- Configure request rules and reviewer groups in a non-production authentik instance, then test approval, denial and expiry paths with named test accounts.
- Build the custom flow that collects justification and ticket details, and confirm which fields reach the reviewer and the event log.
- Verify revocation: confirm that access ends at expiry and when a grant is removed early, and record the expected event log entries for each case.
How we hand over
- Deliver written runbooks for requesters, reviewers and administrators, including how to approve, deny and revoke a grant.
- Provide an audit evidence pack that shows where request, approval, grant, expiry and revocation events appear in the event log.
- Document the privileged access management preview status and the Enterprise license dependency so your team can plan the change deliberately.
How we support
- Offer ongoing support, upgrades and testing as a retainer, covering version changes such as the 2026.8 line and later releases.
- Re-test request rules and expiry behavior after each authentik upgrade before reviewers rely on them again.
- Ask us to confirm during scoping which support terms, response expectations and upgrade windows apply to your retainer.
