authentik remote access with RAC

authentik remote access with RAC: when browser access replaces a VPN for some users

The authentik RAC provider, listed among authentik's provider types as remote access control, gives signed-in users browser-based access to internal machines, and the outpost is the component that carries those sessions to the targets. Teams choose this over a full VPN when a small group, such as support engineers, administrators or vendors, needs occasional access to specific machines and a VPN would place far more of the network within reach than the task requires. The protocols named for this topic are RDP, SSH and VNC. Confirm in the RAC provider documentation which protocol variants, browser requirements, clipboard and file transfer behavior, and outpost placement are supported before you design around them.

The three common options solve different problems. A VPN grants network-level reach, a bastion host gives a hardened jump point with shell access, and RAC gives identity-gated sessions to named endpoints without granting a network path. Decide early how many users need access, whether they work from managed devices, whether they need only a few hosts, and whether sessions must be recorded or logged in a form your auditors accept. Check where the outpost must run to reach each target segment, since a single outpost placed in the wrong network zone can make an otherwise correct configuration fail. The authentik providers documentation is the starting point for matching these requirements to the provider settings.

A browser session is only as strong as the identity behind it, so the sign-in path for RAC users should enforce the same multi-factor and group controls you apply to your other privileged applications. Plan a pilot with one or two machines and a single user group, then test access from a clean network path to confirm the outpost reaches each target. Also decide who owns credentials on the target machines and how they reach the session, because RAC does not remove the need to manage local accounts. Record these decisions in writing so the team that runs the platform can answer access questions later.

RAC, VPN and bastion compared for internal machine access

This table compares browser-based RAC access through authentik, a full VPN and a traditional SSH or RDP bastion across the factors that shape a rollout. Read each row as a question to answer for your own environment, and treat any cell marked for confirmation as an open item for the vendor or your proof of concept. The main takeaway is that RAC narrows what users can reach but shifts some logging and placement questions to the outpost and to features you still need to verify.

Factor	Browser-based RAC with authentik	Full VPN	SSH or RDP bastion
User experience	Users sign in through the authentik portal and open RDP, SSH or VNC sessions in a browser tab	Users connect a network tunnel and then use their normal native clients against internal addresses	Users connect to a jump host first, then start a second session to the target machine
Client software needed	Browser only for the session; confirm supported browsers and any client prerequisites for your protocols	VPN client on every managed device, with platform support and configuration to maintain	Native SSH or RDP client; the bastion itself is reached through standard tooling
Per-endpoint policy	Access is granted per configured endpoint and can be bound to authentik policies and groups	Typically granted at network or subnet level; per-host rules depend on firewall design	Enforced through host and account controls on the bastion; per-target rules depend on configuration
Session expiry	Session lifetime is a provider setting; confirm the exact options and behavior in your version	Tunnel lifetime and re-authentication depend on the VPN platform configuration	Depends on SSH or RDP server settings and bastion hardening
Session recording and logging	Confirm whether session recording and per-session audit fields meet your evidence needs before relying on them	Logs usually show tunnel establishment, not the actions inside each internal session	Session recording is available in some bastion products; confirm the tool you choose
Network placement of the outpost	The outpost must reach the target machines and be reachable by users through authentik; plan its network zone explicitly	The VPN gateway sits at the network edge and terminates tunnels into internal segments	The bastion sits in a controlled zone with inbound access to targets on the protocol ports
Operational ownership	Shared between the authentik platform team and the team that owns endpoint definitions and outposts	Network or security team owns gateway, client rollout and split-tunnel rules	Infrastructure team owns bastion hosts, accounts, keys and hardening

How endpoints and per-endpoint policies control who connects

Each internal machine becomes an endpoint in authentik, and every endpoint is tied to a RAC provider that holds its connection details: protocol (RDP, SSH or VNC), target address, and the credentials authentik uses to log in on the user's behalf. A user sees an endpoint in their application list only if the policies bound to it allow them to. Model one endpoint per machine or per tightly scoped service rather than grouping many hosts under one entry, because the policy decision is made per endpoint and a broad entry means a broad grant. Before you build, list every host, its protocol, the account authentik will use to log in, and the team that owns it. That inventory is the input to every policy decision that follows.

Access is decided by policy bindings on each endpoint, typically expression or group-membership policies evaluated against the user's groups and attributes. Most organizations already have groups synced from Active Directory, Entra ID or another directory, so decide early whether those groups map directly to endpoint access or whether you create authentik-specific groups that a directory group feeds into. Direct mapping is faster to run but inherits any stale membership in the directory, while a separate layer gives you a place to add approvals or time limits. Because one outpost can reach several networks, grant each group only the endpoints its members need, and keep a separate outpost or network path for hosts in a different trust zone so a permissive rule in one zone cannot expose another. Confirm the exact binding behavior, policy evaluation order and any session-level controls in the authentik configuration documentation before design sign-off, since these details determine what a user can open and for how long.

