When smart card login with authentik fits your access model
Choose certificate-backed sign-in when your users already hold credentials that prove identity more strongly than a password, such as PIV cards, CAC-style badges, managed device certificates or hardware tokens. authentik handles this through its Mutual TLS stage, which authenticates or enrolls users with those certificates. This capability is an authentik Enterprise feature, so the Open Source edition does not include it. Budget for an Enterprise license before you design the flow, and confirm the current terms on the authentik pricing page.
Certificate login fits best where a password plus MFA is not enough for policy reasons: privileged administrators, regulated workforces that issue smart cards, or environments where hardware-bound credentials are already the access standard. For general staff and external users, passwords with phishing-resistant MFA may be simpler to run and support. Ask your security team which populations are mandated to use a card or certificate, and which only need stronger assurance, before you decide which applications get the certificate path.
The work depends less on authentik itself than on the trust chain around it. You need a clear list of issuing certificate authorities, a decision on how revocation is checked, and a reverse proxy that terminates TLS and forwards the client certificate details to authentik in a form it can verify. Each of these is a separate configuration point that can silently fail, so plan test users, a rollback path and a set of rejected-certificate cases before go-live. Confirm the proxy and CA details against your own environment during scoping, because they vary by deployment.
Which certificate login option fits which population
Employees who already hold a government-issued PIV or CAC card usually have a certificate on the card from an issuing authority that your organization does not operate. In this case the question is authentication, not enrollment: authentik needs to trust the issuing certificate authority and check that the presented certificate belongs to the user it claims to be. Confirm with your card issuer which certificate chains the cards carry and whether revocation status is available to your reverse proxy.
- Certificate source: the card's authentication certificate, issued outside your environment.
- Enrollment: usually none, but confirm which certificate policy the cards use.
- Trust setup: import the issuing CA chain into the Mutual TLS stage configuration.
- Fallback: a password plus a second factor that the card holder can use if the reader or middleware fails.
- Identity mapping: confirm which certificate field maps to the authentik username before rollout.
Check that the fallback method is available to every cardholder without a card, such as during travel or a reader outage.
Corporate laptops and phones can carry a certificate issued by your own internal certificate authority, typically pushed by a device management tool during enrollment. Here the certificate is part of your environment, so you control its issuance, lifetime and revocation. Enrollment of the device certificate is a separate project from the authentik configuration and should be planned with the team that runs your device management and PKI.
- Certificate source: an internal CA, distributed to managed devices by a management platform.
- Enrollment: required, and it should happen through a managed process rather than by users.
- Trust setup: trust the internal root or intermediate CA in the Mutual TLS stage.
- Fallback: a second factor and a recovery path for lost or wiped devices.
- Lifecycle: plan renewal and removal when a device leaves the fleet.
Confirm which device management product delivers the certificate and whether it can be revoked from the same console.
Contractors, partners and other external users rarely hold cards from your issuing authority, and they may use personal or vendor-owned devices. Issuing them certificates from your internal CA extends your trust boundary to people you do not employ, so this population needs a deliberate decision on whether certificate login applies at all. Many organizations keep certificate login for employees and use stronger standard second factors for external users.
- Certificate source: either a dedicated external CA or a card from the contractor's sponsoring organization.
- Enrollment: needed only if you issue certificates, which requires identity proofing and an expiry date.
- Trust setup: a separate CA chain, scoped to specific applications where possible.
- Fallback: standard passwords with a one-time code or hardware key, governed by the flows and policies you configure.
- Sponsorship: name the internal owner who approves each external account.
Confirm your contract terms allow the sponsoring organization's card or device to be used for authentication.
Some users authenticate with a hardware token that holds a certificate, such as a USB or NFC token that stores a private key. These tokens are often issued to privileged staff or to users who cannot use a company device. Enrollment is typically handled by a token administrator, and the token is tied to a specific user and a specific certificate. Loss handling and replacement are the main operational concerns.
- Certificate source: a certificate generated on or loaded onto the token by your PKI team.
- Enrollment: required, with a documented procedure for issuing and revoking tokens.
- Trust setup: trust the CA that issued the token certificate in the Mutual TLS stage.
- Fallback: a spare token held by the user's manager or a second registered device.
- Replacement: define how a lost token is revoked and how the user is re-enrolled.
Confirm whether the token vendor's middleware is supported on every client operating system your users run.
Mutual TLS stage settings and when each fits
This table compares the main Mutual TLS stage decisions: the trusted CA bundle, certificate validation, user matching, enrollment versus authentication behavior, and which flow the stage sits in. Read each row as a choice you make before go-live, and confirm the exact setting names and options in the release you deploy, since the stage configuration can change between versions.
| Decision | Trade-off | When to choose it |
|---|---|---|
| Trusted CA certificate bundle | A narrow bundle limits who can authenticate but breaks when an issuing CA rotates; a broad bundle is easier to run but accepts more certificates than you intend. | Use only the issuing CAs for your PIV, smart card or device certificates, and confirm how the stage handles intermediates and chain order in your release. |
| Certificate validation mode | Stricter checks such as revocation and chain validation reduce misuse of stolen or retired cards but add dependencies on CRL or OCSP reachability. | Choose strict validation for privileged or regulated applications. Confirm which revocation options the stage exposes and how it behaves when a responder is unreachable. |
| User matching attribute | Matching on a certificate field such as the subject or a UPN-style value is simple but depends on how your PKI populates it; matching on an identifier you control is more stable but needs a mapping step. | Match on the attribute your PKI guarantees is unique and stable for each person. Test with real issued certificates before rollout, and confirm the attribute options available in your release. |
| Authentication versus enrollment behavior | Authentication only keeps the stage simple and avoids issuing new bindings; enrollment lets users register a certificate on first use but needs stronger controls around who can bind which certificate. | Use authentication for users whose certificates are already issued through your PKI. Use enrollment only when your policy allows users to bind their own device or token, and pair it with an approval or identity check. |
| Stage placed in the login flow | Placing the stage in login gives certificate sign-in as a primary or alternative factor, but a misconfigured flow can lock out users who rely on other methods. | Use for smart card users who sign in directly. Keep a tested fallback path and confirm how the stage combines with password or other stages in the flow order. |
| Stage placed in the enrollment flow | Enrollment placement lets you bind certificates during onboarding or device setup, which adds an extra step for new users and needs a clear owner for the enrollment process. | Use when certificates are issued during joiner onboarding and you want the binding recorded at account creation. |
| Stage placed in the recovery flow | Recovery placement can give a second route to re-establish access, but it also creates a path that an attacker might target if certificate checks are weak. | Use only when your recovery policy explicitly accepts certificate-based identity proof. Review the recovery flow's other stages and confirm the audit events it produces. |
| Enterprise licensing check | Mutual TLS client certificate authentication is an Enterprise feature, so the design must budget for the subscription before the stage is available in production. | Confirm the license tier and feature availability with authentik before committing to the design. Open-source editions do not include this stage. |
Setting up client certificate login step by step
This sequence takes a team from an Enterprise license check to a tested login path where users present a certificate from a device, smart card, PIV card or hardware token and authentik verifies it before granting access. Each step ends with a check you can record as evidence.
Confirm the Enterprise license and edition
The platform or security lead confirms that the deployment runs an edition that includes the Mutual TLS stage, since client certificate authentication is listed as an authentik Enterprise feature. Check the license terms against the enterprise license file in the authentik/enterprise/ directory, which is licensed separately from the rest of the MIT-licensed code, and confirm the edition with your account contact. The step is done when the license entitlement is recorded and an administrator can open the Mutual TLS stage type in the admin interface. If the stage is missing, stop here and resolve licensing before building anything else.
Build the CA trust chain and revocation approach
The PKI owner assembles the certificate authorities that issue user credentials, including any intermediate CAs, and decides how revoked certificates are detected. Document which issuers are trusted for login, who owns each one, and how revocation status will be checked, whether through a certificate revocation list or an online responder. Confirm the exact certificate and revocation settings with your authentik release notes and the Mutual TLS stage documentation before you configure them. The step is done when the trust chain is exported as a reviewed bundle and the revocation method is written down with an owner.
Configure the Mutual TLS stage
An authentik administrator creates a Mutual TLS stage and points it at the trusted CA bundle from the previous step. Set how the stage handles certificates that are missing, invalid or unrecognized, and decide whether it authenticates an existing user, enrolls a new one, or both. Keep the stage settings in version control if your team manages configuration as code. The step is done when the stage saves without errors and its settings match the approved design document.
Bind the stage into a login flow
The administrator adds the Mutual TLS stage to an authentication flow and binds it to the applications or brands that should accept certificate login, with a fallback path for users who cannot present a certificate. Place it so that policies and any second factor still run after the certificate check, and test the order of stages in a non-production tenant first. The step is done when a flow preview shows the stage sequence you designed and a non-production user reaches the expected next stage.
Configure the reverse proxy to forward certificate data
The network or platform team configures the reverse proxy in front of authentik to request a client certificate during the TLS handshake and to pass the certificate details to authentik in a header that authentik is set to read. Only the proxy should be able to set that header, so strip any copy supplied by clients. Confirm the header name and trust settings against the authentik deployment documentation for your proxy. The step is done when a request with a valid test certificate reaches authentik and the flow log shows the certificate was received.
Test with each certificate type
The test team runs login attempts with each credential type in scope: a device certificate, a smart card or PIV card certificate, and a hardware token certificate, each issued by a trusted CA. Record the outcome and the event log entry for every attempt. The step is done when every in-scope type authenticates or enrolls as designed and the results are filed with the change record. Repeat this step after each authentik upgrade or CA change.
Verify rejection of revoked and untrusted certificates
Run negative tests before go-live: a certificate that has been revoked, a certificate issued by an untrusted CA, an expired certificate, and a request with no certificate at all. Each attempt should be refused or routed to the fallback path, and the event log should show the reason. Keep these results as evidence that the trust chain and revocation checks work as documented. The step is done when every negative case fails as designed and the failure reasons match the test plan. Any unexpected success blocks go-live until the trust bundle or revocation setting is corrected.
Why reverse proxy certificate forwarding breaks most deployments
The client certificate is usually validated before authentik ever sees it. In most deployments, TLS terminates at a load balancer or reverse proxy, so the proxy is the component that requests the client certificate during the handshake. authentik's Mutual TLS stage can only evaluate a certificate that reaches it, which means the proxy must be configured to request the certificate, validate it against your CA bundle, and pass the result to authentik in a request header or an equivalent mechanism. If any link in that chain is missing, users see a login failure that looks like an authentik problem but is really a proxy problem. Plan the proxy work as a separate build step with its own tests, not as a footnote to the authentik stage configuration.
The forwarded header is the most common security gap. If authentik accepts a certificate header from any client that can reach it, an attacker can send a forged value and skip the smart card entirely. Your proxy must strip any incoming copy of the header from external requests and set it only after its own validation, and authentik must be reachable only through that proxy, not directly on a network path that bypasses it. Keep the trust relationship explicit: the CA bundle used by the proxy and the trust settings configured in authentik should come from the same source of truth, and you should record who owns each. A mismatch here tends to surface after a CA rotation or a new card issuer is added.
Before go-live, confirm the exact header name, encoding and certificate format for your specific proxy and authentik version, because these details differ between products and releases. Check the Mutual TLS stage and enterprise feature documentation in the authentik Enterprise features documentation, then test with real cards from each issuer population you support, including an expired certificate and one from an untrusted CA. Ask your proxy vendor and the authentik release notes for the version you run to confirm the forwarding format, and rerun these tests after every proxy or authentik upgrade.
Security controls for certificate-based sign-in
Certificate sign-in moves trust from passwords to the certificate chain, the reverse proxy and the card or token that holds the key. Each control below is a configuration decision you make before users depend on the Mutual TLS stage, and each one is worth reviewing with your security team before rollout.
CA trust scope and intermediates
The Mutual TLS stage only accepts certificates that chain to the authorities you trust, so the trust bundle defines who can sign in. Include only the issuing CAs your badge or PIV program actually uses, and confirm whether intermediate certificates must be bundled with the client certificate or whether the chain is presented by the device. An overly broad bundle, such as a root that also issues certificates to outside parties, widens the sign-in population without anyone noticing. Ask your PKI team to document each CA in the bundle and its owner.
Revocation checking
A valid chain alone does not prove a card is still in use. Decide how revoked or lost credentials are caught, whether through certificate revocation lists, OCSP responses or a short re-issuance cycle, and confirm which of these your authentik version and stage configuration support. Test with a deliberately revoked test certificate before go-live. Without a tested revocation path, a terminated employee's card may keep working until the certificate expires.
Protecting forwarded certificate headers
When a reverse proxy terminates TLS and passes the client certificate to authentik in a header, anyone who can set that header can impersonate a certificate holder. Limit the proxy to forwarding the header only on the path that needs it, strip any copy supplied by the client, and make sure authentik only reads the header from the proxy's address. Verify this with a request that carries a forged header from outside the proxy. The exact header names and trust settings depend on your proxy and should be confirmed against the authentik configuration reference.
Key storage on PIV and hardware tokens
The security of the sign-in depends on the private key never leaving the card or token. Confirm that your smart cards or hardware tokens generate and hold keys on the device, that PIN policies lock the card after repeated failures, and that the certificates your users present are the ones issued to that hardware. Ask the card vendor or issuing agency which key algorithms and PIN retry limits apply. Copies of certificates on laptops or in shared storage turn a hardware factor into a file that can be stolen.
Fallback path abuse
A certificate stage that sits beside a password or one-time code path gives attackers a second way in if the weaker path is easier to reach. Review the flow bindings so that certificate sign-in is either required for the groups that need it or applied with policies that define when fallback is allowed. Restrict self-service enrollment of new certificates to controlled events, and confirm which users can reset factors. Test each fallback path as an attacker would before go-live.
Logging certificate events for audit
Auditors will ask who signed in with which certificate, when, and what happened when a certificate was rejected. Confirm that authentik's event log records the Mutual TLS stage outcomes and the certificate identifiers involved, then forward those events to your central log platform with retention that matches your policy. Test that a rejected attempt and a successful attempt both produce a traceable record. Check the enhanced audit logging edition requirements before you rely on it for evidence.
Questions buyers ask about smart card login with authentik
Does authentik Open Source support smart card and client certificate login?
No. Authentik documents client certificate authentication through the Mutual TLS stage as an Enterprise feature, so the Open Source edition does not include it. The pricing page lists mTLS client certificate authentication among the Enterprise-only features. Before you plan around it, confirm the current feature list against the authentik Enterprise features documentation and your own license terms, because the code under the enterprise directory is covered by a separate license from the MIT-licensed core.
What does authentik Enterprise cost for our number of users?
The authentik pricing page lists Enterprise at $5 per user per month, billed annually, plus $0.02 per external user per month. Multiply those rates by your user counts to get the subscription estimate, and confirm with authentik how it counts users and external users. Enterprise Plus starts at $20k annually and adds dedicated support with SLAs, multi-instance support and FIPS compliance for FedRAMP requirements, so check whether you need those extras. DeployOpen does not publish prices. Its work is quoted from a written scope that covers planning, CA trust, proxy configuration, testing and handover, and that quote is separate from the authentik subscription.
How long does smart card login take to set up, and what drives the effort?
Duration depends on how many certificate sources you have, how many applications sit behind the reverse proxy, and how mature your PKI is. The main effort drivers are: the number of certificate authorities in the trust chain, whether revocation checking is available to the proxy, how many user populations (employees, contractors, devices, hardware tokens) use different profiles, and how many applications need to accept the authenticated identity. DeployOpen provides a timeline in the written scope after reviewing these factors in your environment. Ask for the assumptions behind any timeline so you can check them against your PKI team's availability.
What must our team provide before the engagement starts?
Expect to provide several inputs:
- The full CA chain, including intermediate and root certificates, and the trust relationships for each issuing authority
- The certificate profiles and extended key usage settings that identify smart card, PIV or device certificates
- Revocation information (CRL or OCSP endpoints) and the network paths the reverse proxy needs to reach them
- Access to the reverse proxy or ingress that forwards client certificate details to authentik, with a change window
- Test cards, tokens and devices for each user population, plus a test user group in authentik
Confirm whether your PIV or smart card middleware is supported on each client platform.
Can our own team run smart card login after the engagement?
Yes, if the team owns the right skills and the work is documented. Running it day to day needs people who can manage the PKI, renew and revoke certificates, update the CA bundle when issuers change, and check the reverse proxy forwarding configuration after upgrades. Authentik also changes between releases, so your team needs an upgrade routine that retests certificate login. DeployOpen can plan, implement, document and hand over the configuration, and it can provide ongoing support and upgrades under a retainer if your team prefers a partner for that work. Decide ownership for each task in the written scope.
What are the main security risks in certificate-based login?
The most common risks come from trusting the wrong issuers, accepting certificates that were revoked, and losing the identity mapping between the certificate and the user account. Each of these can give access that should have been denied. Reduce the risk by limiting the trust store to the issuers you control, enforcing revocation checks where your design supports them, mapping certificates to users with explicit attributes, and logging each authentication stage. Also confirm how the reverse proxy strips or forwards certificate headers, because a misconfigured proxy can let clients spoof them. Test these cases before go-live.
Does smart card login help with compliance requirements?
It can support access control and strong authentication requirements, but it does not create compliance on its own. Frameworks such as NIST SP 800-53 describe controls that an assessor reviews as part of a system authorization, and the evidence for those controls comes from your configuration, logs and processes. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor which control IDs your certificate login design should be mapped to before you finalize the scope.
How certificate login relates to federal and sector requirements
Certificate login rarely becomes mandatory because of a single product feature. It usually enters the design when a regulation or customer contract names strong authentication or cryptographic controls that the rest of the identity stack must meet. Three frameworks commonly shape that decision: the control catalog in NIST SP 800-53 Rev. 5, the baselines in NIST SP 800-53B, and the scope rules of FedRAMP or CMMC for any cloud service that handles federal or defense information. Start by asking which of these apply to your organization and which systems fall inside the boundary. A federal, defense or criminal justice customer may need certificate-based authentication for specific applications while leaving others on passwords with MFA.
The cryptography requirements are often the part that changes the build. The FBI CJIS Security Policy version 6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits for criminal justice information in transit and at rest outside physically secure locations. Confirm with your assessor which modules and TLS configurations they accept on the reverse proxy and in the authentik server, because certificate validation depends on the same stack. FIPS-related needs are an item on authentik's Enterprise Plus tier, according to the authentik pricing page, so confirm that tier and its terms in writing before you plan around it.
DeployOpen prepares the system, configuration and evidence that an assessment will examine, such as certificate authority trust settings, Mutual TLS stage bindings, access policies, logging and scan records. Independent auditors, assessors and certification bodies decide whether your environment meets a requirement, and this page does not claim compliance with any framework. Before scoping work, document which controls the certificate design is intended to support, which evidence each control owner will need, and which parts of the design sit outside the authentik boundary. Those answers determine how much of the work is configuration and how much is documentation.
How DeployOpen scopes and delivers certificate login
The sequence starts with a written scope that confirms the certificate sources, the Enterprise license and the proxy path, then builds and tests each certificate type before handing over trust and forwarding documentation. The result is a certificate login flow your team can run and verify without relying on memory of the original build.
Confirm the certificate use cases and sources
Before any configuration, DeployOpen works with your security and identity leads to list which credentials must sign in or enroll: managed device certificates, smart cards, PIV cards or hardware tokens. For each one, we record the issuing certificate authority, who owns it, and which applications the login protects. The step closes with a written use case register that names every certificate type in scope and the systems that will accept it.
Discover CA chains and the reverse proxy path
DeployOpen inspects the existing certificate authority hierarchy, including intermediates, revocation endpoints and the root certificates your clients trust. We also map how requests reach authentik, including the load balancer or reverse proxy, TLS termination points and whether client certificate details can be forwarded to the authentik server. The step closes with a discovery record listing each CA, each hop and each point where the client certificate could be lost.
Confirm Enterprise licensing for the Mutual TLS stage
Client certificate authentication through the Mutual TLS stage is an authentik Enterprise feature, so the scope must include a license check before build work begins. DeployOpen confirms with you which edition and seat model applies to your user population and external users, and records who holds the license agreement. The step closes with a written confirmation that the Enterprise features in scope are licensed for your deployment, or a clear list of what is blocked until the license is in place.
Configure the Mutual TLS stage and flows
DeployOpen configures the Mutual TLS stage, the flow bindings that route certificate users into the right authentication or enrollment path, and the policies that decide which certificates may proceed. Where a certificate should only enroll a user rather than sign them in, we set the enrollment behavior explicitly. The step closes with a configuration set held in your own version control, ready for review by your security team.
Test each certificate type end to end
Each certificate type in the register is tested with real credentials: a device certificate, a smart card or PIV card, and a hardware token where in scope. Tests cover valid certificates from the trusted chain, certificates from untrusted or revoked issuers, expired certificates, and a user with no matching account. DeployOpen records the result for every case. The step closes when every test case has a documented expected and actual outcome and any failures have been fixed and retested.
Document trust and forwarding settings
DeployOpen writes the runbook your operators will use: the trusted CA bundle and how it is updated, the reverse proxy header or forwarding settings that carry the client certificate, the expected failure messages, and the steps to rotate a CA. Settings that depend on your network layout are documented with the owner who must confirm them. The step closes with a handover document reviewed with your platform team, so changes to the proxy or CA can be assessed against the certificate login path.
Agree on ongoing support through a retainer
After handover, changes to CA chains, proxy upgrades or authentik releases can affect certificate login. DeployOpen offers ongoing support, upgrades and re-testing as a retainer, with scope agreed in writing. Your team decides whether to keep this work in house, use a retainer, or combine both. The step closes with a written support arrangement that names who responds to certificate failures and how regression tests are rerun after each change.
