What authentik Endpoint Devices does and whether to adopt it now
A platform team that wants to replace shared SSH keys and static kubeconfig or AWS CLI credentials with authentik identity should know first that Endpoint Devices, introduced in 2025.12, is marked by the documentation as early preview and not recommended for production. The feature uses the authentik Agent to register end-user devices and servers, then handles device compliance, local device login, SSH and CLI application authentication such as kubectl and AWS. Treat it as a candidate for a lab or pilot environment today, and plan the production cutover for a later release once the preview label is removed. The scope is broader than SSH. Registering a device through the agent lets authentik tie a command-line session to a named user and a registered machine, rather than to a long-lived key or a copied token. For SSH, the documented path currently supports only Linux devices as SSH endpoints, and it requires the agent on both the source and the target. Sudo authorization can also be handled through the same flow, which matters for teams that currently grant root through shared accounts. Confirm with the vendor whether Windows or macOS endpoints are on the roadmap before you design around them. Evaluate it now if you run a small, non-production Linux estate, want to learn the agent enrollment model, or need to test how your audit and offboarding processes would consume authentik events. Wait if your SSH access to production hosts, or your kubectl and AWS access to production clusters and accounts, depends on the feature, or if an auditor will expect a production-grade control. Ask the vendor or your partner to confirm the current status, supported platforms and any production readiness commitments in writing, and keep existing keys and credentials in place until that confirmation exists.
Which access paths the authentik Agent covers
The authentik Agent covers five related paths: device registration for compliance, local device login, SSH to Linux hosts, sudo authorization on those hosts, and CLI sign-in for tools such as kubectl and AWS. All five depend on the same enrolled device identity, but each has its own targets, prerequisites and maturity. Read each card as a separate go or no-go decision.
Device registration and compliance
The authentik Agent registers end-user devices and servers with your authentik instance, so each machine has an identity record that authentik can use for compliance decisions. Registration is the foundation for the other four paths, so it is the first thing to pilot. Confirm which device attributes the agent reports, how enrollment is approved, and who owns the record when a device is retired. The documentation marks Endpoint Devices as early preview and not recommended for production, so plan a pilot group before any fleet-wide rollout.
Local device login
The agent also covers local login, which lets a user sign in to a workstation or server with their authentik credentials. Confirm which operating systems and login methods the current agent release supports, because the Linux-only limit on SSH does not settle local login support. Test lost-device recovery, offline sign-in and how local accounts map to authentik users. Keep an approved break-glass local administrator path until those tests pass on your own hardware.
SSH to Linux hosts
For SSH, the documentation currently supports only Linux devices as SSH endpoints. The agent must be installed on both the source machine users connect from and the target host they reach, so the rollout starts with a list of paired hosts rather than the whole fleet. Inventory jump hosts, automation runners and any servers that cannot run the agent, and decide what happens to existing key-based access during the transition. Keep current SSH access available until the new path has been tested end to end.
Sudo authorization on SSH hosts
The SSH documentation states that the agent can handle sudo authorization, so privilege escalation on a host can be decided through the same authentik-backed flow. A locally maintained sudoers entry remains a separate control that needs its own review. Confirm which groups or policies grant sudo, how that mapping stays in sync with your directory, and how a revoked user loses elevated rights during an active session. Test the failure path too, because a sudo decision that cannot reach authentik could block administrators on the host.
CLI authentication for kubectl and AWS
The agent supports CLI application authentication for tools such as kubectl and the AWS CLI, using authentik credentials instead of separately issued static keys. Confirm that each target accepts identities issued by authentik, since the cluster and cloud account side of that trust is a separate configuration task. Check token lifetimes, where kubeconfig and AWS profile files are written on developer machines, and which groups map to cluster roles and account permissions. Document the fallback for engineers whose devices are not enrolled.
Why SSH support is limited to Linux endpoints today
The authentik Agent's SSH authentication currently works only when the target host is Linux. Windows and macOS machines cannot yet be SSH endpoints through this path, so any fleet with mixed operating systems needs a split plan: Linux servers move to agent-based SSH, while other systems keep their existing access method until the feature widens. The agent is also required on both the source (the machine the administrator connects from) and the target, which means a Linux host cannot be brought under this model by changing only the client side. Before scoping, inventory which hosts are Linux, which connect from workstations that the agent can be installed on, and which are reached from tools or jump points you do not control.
Bastion designs and existing SSH workflows need the same check. If your current pattern uses a bastion to reach private hosts, confirm whether the bastion, the workstations and the targets can all run the agent, and whether your security team accepts the agent's place in that trust chain. Teams that issue SSH certificates or manage authorized_keys files should not assume the agent replaces them on day one. Plan a parallel period, document which accounts and hosts use which method, and confirm with the vendor how the agent interacts with existing certificate authorities and key files in your environment.
Sudo authorization is handled by the agent as part of the same flow, so privilege decisions can be tied to authentik group membership rather than only to local sudoers entries. Confirm the exact sudo behavior, the group mapping and the fallback path against the current documentation before you write runbooks, because preview features change between releases. If the Linux-only limit blocks a platform you need, record it as a dependency and wait for the feature to reach a supported status rather than building a custom bridge that your team would then have to maintain.
When to pilot now and when to wait
A lab or pilot is the right place to learn how the authentik Agent registers devices, how SSH and CLI sign-in behave, and where your team's assumptions break. The documentation marks Endpoint Devices as early preview and not recommended for production, so a pilot should be treated as a test of the feature itself, not as a候补 replacement for existing access paths. Keep the pilot isolated, use disposable hosts, and write down every step so the results can be repeated.
- Isolated test hosts: Use a small set of Linux machines that hold no production data and can be rebuilt from scratch.
- Both ends tested: Install the authentik Agent on the source and target, since SSH authentication requires it on both.
- Sudo behavior: Test sudo authorization with a named test group before relying on it.
- Failure drills: Practice removing a device, revoking a user, and recovering when the agent or server is unreachable.
- Documented findings: Record versions, configuration keys and observed behavior so the same test can be repeated after upgrades.
Before you move past the lab, confirm the current status and supported platforms with the authentik Endpoint Devices documentation, since preview features change between releases.
Non-production internal tooling, such as a platform team's sandbox clusters, build hosts or internal developer utilities, is a more practical place to test with real users. Access to these systems is still important, but an interruption can be contained, fixed by the owning team, and rolled back. Even here, the preview label means you should keep a standard access path available so that engineers are never locked out of a system they must maintain.
- Break-glass access: Keep existing SSH keys or a bastion path working for administrators until the feature is proven.
- Scoped rollout: Limit the first group to a few owners who understand the tooling and can report problems quickly.
- Linux only: Confirm that every target is Linux, because SSH support currently covers only Linux endpoints.
- CLI checks: Verify kubectl or AWS CLI sign-in against a non-production cluster or account before wider use.
- Upgrade plan: Schedule a test upgrade of the authentik version and the agent to see whether sessions and registrations survive.
Ask the authentik vendor or your DeployOpen contact to confirm the supported agent versions for your operating systems before any internal rollout.
For regulated production access, such as administrative SSH into systems that hold customer or patient data, the documented guidance is the deciding factor. Endpoint Devices is marked early preview and not recommended for production, so it should not be the sole mechanism that controls privileged access. Your compliance and security teams will also expect evidence that access controls operate as designed, and a preview feature is hard to defend in an assessment. DeployOpen prepares systems and evidence for assessments, but independent auditors decide whether a control is adequate.
- Wait for production status: Do not make Endpoint Devices the only path for privileged SSH until the documentation removes the preview label.
- Keep proven controls: Continue using established bastion, certificate or key management controls for production hosts.
- Evidence plan: Define what logs, approvals and access records you need, and test whether the feature produces them.
- Vendor support terms: Ask what support and support levels apply to your edition before depending on it, since Enterprise pricing and features are listed separately.
- Risk acceptance: Document any residual risk and get sign-off from the accountable owner.
Before expanding, confirm the current status, supported platforms and edition requirements with the authentik Endpoint Devices documentation and your compliance team.
Configuration choices and when each fits
This table compares the main decisions for authentik Endpoint Devices: licensing, SSH access model, CLI authentication target and agent rollout. Read each row against your current access path, and check the Enterprise column before budgeting, since the pricing page lists Enterprise as a paid edition.
| Decision | Option | Trade-off | When it fits |
|---|---|---|---|
| Licensing | Open Source edition | Free edition with community Discord support only. Confirm with authentik whether Endpoint Devices features are available without an Enterprise license. | Evaluation and lab work where preview status is acceptable |
| Licensing | Enterprise edition | Paid per user per month, billed annually, plus a per external user fee according to the pricing page. Enterprise-only items on that page include ticket-based support for subscriptions over $1k. Confirm feature entitlement for Endpoint Devices in writing. | Teams that need vendor-backed support on the same platform as their SSO |
| SSH target platform | Linux hosts only | SSH with the authentik Agent currently supports only Linux devices as SSH endpoints. Windows and macOS targets stay on their existing access paths. | Estates where Linux servers are the main SSH targets |
| SSH access model | Agent on source and target | The agent is required on both sides, and sudo authorization is supported. Every host in the access path needs agent rollout before it can be used. | Fleets that can install and maintain the agent on each server |
| SSH access model | Existing bastion or RAC access | Bastions and the authentik RAC provider are separate patterns with their own operations. Keep the current path until Endpoint Devices SSH has been tested against your host set. | Production access paths that already meet audit and session needs |
| CLI authentication | kubectl | Uses authentik credentials for cluster access. Confirm the supported authentication flow and cluster-side configuration with authentik and your Kubernetes distribution. | Platform teams that want SSO-backed cluster access on developer workstations |
| CLI authentication | AWS CLI | Uses authentik credentials for AWS access. Confirm the role mapping, session duration and federation setup in your AWS account before relying on it. | Teams already federating AWS access through an identity provider |
| Agent rollout | Pilot device group | A small group of Linux servers or workstations tests login, SSH, sudo and CLI flows. Preview status means behavior may change between releases. | First phase, before any production dependency |
| Agent rollout | Production device group | Wider deployment across hosts with a documented fallback path. Wait until the documentation no longer marks the feature as early preview, or accept the risk in writing. | Only after the pilot and a tested rollback plan |
Setting up a pilot with the authentik Agent
This sequence takes one Linux source and one Linux target from a clean state to verified SSH and sudo sign-in through authentik, with a rollback point at each step so the pilot stays contained while the feature remains in early preview.
Confirm the authentik version and release line
The platform owner checks the running authentik version against the release line that receives security fixes and the Endpoint Devices release notes, then records the version in the pilot plan. Endpoint Devices was introduced in 2025.12, so confirm your deployment is on a release at or after that line before going further. Check the current supported lines in the security policy and the latest release on the GitHub releases page. Done means the version, the date checked and the upgrade path, if one is needed, are written down. Rollback: no change has been made yet, so stop here and schedule an upgrade under your normal change process if the version is too old.
Confirm Enterprise licensing for the feature
The platform owner or procurement lead confirms with authentik whether the license covering your instance includes the Endpoint Devices capability and the agent. Ask for the license terms in writing, the edition name and any user or external-user counts that apply. Read the license file in the Enterprise directory, since code under that path is governed by a separate license from the MIT-licensed core. Done means you hold a written answer on licensing scope. Rollback: if the feature is not covered, end the pilot here or move to a test instance that is licensed for evaluation.
Register the Linux source and target devices
The identity administrator registers one Linux source workstation and one Linux target server as devices in authentik, using the Endpoint Devices area of the admin interface. Use test accounts and a non-production host for the target. Record the device names and the users who will sign in. Done means both devices appear in the console with their expected identity. Rollback: remove the device records from the console, which leaves the hosts and authentik's core configuration untouched.
Install the authentik Agent on both hosts
The system administrator installs the authentik Agent on the source and the target, since SSH authentication requires the agent on both ends and the feature currently supports only Linux endpoints. Follow the agent installation steps in the Endpoint Devices documentation, enroll each host with its registration, and keep a note of the packages and service units added. Done means the agent reports as online for both devices in the console. Rollback: uninstall the agent package on the affected host and remove the device record, keeping a snapshot or backup of the host taken before installation.
Configure the SSH and sudo policy
The identity administrator creates a policy that limits which users and groups may sign in over SSH to the target, and defines whether sudo authorization is granted through authentik. Start with one pilot group and a narrow set of target hosts, and avoid granting sudo to the broad group at first. Review the SSH authentication documentation for the exact policy bindings and how sudo is handled. Done means the policy is bound to the target device and the pilot group only. Rollback: unbind the policy from the target, which returns that host to its existing login methods, and keep local break-glass accounts available throughout.
Verify allowed and denied SSH logins
The pilot tester signs in over SSH from the source host as a user inside the pilot group, then attempts the same from a user outside it. The first attempt should succeed, and the second should be refused by policy. Repeat a sudo command for the pilot user to confirm the authorization path works as the policy specifies. Done means both outcomes match the policy written in the previous step, and the results are recorded with timestamps. Rollback: if an allowed user is refused or a denied user gets in, unbind the policy and investigate with the local break-glass account open.
Check audit events and decide next steps
The security or compliance lead reviews the authentik event log for the successful sign-ins, the refused attempts and the sudo events produced during testing, and confirms each has the expected user, device and outcome. Confirm with your own control owners which evidence they need, since the pilot only shows that events are recorded and does not establish compliance. Decide whether to extend, pause or stop the pilot, weighing the early preview status documented for Endpoint Devices against your production requirements. Done means a written pilot report lists the results, the open issues and the decision. Rollback: if events are missing or incomplete, do not expand scope until the logging gap is understood.
Security and operational risks to plan for
Endpoint Devices is an early preview, so the risks cluster around change, the agent on every server, and what happens when authentik is unavailable. Plan each one before the first host is enrolled, and decide the fallback path while existing SSH keys still work.
Preview-stage change risk
The documentation marks Endpoint Devices as early preview and not recommended for production. Expect configuration names, agent behavior and supported flows to change between releases. Before go-live, ask authentik which parts are preview, read the release notes for each version you plan to run, and test sudo authorization and CLI logins on non-production hosts first. Record the exact version you validated.
Agent lifecycle on servers
SSH authentication requires the authentik Agent on both the source and the target Linux host. Each server therefore carries an extra component to install, patch, monitor and remove. Define who owns agent upgrades, how a failed agent is detected, and how a host is returned to plain SSH keys when it is decommissioned. Ask how the agent is packaged and whether it can be deployed through your existing configuration management.
Break-glass access if authentik is down
If authentik, the network path to it or the agent fails, administrators may be locked out of hosts they must reach during an incident. Keep at least one tested break-glass path that does not depend on authentik, such as a named emergency account with a hardware-stored key held under dual control. Document who may use it, how use is logged, and how access is revoked afterward. Test it on a schedule.
PostgreSQL dependency for server and worker
authentik stores all configuration and data except uploaded files in PostgreSQL, and both the server and the worker depend on it. The 2025.10 release moved caching, tasks, sessions and WebSocket functions from Redis to PostgreSQL and warned of roughly 50% more connections after upgrading. Plan connection limits, backups and failover for the database before enrolling production hosts. Use a separately managed PostgreSQL for production rather than the bundled chart database.
Keeping a fallback to existing SSH keys
Do not remove existing SSH keys, authorized_keys entries or sudo rules when a host is enrolled for authentik. Keep them in place until the authentik path has passed your acceptance tests, and keep a documented rollback that restores key-based access. Confirm with authentik how the agent interacts with existing key files and PAM configuration so that enabling or disabling it does not remove the fallback.
Security release timing
The security policy lists 2026.5.x and 2026.8.x as the supported release lines receiving security fixes, and the project announces security releases at least 24 hours in advance. Only the supported lines get fixes, so a host running an older line is exposed. Subscribe to release notices, assign a named owner to test and apply security releases within that 24-hour window, and check the version on every server and agent after each change.
Questions teams ask before running authentik Endpoint Devices
Can we run authentik Endpoint Devices in production today?
Not on the strength of the documentation alone. The authentik Endpoint Devices documentation marks the feature as early preview and not recommended for production, and it was introduced in 2025.12. Treat it as a candidate for a controlled pilot on non-critical hosts, and check the Endpoint Devices documentation for the current status before you set a production date. Confirm with authentik which release you will run, since the supported security versions listed in the security policy are 2026.5.x and 2026.8.x, and confirm whether the feature's status has changed by the time you plan the rollout.
Which Linux hosts and devices does SSH with the authentik Agent support?
SSH authentication with the authentik Agent currently supports only Linux devices as SSH endpoints. The agent must be installed on both the source and the target, so a workstation or server that is not Linux cannot yet be a target. Sudo authorization can also be handled through the agent. Before you commit to a design, inventory which hosts are Linux, which distributions and versions they run, and whether the agent install path fits your configuration management. Confirm current platform support for local device login and CLI authentication separately, because the SSH support statement does not cover those use cases.
What licensing do we need before a pilot starts?
Confirm the licensing position with authentik before the pilot. The repository places most code under the MIT license, while code in the enterprise directory uses a separate enterprise license. The authentik pricing page lists Open Source as free with community support on Discord, 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 with authentik whether Endpoint Devices features sit under the Enterprise license, since that determines the subscription you need for the pilot population. Ask for the license terms in writing and the exact user count the pricing model will apply to.
What drives the effort and cost of a pilot?
The main drivers are the number of hosts, how many distinct teams and access paths you test, and how much policy design the pilot needs. Costs split into one-time work (architecture, agent packaging, policy design, test plans, and runbooks) and recurring work (licensing, agent updates, and support). Ask any partner or internal team to break the quote into those parts, and to state which items depend on the Linux host count, which depend on identity group design, and which depend on the authentik release you choose. A fixed-scope written statement of work makes these drivers visible before work starts.
What must our team provide for the pilot?
Your team needs to supply a list of Linux hosts in scope with their distributions, access to the authentik instance and an administrator account, and the identity groups that will map to sudo rights and SSH access. You also need a named owner for each identity group, a test set of users with different roles, and a change window on each host for agent installation and rollback. Confirm whether your hosts can reach the authentik server from every network segment in scope, and whether your change process requires written approval for agent installs on production systems.
Can our own team run this pilot without a partner?
Yes, if your team has authentik administration skills, Linux operations experience and a test environment that matches production. Teams that already run authentik and manage Linux fleets with configuration management usually have the core skills, but the feature is in early preview, so expect to read release notes closely and to verify behavior yourself. A partner can take on the architecture, test plan and runbook, or review your design. Whichever route you choose, agree on who owns rollback, who approves policy changes and who watches the logs during the pilot.
How long does a pilot usually take?
No duration is supplied for this feature, so the timeline should come from your own plan and from the written scope of any partner. The length depends on the number of hosts, the number of identity groups and access paths, how many change windows you can use, and how long testing needs to run on each host type. Ask for a timeline that lists the test environment setup, the agent rollout waves, policy validation, and the exit criteria for moving from pilot to production. Confirm the exit criteria against the feature status in the documentation at that time.
How DeployOpen scopes and delivers authentik endpoint access
DeployOpen approaches authentik Endpoint Devices as a scoped engagement: we first confirm which hosts, devices and CLI tools are in play and whether the preview status fits your risk appetite. We then build, test and document the agent-based access path in your own infrastructure, with the handover and ongoing support agreed in writing before work starts.
How we scope
- We confirm which Linux hosts, devices and CLI tools (kubectl, AWS CLI) will use authentik credentials.
- We check that each target runs a supported Linux distribution and that the authentik Agent can sit on both source and target.
- We agree in writing whether the work uses Enterprise licensing and whether a preview feature is acceptable for production.
How we build
- We configure the authentik Agent, device registration and SSH authentication on a staging host before any production rollout.
- We test sudo authorization paths and local login fallback so a failed agent does not lock administrators out.
- We validate kubectl and AWS CLI sign-in against your existing clusters and accounts, with test users and groups.
How we hand over
- We deliver runbooks covering enrollment, revocation, agent upgrades and the steps to return to your existing SSH access method.
- We document the configuration, access policies and the evidence your team needs for internal reviews.
- We walk your operations staff through the build and the known limits of the preview feature.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, which we can scope against your version plan.
- We re-test the access path after authentik upgrades and before any feature moves from preview to wider use.