Setting up a RAC endpoint in authentik, step by step

This sequence takes a team from a confirmed authentik release to a tested browser-based session on an internal machine, with a check at each stage so problems surface before users depend on the path. It produces a working RAC provider, one endpoint, and policy-scoped access verified from a non-admin account.

Confirm the authentik version and release line
Before building anything, the platform owner confirms which authentik version is running and whether it sits on a release line that receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines, and the GitHub releases page shows the latest release, so compare your running version against both. Check the release notes for the RAC provider and any upgrade steps that apply to your version. Done means you have a written version number, a confirmed supported line, and a plan to upgrade first if you are behind.
Place an outpost on a host that reaches the target
The RAC connection runs through an outpost, so the platform team deploys one on a host or container that can open network connections to the target machines over RDP, SSH or VNC. Choose a location inside the segment where the targets live, and confirm that outbound connectivity from the outpost to the authentik server works. Check the outpost health status in the admin interface and confirm it reports as connected before moving on. If it does not appear, verify the outpost token, the server address and firewall rules between the two.
Create the RAC provider and its application
In the admin interface, the administrator creates a RAC provider and attaches it to a new application, which becomes the tile users see after sign-in. Set the application name, launch URL and icon, and bind the provider to the outpost placed in the previous step. Keep the provider and application names descriptive, since they appear in the event log and in access reviews. Done means the application appears in the admin list with the provider linked and the outpost assigned, and the configuration is saved without validation errors.
Define the endpoint and its connection settings
Under the RAC provider, the administrator adds an endpoint for each machine or service, choosing the protocol (RDP, SSH or VNC), the target address, the port, and the credentials or credential handling the protocol requires. Confirm the exact settings for each protocol in the authentik provider documentation for your version, because option names and supported credential methods can change between releases. Record which endpoints hold privileged accounts so they receive tighter policies later. Verify by opening the endpoint details and checking that the host, port and protocol match the target system.
Bind policies to users and groups
Access is granted through policy bindings, so the administrator binds the application or endpoint to a named group rather than to individual users. Use group membership that your identity source already maintains, and add expression or other policies only where the protocol and business need call for them. Keep administrator-only endpoints in a separate group from general staff endpoints. Verify the bindings by reviewing the list of bound policies on the application and confirming that users outside the intended groups do not see the application in their library.
Test sign-in with a non-admin account
The tester signs in as a standard user who belongs to the bound group, not as an administrator, because administrator accounts can see paths that ordinary users never reach. Confirm the application tile appears, then open a session to the endpoint and check that the remote desktop or terminal loads. Also sign in with a user outside the group and confirm access is refused. Done means both outcomes match the policy design, and any failure is traced to a specific policy, outpost connection or endpoint setting.
Review session expiry and the event log
After a successful test connection, the platform owner reviews the event log for the sign-in, the authorization decision and the RAC session start and end. Confirm that the entries identify the correct user, application and endpoint, and that the refused attempt from the excluded user is also recorded. Check the session expiry settings configured for the provider against your organization's rules for idle and maximum session length, and record the values you chose. The sequence is complete when the log shows both events correctly and the expiry behavior has been confirmed in a live test.

Security risks in browser-based remote access to internal machines

Browser-based RDP, SSH and VNC access puts a gateway between users and machines that hold sensitive data. The risks below share one root: the RAC outpost and its policies become the path to internal hosts, so a weakness in exposure, access rules, credentials, session handling, logging or patching affects every session. Each card names the control to design and what to verify before go-live.

Outpost exposure to untrusted networks

The RAC outpost is the component that opens connections to internal machines, so it should sit where only the authentik server and approved user paths can reach it. Design a network placement that keeps the outpost off the public internet and limits which subnets it can reach, using firewall rules that name the target ports for RDP, SSH and VNC. Verify in your own environment which network paths the outpost can initiate and whether any management interface is reachable from outside the trusted segment. Confirm the outpost deployment model with the authentik outposts documentation before you choose a placement.

Over-broad endpoint policies

A RAC provider exposes every endpoint it is bound to, so a policy bound at the application level can grant more machines than intended. Design per-endpoint policies that tie each machine to a named group, such as production database administrators, and deny by default for everyone else. Review group membership as a control, because a user added to a broad group inherits access to every endpoint under it. Test with a non-admin account that each endpoint is visible only where the policy allows it, and record the test result as evidence.

Shared or stored target credentials

