Restricting sign-in to compliant devices in authentik
Yes, authentik can allow access only from managed, compliant devices, but that capability sits in its Enterprise edition. Teams that need this usually have a rule that sensitive applications may be opened only from company-managed laptops or browsers that the organization has verified. In authentik, conditional access means policies that are evaluated during login, using facts about the device to decide whether the sign-in proceeds. Those facts come from a connector to a device management or trust system, or from device data your own policies read. The Fleet and Google Chrome connectors were added in authentik 2026.5, and they are the two device-aware options to plan around first.
The core authentik project is licensed under the MIT license, but code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory. Before you design around these connectors, confirm with authentik which edition and license terms apply to your organization, and read the authentik Enterprise features documentation to see each connector's status. The Fleet connector is listed as preview, which affects how much you should rely on it for a production control. The Chrome connector is described for device-aware access decisions and depends on Chrome Enterprise Device Trust, so the browser fleet itself must be configured for that trust model.
Start with a written list of the device facts your access rule needs, such as whether the device is managed, enrolled, or certified by a specific authority. Then check which connector can supply each fact, and what happens for users on unmanaged or personal devices. Decide whether the rule blocks access outright or only steps up to additional verification. Confirm the Fleet certificate and mTLS stage requirements in your environment with a test user before you apply the policy to a whole application group.
Which device signal fits your fleet
authentik offers two Enterprise connectors that bring device state into access decisions, and they draw on different sources of truth. Your choice depends on what your devices already report and which signal your access policies need to trust.
Fleet connector through an mTLS stage
The Fleet connector verifies a device by the Fleet certificate it presents, enforced through a mutual TLS stage in authentik. No authentik agent is needed on the device, which matters if you cannot deploy additional software to endpoints. The connector is listed as preview, so confirm with the vendor which Fleet versions and certificate setups it supports before you depend on it. Check that your Fleet deployment already issues device certificates to the machines you need to cover.
Chrome Enterprise Device Trust connector
The Google Chrome connector uses Chrome Enterprise Device Trust through the Chrome Verified Access API to make device-aware access decisions. It applies only where users reach applications through Chrome on managed devices, so browsers outside that scope fall outside the check. Confirm that your Chrome Enterprise management and device trust configuration is in place, and test which signals reach authentik for each device class you support.
Certificate status is not posture
A Fleet certificate proves that a device was enrolled and holds a valid credential. It does not prove that disk encryption is on, that the operating system is patched, or that a screen lock is active unless your own Fleet policies enforce those checks and feed them into the decision. Write down which posture checks your access rules actually require before you choose the signal.
Browser context is not full device health
The Chrome signal describes the managed browser session and the device that runs it, which covers access made through Chrome. It does not cover SSH sessions, command-line tools, native desktop clients or unmanaged devices. If users reach internal systems through other paths, plan separate controls for those paths rather than assuming the browser check covers them.
Enterprise licensing and scope
Both connectors are Enterprise features, and the code under the enterprise directory uses a separate license from the MIT-licensed core. Ask your authentik contact which edition and license terms cover each connector, and confirm the per-user pricing components on the pricing page before you assume a device signal is available in your current plan.
Device facts in expression policies
Device facts from either connector can be evaluated in expression policies that decide whether a flow or application proceeds. Map each required fact to a policy and a fallback action, such as step-up MFA or denial with a clear message. Test each branch with a device that fails the check, since a missing fact and a failed fact should lead to different outcomes.
Device signal options and when each fits
This table compares the four ways to bring device state into an authentik access decision: the Fleet connector, the Chrome Enterprise Device Trust connector, expression policies that read device facts, and mTLS client certificate stages. Read each row against your fleet, your device management tooling and the access decision you need to make. Confirm current preview status and platform coverage with authentik before you commit a design.
| Option | What it checks | Enterprise requirement | Maturity status | Best fit |
|---|---|---|---|---|
| Fleet connector | Device identity through Fleet-issued certificates verified by an mTLS stage, with no authentik agent on the device | Enterprise license, per the authentik Enterprise features page | Preview, per the authentik Enterprise features page | Organizations already managing endpoints with Fleet that want certificate-based device checks without installing an agent |
| Chrome Enterprise Device Trust connector | Device signals from Chrome Enterprise Device Trust through the Chrome Verified Access API, used for device-aware access decisions | Enterprise license, per the authentik 2026.5 release notes | Listed on the Enterprise features page for device-aware access decisions; confirm current status with authentik | Browser-centric access to web applications on managed Chrome devices within a Google-managed device estate |
| Expression policies using device facts | Whatever device facts your upstream or connector data exposes to the policy engine, evaluated per application or flow | Confirm which Enterprise features your facts depend on before design | Confirm with authentik; depends on the facts available in your configuration | Custom rules that combine device facts with user group, network or risk context |
| mTLS client certificate stage | Presence and validity of a client certificate issued by a CA you trust, presented during the flow | Enterprise license, per the authentik pricing page listing mTLS client certificate authentication | Confirm current status with authentik | Environments with an internal CA that already issues device or smart card certificates |
| Reverse proxy certificate forwarding | Whether the certificate reaches authentik intact, which depends on the proxy configuration in front of authentik | Depends on your proxy and mTLS setup | Not a product feature; a design dependency | Any mTLS-based option, since a misconfigured proxy blocks the certificate before the policy runs |
Setting up device-based conditional access step by step
This sequence takes you from confirming licensing and versions to a tested policy that admits compliant devices and blocks unmanaged or non-compliant ones for a chosen application. Each step ends with a check you can record before moving on.
Confirm Enterprise licensing and supported version
Before any configuration, confirm with authentik that your subscription covers the Fleet and Google Chrome conditional access connectors and the mTLS stage, since the authentik pricing page lists mTLS client certificate authentication as an Enterprise-only feature. Then confirm your running version is on a supported line, 2026.5.x or 2026.8.x, according to the authentik security policy. Ask your vendor contact whether the Fleet connector is still in preview for your subscription, because the authentik Enterprise features documentation lists it as preview. You know this step is done when you have a written license confirmation and the version shown in your administrator interface matches a supported line.
Prepare the device management side
Your device management platform must issue the trust signal that authentik will check. For the Fleet connector, devices need Fleet-issued certificates, and authentik verifies them through an mTLS stage without requiring an authentik agent on the device. For the Google Chrome connector, browsers must be enrolled in Chrome Enterprise so that Chrome Enterprise Device Trust, through the Chrome Verified Access API, can attest device state. Platform administrators own this work, and authentik administrators should agree with them on which device attributes count as compliant. You know this step is done when a test device presents a valid signal and the platform console shows it as managed and compliant.
Add the connector or mTLS stage to the flow
In the authentication flow that guards the target application, add the stage that matches your device source: the mTLS stage for Fleet certificates, or the Google Chrome conditional access connector for Chrome Enterprise. Set the stage so it runs before the access decision and confirm the trusted certificate authority or connector configuration with the platform team. Keep the original password or MFA stages in place so that device checks add to, rather than replace, user verification. You know this step is done when a preview of the flow shows the new stage in the expected position and a saved configuration loads without errors.
Write expression policies against device facts
Create expression policies that read the device facts the connector supplies, such as certificate validity, managed status or the compliance result reported by the platform. Start with a single rule that allows only devices reporting compliance, and write the deny path explicitly so that a missing fact does not default to access. Document each expression and the fact it depends on, since the field names come from the connector output and should be verified in your own environment. You know this step is done when each policy evaluates to true for a known compliant test record and false for a known non-compliant one in the policy test view.
Bind policies to the target application
Attach the device policy to the application or its provider binding so that it is evaluated on every sign-in to that application, and decide whether it also applies to a broader group of applications. Set the binding order so that the device policy runs after identity checks but before the session is granted. Confirm that other applications in the same tenant are unaffected unless you intended a wider rollout. You know this step is done when the binding list for the application shows the policy in the correct order and an unrelated application still signs in as before.
Test with compliant, non-compliant and unmanaged devices
Test three cases end to end: a compliant managed device, a managed device that fails compliance, and an unmanaged device with no certificate or enrollment. Each should reach the outcome your policy defines: access granted, denial, and denial respectively. Use a test user who is not an administrator so that administrator bypass does not hide problems. Review the authentik event log for each attempt to confirm the decision and the facts used. You know this step is done when all three outcomes match the written expectation, and the logged decisions are saved as evidence for your change record.
Using device facts in expression policies
Device facts from a connector become useful when they feed an expression policy bound to a specific application, so each app can decide access on its own terms. An expression policy evaluates a Python-style expression against the request context, and device data from the Fleet or Chrome connector can be read there alongside the user's groups, MFA state and network context. The key design choice is to combine signals deliberately: for example, requiring membership in a finance group, a completed second factor, and a device that the connector reports as compliant, with each condition checked separately so a failure is easy to explain. Confirm the exact attribute names that each connector exposes in your authentik version, because the Enterprise features documentation and the release notes describe the connectors at a higher level than the field-level reference. Do not copy attribute names from older examples or community posts without checking them against your running instance.
Write and test policies in a test flow before they touch production sign-in. Bind the policy to a test application or a dedicated test group, run the flow with a managed device, an unmanaged device, and an account that should be denied, and record which stage made each decision. Turn on logging for policy results and review the event log for each test case, so you can show an auditor or colleague why a request was allowed or refused. Keep the policy's expected outcomes in a short document next to the flow definition, because the same expression will be revisited during upgrades and when a connector changes status. Treat connector preview status as a reason for caution on any app that cannot tolerate a lockout.
Before you enforce a device rule, document a fallback path and test it. A break-glass account that is excluded from device-based policies, stored offline, and reviewed on a fixed schedule is the usual minimum, along with a written procedure for who can use it and how the use is recorded. Confirm that this account can still reach the admin interface if the Fleet certificate chain, the mTLS stage or the Chrome Verified Access check fails. Ask your implementation partner or your own team to rehearse a denial scenario on a non-production instance first, and to confirm how long recovery takes in your environment, since no duration is set by the vendor for this path.
Security risks in device-based access control
Device-based access control adds a second decision on top of the password and MFA check: whether the device itself is trusted. Each risk below comes from that extra signal, the certificate or agent behind it, or the release process that keeps the controls working.
Trusting device signals you do not control
A conditional access rule is only as strong as the device fact it reads. If the device management system reports a device as compliant when its agent is stale, misconfigured or never enrolled, the policy will allow access on bad data. Before relying on a connector, confirm which system asserts the device state, how often that state refreshes, and what happens when the signal is missing. Treat a missing signal as a denial, not a pass.
Lockout when certificates expire
Device certificates and client agents have their own lifecycles. When a certificate expires or an agent stops reporting, legitimate users can be locked out of applications they need, often on a Monday morning with no obvious cause. Build a renewal calendar for every certificate authority and device credential in the flow, alert on upcoming expiry, and agree an approved break-glass path before the first production rollout.
Certificate trust chain and proxy forwarding
The mTLS stage only works if the client certificate reaches authentik intact and the issuing certificate authority is trusted. A reverse proxy that terminates TLS and drops or rewrites the client certificate headers will make every device look unverified, or worse, let a request through with the wrong identity. Test the full path with a certificate from each issuer you accept, including revoked and expired certificates, and record the proxy configuration as part of the change.
Preview features in production
The Fleet connector is listed as preview in the Enterprise features documentation, so its behavior, configuration fields and upgrade handling may still change. Running it as a hard gate for production logins adds risk that a minor change in a later release blocks users. Decide which applications may depend on a preview connector, pilot it on a limited group, and keep a documented fallback policy.
Keeping authentik on a supported version
Device checks depend on current code paths, and only supported versions receive security fixes. Confirm your running version appears in the security policy list of supported releases before you enable any device connector, and plan upgrades so you do not fall behind. The project announces security releases at least 24 hours in advance, so the on-call rota should have a named owner who can schedule that window.
Monitoring policy denials and audit evidence
A denied login caused by a device rule looks like a generic access failure unless your logs record which policy and which device fact caused it. Forward authentication events to your log platform, track denial rates per application and per policy, and keep the records that show a device decision was made under an approved rule. Ask your auditors which evidence they expect before you design the log retention period.
What Enterprise licensing changes for device checks
Enterprise licensing decides which device checks you can use. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. The same page lists mTLS client certificate authentication as Enterprise-only, so a Fleet connector that depends on an mTLS stage cannot be planned as a free feature. Before you design around it, ask your authentik contact or check the authentik pricing page to confirm which edition includes each connector, and whether the Chrome Enterprise Device Trust connector sits in the same tier as the Fleet connector. Do not assume that a connector listed on the features page is available on the Open Source edition.
Licensing also has a code-level dimension. Most of the authentik repository is under the MIT license, but code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory. If your team plans to modify, fork or redistribute device-check logic, read both license texts in the authentik LICENSE on GitHub file and the enterprise directory before you build. Legal and procurement teams should review those terms alongside the commercial order, since a subscription governs use of the product while the license governs what you may do with the source.
Two practical checks follow. First, confirm in writing which edition, user counts and external user counts your quote covers, because per-user and per-external-user pricing scales with the population that signs in. Second, if the Fleet connector is still labeled preview in the release you select, record that status in your risk register and decide whether a preview feature may gate production access. Ask for the license terms and the edition matrix in the quote so the device-check design rests on what you have actually purchased.
Questions teams ask before device-based access
How much does device-based access in authentik cost?
Device-based access in authentik sits behind the Enterprise license, so the license is the main recurring software cost. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. The Fleet and Google Chrome connectors and the mTLS stage are Enterprise features, so confirm with authentik which edition covers your user counts. Implementation effort is a separate one-time cost, driven by how many device signals you use, how many applications need the check, and how much your device management platform already provides. Ask for a fixed-scope quote that lists each connector and application separately.
What drives the price of an authentik device compliance pilot?
The pilot cost depends on scope more than on the connector itself. The main drivers are the number of applications in the pilot, whether a device management system such as Fleet already issues the certificates you need, how many device states you must evaluate, and how many user groups take part. Each added application adds policy design, testing and rollback planning. Ask for a written scope that names the connector, the test applications, the device groups, the success criteria and what happens if a device fails the check. A pilot can usually be scoped to one application and one device group, which keeps effort and risk low.
How long does a device compliance pilot take in authentik?
The duration depends on how ready your device data is, not on authentik alone. A pilot runs faster when a device management platform already issues certificates or reports device facts, and when the application owners are available to test. Delays usually come from certificate authority decisions, from agreeing which device attributes count as compliant, and from testing unmanaged devices. The Fleet connector is listed as preview, which can add time for validation. Ask for a timeline with named milestones and a go or no-go decision point, and confirm the timing for your own environment before committing.
What does the client need to provide for device-based access?
You need to provide three things before the build starts. First, a device management source, such as Fleet for certificates or Chrome Enterprise device management for Google Chrome, with an inventory of which devices are enrolled. Second, a certificate authority that issues and revokes device certificates and whose trust chain authentik can use in the mTLS stage. Third, named application owners who can confirm which applications should require a compliant device and who will test sign-in. Missing any of these usually stalls the work. Confirm each item with your device and certificate teams early.
Can our internal team set up device-based access without a partner?
An experienced identity team can build a basic setup alone, provided it has the skills and time. The work requires knowledge of authentik flows and policies, mTLS and certificate trust, your device management platform, and the applications being protected. Teams with prior authentik deployments often handle the core configuration in-house and bring in outside help for the riskiest parts, such as the certificate chain, the reverse proxy configuration and the rollback plan. Decide on the split by listing which skills are missing and how many people can give the project time. An independent assessment of your plan can also help.
Does device-based access replace our VPN or MDM?
No. Device-based access in authentik decides whether a signed-in user's device meets a condition before an application grants access. It does not create a network tunnel, so a VPN or zero-trust network access product may still be needed for network reachability. It also does not manage devices, push configuration, patch operating systems or wipe lost hardware, which remains the job of your mobile device management or endpoint management platform. Many teams keep their VPN and MDM and use authentik to enforce device conditions at the application layer. Confirm which network paths and device controls each application depends on before deciding what to retire.
How should we handle a preview connector in production?
Treat a preview connector as a component you validate and monitor, not one you assume is stable. The authentik Enterprise features documentation lists the Fleet connector as preview, so confirm its current status, supported versions and known limitations with authentik before relying on it for production access. Keep a fallback sign-in path for a documented period, pilot the connector on a limited application set, and set alerts on failed device checks. Review the release notes with each upgrade, since authentik versions are named by year and month and changes can affect policies. Ask your provider which parts of the connector may change before general availability.
Where to read the current documentation
Before you commit to a device compliance design, read the authentik 2026.5 release notes for the release that added the Fleet and Google Chrome connectors. The notes describe what each connector checks and how it was introduced, which is the starting point for deciding whether the Fleet mTLS stage or the Chrome Enterprise Device Trust path fits your device estate.
Then read the Enterprise features page, which states the maturity of each connector. At the time of research, the Fleet connector was listed as preview, so confirm whether it is still preview before you make it a control that auditors or users depend on. Ask your authentik contact or check the project's current documentation for any change in status, supported device sources, or licensing terms.
Treat both pages as a snapshot taken on the day you read them. Record the authentik version you plan to run, check it against the supported version list in the security policy, and re-read the connector status and release notes immediately before your design review and again before go-live. A feature that is preview today may change in a later release, and your access policies should be tested against the version you will actually deploy.
How DeployOpen scopes and delivers device-based access
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For device compliance and conditional access, we start by confirming which device signals your policies need, which connector and licensing path fits them, and how access decisions will be verified before any build begins.
How we scope
- Confirm which access applications must be restricted to compliant devices and what each one requires.
- Confirm the device signal source, such as Fleet certificates or Chrome Enterprise Device Trust, and whether it is available in your environment.
- Agree in writing on Enterprise licensing needs, connector preview status and any fallback access path.
How we build
- Configure the mTLS stage, device facts and expression policies in a non-production authentik instance first.
- Test allowed and denied sign-ins from managed and unmanaged devices, including expired or revoked certificates.
- Document each policy, its device conditions and its rollback steps so your team can change them safely.
How we hand over
- Deliver configuration, test records and runbooks for the device checks and the conditions they enforce.
- Walk your identity and endpoint teams through how device signals are verified and where they can fail.
- Record which items remain your responsibility, such as device enrollment and certificate issuance in your MDM or fleet tooling.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover re-testing conditional access rules when authentik releases or connector behavior changes.
- Ask for a written quote that lists scope, deliverables, timeline and support terms before work starts.