RAC can connect with credentials stored on the provider, which removes the need for users to know machine passwords but also concentrates that secret in the identity platform. Decide whether each endpoint uses stored credentials, a per-user prompt or an external secrets store, and document the owner and rotation schedule for each one. Shared accounts on target machines break per-user attribution in session records. Verify how authentik stores and encrypts endpoint credentials and who can read them in the admin interface before you approve the design.

Session lifetime and idle timeout

A remote desktop or shell left open is an active path into a machine, so session duration and idle behavior are security settings, not comfort settings. Set a maximum session lifetime per endpoint class, with shorter limits for privileged hosts, and set an idle timeout that closes sessions after inactivity. Confirm which session expiry options the RAC provider supports for each protocol, since RDP, SSH and VNC may behave differently. Test that an expired session cannot be resumed from a stale browser tab.

Logging gaps for privileged sessions

Auditors and incident responders need to know who connected to which machine, when, and from where, and what happened during the session. Identify which events the authentik event log records for RAC connections and which session activity, such as keystrokes or recordings, it does not capture. Forward authentik events to your central log platform and confirm retention matches your policy. Where recording is required, decide the tool or machine-side setting that provides it, because the authentik event log alone may not satisfy that need.

Patching the server and outpost

The authentik server and the outpost must run supported versions, because a remote access gateway that falls behind carries the same exposure as any internet-facing service. Plan patch windows for the server, worker and outpost together, and check the security policy to see which release lines receive fixes. Subscribe to release notices so you can act on the advance notice the project gives before security releases. Verify that your outpost version matches the server version, and test upgrades in a staging copy before production.

Where the RAC outpost runs in Docker Compose and Kubernetes

The authentik Docker Compose guide positions Compose for test setups and small-scale production, and it calls for a host with at least 2 CPU cores and 2 GB of RAM. On that host you run the server container, which includes core and an embedded outpost, the worker container and PostgreSQL. For RAC, the outpost must open RDP, SSH and VNC connections to your target machines, so the host needs a network path to those targets while users reach the login page through your reverse proxy.

Minimum host size: 2 CPU cores and 2 GB of RAM is the documented floor. Remote sessions carried through the outpost add load, so size the host against the number of sessions you expect at the same time.
Placement: put the host on a segment that can reach the target ports, and keep those target ports closed to everyone else.
Database: PostgreSQL holds all configuration and data except uploaded files, so include it in your backup and restore tests.
Single host limit: Compose runs everything on one machine. If you need outposts spread across failure domains, plan for a different platform.

Confirm with the vendor whether RAC traffic runs through the embedded outpost or a separate outpost container before you size the host.

Questions teams ask before building authentik remote access

Is authentik RAC included in the Open Source edition or does it need an Enterprise license?

Confirm this on the authentik pricing page before you commit, because the pricing page lists Enterprise-only features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management and enhanced audit logging, and RAC is not named in that list. The repository is mostly MIT-licensed, but code in the enterprise directory falls under a separate license, so check which directory and edition the RAC provider in your target version belongs to. Ask the vendor for written confirmation of the edition, support terms and any feature-level restriction for the version you plan to run.

What does a remote access build cost and what drives the effort?

Cost has three parts: the software edition you choose, the infrastructure that hosts authentik and the outpost, and the services work to design and verify the setup. Software licensing is a recurring decision that depends on your edition and user count, and the pricing page lists per-user Enterprise pricing if that edition applies. Services effort rises with the number of protocols (RDP, SSH and VNC each behave differently), the count of target machines, how many network zones the outpost must reach, how many permission tiers you need, and how much of your existing VPN or bastion logging must be matched. Request a quote built from a written scope listing endpoints, zones, identity groups and session rules.

How long does it take to prove a first endpoint works?

The first endpoint usually takes longer than later ones because it sets up the shared pieces: the authentik deployment, the outpost placement, the network path to one target, the identity group model and the session settings. Duration depends on how quickly your team can open the required network path, whether a suitable test machine exists, and whether your identity groups are already clean in authentik. A useful proof covers one RDP or SSH target, one policy that allows a named group and denies everyone else, a session expiry test, and a log review. Agree on that proof as a milestone in the written scope rather than as an open-ended pilot.

What must our team provide before the engagement starts?

Your team typically provides:

Network access: a host or cluster where authentik runs, a path from the outpost to each target on the ports it needs, and firewall change approval.
A target inventory: hostnames or addresses, protocol per machine, operating system, owner and the account used for connection.
Identity groups: which users need which machines, who approves new access, and the group names used in authentik policies.
Test accounts and a maintenance window for the first cutover.

Also confirm who holds administrator rights in authentik and who receives audit logs. Missing inventory is the most common reason a scope grows during build.

Can our internal engineers build and run this without outside help?

Yes, a team with experience in identity, Linux and Windows administration, and reverse proxy or network operations can build it, provided it has time and a clear design. The work that most often needs outside help is the security design: outpost placement, credential handling for shared target accounts, session recording decisions and how the setup is tested against your access policies. Internal teams should also plan for upgrades, since authentik releases move quickly and the supported versions are listed in the security policy. Weigh the cost of your engineers' time against the risk of a rushed build, and confirm the skills gap in a short design review before you decide.

How do we replace a VPN with authentik RAC without exposing internal networks?

Replace a VPN in stages rather than cutting it off on one date. Start with a small group and a short list of machines, keep the VPN available as a fallback, and confirm that every RAC session is logged with the user, target and time. Keep the outpost in a segment that can reach only the approved targets, enforce MFA at the authentik login, and set session expiry so idle or long sessions end. Some teams keep a bastion for administrative paths while RAC serves day-to-day users. Review your threat model with your security team, since browser-based access changes what an attacker can reach after one compromised session.

What should we verify before opening RAC to all users?

Verify the controls that matter in production:

Policies: a user outside the approved group cannot see or open a target.
Session expiry: sessions end after the configured period and cannot be reused.
Logging: each connection appears in your log pipeline with user, target and time.
Failure paths: an outpost restart, a target reboot and a lost identity provider session each leave a clear state.

Run these checks against each protocol you enable. Keep the test results as evidence for your change record and for any compliance assessment your organization undergoes.

Limits to confirm in your environment before you commit

Remote access through the authentik RAC provider depends on protocol coverage, target operating systems, session controls and licensing, and none of these is settled by the open-source code alone. The cards below list what to verify with the vendor documentation, a test endpoint and the authentik support channel that matches your license before you commit to the design.

Protocol and client coverage

Confirm exactly which RDP, SSH and VNC features the RAC provider supports, including clients, authentication modes, keyboard and clipboard handling, and file transfer. Test each protocol with the client your users actually run, on a non-production endpoint. Do not assume that a protocol listed as supported covers every feature your teams expect from a native client.

Supported target operating systems

Ask which target operating systems and versions the RDP, SSH and VNC paths were tested against, and which server components must run on each target. Windows remote desktop settings, SSH server configuration and VNC server software differ across releases, so list your exact fleet and test a representative sample of each.

Session expiry and idle timeout

Confirm which session lifetime and idle timeout options the RAC provider exposes, whether they apply per endpoint or globally, and how an expired session is ended on the target. Verify that a dropped browser tab does not leave a live session open. Record the settings you choose, since they become part of your access control evidence.

Handling of target credentials

Establish where target credentials are stored, who can read them, how they are rotated, and whether users ever see them. Check whether the outpost holds credentials in memory or in the database, and whether they are encrypted at rest. Ask the vendor documentation and your security team to agree on this before any endpoint is published.

Licensing under the open-source and enterprise split

authentik's code is largely MIT licensed, while the enterprise directory is under its own license, so confirm which part of the RAC functionality you need sits in each. Check the pricing page and the license text against your plan before you design around any feature. Ask the authentik support channel that matches your license to confirm the answer in writing.

Recording and detailed session audit

Confirm whether the RAC provider records session content, and whether it logs connection starts, ends and endpoint names in the event log. Decide whether event-level audit meets your evidence needs or whether you need a separate session recorder. Ask for a sample audit record and check that retention and export meet your policy.

How DeployOpen scopes and delivers RAC access for your machines

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For authentik remote access with RAC, we start from the machines and users you need to reach, then agree the scope in writing before any build work begins.

How we scope

Inventory the internal RDP, SSH and VNC targets, their owners and the user groups that need each one
Record which endpoints need per-endpoint policies and which can share a single access rule
Confirm where the authentik server, worker and outpost will run and how they reach the targets
Agree session expiry values, MFA expectations and audit requirements in the written scope

How we build

Deploy the authentik instance and its PostgreSQL database in your infrastructure, with a separately managed database for production
Configure RAC providers, endpoints and the outpost that brokers each protocol to the target machines
Build and test per-endpoint policies, group bindings and session expiry against real test accounts
Verify connections from the intended networks and confirm that blocked users cannot reach restricted endpoints

How we hand over

Document endpoint definitions, policy logic, outpost placement and the firewall paths each connection relies on
Provide runbooks for adding an endpoint, rotating outpost credentials and revoking a user's access
Walk your operations and security teams through the configuration, the test results and the open items
Deliver configuration in a form your team can review, version and reproduce on its own

How we support

Support is available as a retainer for upgrades, outpost maintenance and changes to endpoints and policies
Plan upgrades around authentik's supported release lines and confirm each release note before applying it
Review access logs and policy changes with your team during scheduled check-ins under the retainer
Confirm the support terms, response expectations and included work in writing before the retainer starts

authentik remote access with RAC