What authentik helps you evidence under CIS Controls 5 and 6
A self-hosted authentik deployment can supply much of the evidence behind four CIS Controls Safeguards: 5.3 (dormant accounts), 5.6 (central account management), 6.3 (MFA for internet-facing applications) and 6.5 (MFA for administrative access). Because authentik acts as the identity provider for applications, it can enforce MFA centrally through its flows and policies and record the resulting authentication events, which is the pattern CIS accepts when a directory or SSO provider enforces MFA for the application. Safeguards 6.3, 6.5 and 5.3 sit in Implementation Group 1, the essential cyber hygiene baseline, while 5.6 is assigned to IG2 and IG3. Whether an application actually meets a Safeguard depends on how it is wired to authentik, so the first task is an inventory of internet-facing applications and administrative accounts, and a check of which of them support SSO or MFA.
DeployOpen prepares the configuration and the evidence, including provider setup, MFA stages, inactivity handling, group design and records that show how each Safeguard is met. CIS does not certify organizations, and an independent auditor or assessor decides whether your environment conforms. Before scoping the work, confirm with the CIS Controls Assessment Specification which measures and metrics your assessor will use for each Safeguard, and confirm with your authentik edition which features you need. Dormant account handling, for example, depends on how your team reads last-login data and disables inactive users, and some controls may need enterprise-only features that are listed on the authentik pricing page.
Plan for the gaps that authentik cannot close alone. Applications that do not support SSO, administrative accounts on infrastructure outside the identity provider, and service accounts all need a documented exception or a separate control. Safeguard 5.3 also depends on a defined inactivity threshold and a process that acts on it, which authentik can enforce only if your team applies it consistently to the accounts it governs. Keep the exception register, the review records and the event logs together so that an assessor can sample a control and trace it from policy to configuration to log evidence.
How each CIS Safeguard maps to authentik configuration
This table lists four CIS Safeguards in the account and access management controls, with their asset class, security function, Implementation Groups, the authentik capability that addresses each one, and the settings to configure. Read each row as a requirement, then as a configuration task. The main takeaway is that MFA and central account management are IG1 or near-IG1 expectations that authentik can enforce centrally, while dormant account handling depends on your directory and lifecycle process.
| Safeguard | Classification | authentik capability | Configuration to set |
|---|---|---|---|
| 5.3 Dormant accounts disabled or deleted | Users asset class, Protect function, IG1, IG2, IG3 | Lifecycle handled in the source directory, with user deactivation in authentik. Confirm any built-in inactivity handling in your version. | Document a 45-day inactivity threshold, run a recurring report of last logins, and deactivate matches in authentik and the source directory. |
| 5.6 Central account management | Users asset class, Govern function, IG2 and IG3 only | authentik acts as one identity service, with sources feeding users and providers serving applications. | Connect your authoritative directory as a source, then bind each application to an authentik provider and retire local application logins where the app allows it. |
| 6.3 MFA for internet-facing applications | Users asset class, Protect function, IG1, IG2, IG3 | Authentication flow with an MFA stage applied through policy bindings. Proxy provider covers apps without OIDC or SAML. | Bind the MFA stage to every externally exposed application's flow. Confirm each app supports centrally enforced SSO and test legacy protocols separately. |
| 6.5 MFA for administrative access | Users asset class, Protect function, IG1, IG2, IG3 | MFA stage on flows for administrator groups, plus session settings for administrative applications. | Require MFA for admin group members, use separate admin accounts, shorten admin session lifetimes, and cover provider-managed assets where the asset supports MFA. |
How authentik centralizes accounts for Safeguard 5.6
Safeguard 5.6 asks for accounts to be managed from one central place, a directory or identity service. In an authentik deployment, that place is authentik's own database-backed identity store, which holds users, groups and the providers that sign them into applications. Each application is then configured as a provider (OAuth2/OIDC, SAML, LDAP, proxy or SCIM) that reads from the same store, so an account is created, changed or disabled once instead of separately in every application. The decision to make first is where the authoritative record of a person lives: in authentik itself, or in an upstream source that authentik reads from. Document that choice in the access control standard, because the answer determines where leavers are removed and where the Safeguard 5.3 dormant account check must run.
If the organization already has a directory, the main choice is whether authentik becomes a consumer of that directory or the system that holds the accounts. Upstream sources can be an LDAP directory, Microsoft Entra ID or Google Workspace. The Entra ID and Google Workspace integrations are listed on the authentik pricing page as Enterprise-only features, alongside mTLS client certificate authentication and enhanced audit logging, so confirm the edition and license terms before designing around them. The Open Source edition, which the pricing page lists as free, is licensed under MIT for most of the code, while the authentik/enterprise/ directory is under a separate license. Ask your procurement and legal teams to review both before a single source of truth is selected.
Whichever source is chosen, confirm three points in a test environment before rollout: that disabling an account in the authoritative source prevents sign-in to every connected application, that group membership changes flow to the providers that depend on them, and that the audit trail records who changed what. Mapping SCIM provisioning and LDAP sync behavior is covered in the provisioning and sources sections of this page, so this section focuses on the architectural decision. Record the result as evidence that a single account lifecycle governs all in-scope applications, since Safeguard 5.6 is a Govern-function safeguard assigned to IG2 and IG3 rather than IG1.
Configuration sequence for CIS Controls 5 and 6
This sequence turns a running authentik instance into a central account store where every internet-facing application and administrative group is bound to MFA, and where access can be revoked from one place. Each step ends with a check you can record as evidence for Safeguards 5.3, 5.6, 6.3 and 6.5.
Deploy a supported authentik version
Your platform or infrastructure team installs authentik using Docker Compose for small test or production-scale setups, or the Helm chart for Kubernetes, with PostgreSQL as the data store. Check the security policy for the versions currently receiving security fixes and pick one of them before you configure anything, because controls built on an unsupported release are harder to defend. Confirm the PostgreSQL arrangement against the vendor's production guidance: the Kubernetes guide recommends a separately managed PostgreSQL rather than the chart's bundled database. The step is done when the server and worker containers are healthy, the admin console loads over HTTPS, and you have recorded the exact version in your configuration baseline.
Define user sources and groups
Your identity administrator connects authentik to the directory or HR-driven source that will own account lifecycle, or creates users in authentik directly if no upstream source exists. Create groups that mirror your access model, such as one group for general staff, one for each internet-facing application population and one for administrators, so that MFA and access decisions attach to groups rather than to individual accounts. Record which system is the authoritative place where accounts are created, changed and removed, since Safeguard 5.6 asks for account management from one central place. The step is done when every account that can sign in to a protected application appears in authentik, traces to that single source, and sits in at least one group.
Bind each internet-facing application to a provider
For each application reachable from the internet, your application owner creates a provider and application in authentik using the protocol the application supports, such as OAuth2/OIDC, SAML or the proxy provider for applications that cannot speak either protocol. Where the application cannot be integrated, plan a forward-auth or proxy arrangement as a separate work item. Keep a register that lists each application, its provider type, its owner and the group allowed to reach it. The step is done when every externally exposed application appears in the register and no internet-facing application is still reachable through a direct, unmanaged login path.
Enforce MFA stages through policy bindings
Your identity administrator builds an authentication flow that includes an MFA stage, then binds that flow to each application's provider and adds policy bindings so the stage applies to the groups that reach those applications. Choose second factors your organization can support, and confirm in the vendor documentation for your chosen version which factor types, binding options and any enterprise-only features apply to your edition. Where a legacy client cannot present a second factor, record it as an exception with a compensating control and an owner, rather than leaving the application quietly outside the flow. The step is done when a test account in each application group is prompted for a second factor on sign-in, and the attempt appears in the event log.
Require MFA for administrative groups
Your administrators create a dedicated administrative group in authentik, assign only the accounts that need privileged access to it, and bind a stricter MFA policy to that group across the console and to the applications that carry administrative functions. Keep administrative accounts separate from day-to-day accounts so that a normal sign-in cannot reach administrative rights. Document which managed services and administrative consoles sit behind this group, because Safeguard 6.5 extends to accounts a service provider manages. The step is done when an administrator who signs in without a second factor is refused, and when the group membership list has been reviewed and signed off by someone other than its maintainer.
Configure session and dormant-account handling
Your identity administrator sets session lifetimes and idle timeouts for each flow, then establishes a recurring review that identifies accounts with no sign-in for 45 days and either disables or deletes them according to your procedure for Safeguard 5.3. Confirm in the vendor documentation for your version whether inactivity can be detected and acted on automatically, and if it cannot, assign an owner and a documented manual report derived from the event log. Record the session settings and the review procedure in your configuration baseline. The step is done when a dormant test account is identified by the report and the disable or delete action is logged.
Test revocation end to end
Your security team selects a test account that belongs to an application group and an administrative group, then disables it in the central source and confirms that sign-in to each bound application fails, including any active sessions that should end. Repeat the test for a removed group membership to show that access follows the group, not a cached assignment. Capture timestamps, the event records and the application responses as evidence, and file them with the register from earlier steps. If any application keeps a local account or session that authentik does not control, add it to the register as an open finding with an owner. The step is done when the revocation test passes for every bound application and the results are stored with the configuration baseline.
Where MFA enforcement differs by application type
Applications that speak OIDC or SAML hand the login decision to authentik as the identity provider. When a flow or policy requires a second factor, authentik enforces it before issuing tokens or assertions, so the application never sees a password-only session. This is the cleanest path to meeting Safeguard 6.3 for internet-facing applications, because CIS accepts MFA enforced centrally by an SSO provider as meeting the Safeguard.
- Coverage: Each application bound to an authentik provider inherits the MFA stage applied to its flow or policy binding.
- Bypass risk: Local application accounts, break-glass logins and direct-to-app URLs can skip SSO, so disable local password login where the application allows it.
- Group scoping: Bind MFA to groups that cover all users of the application, not only the ones you remember to add.
- Evidence: Export the provider and binding configuration and keep authentication event logs that show the second factor step.
- Vendor limits: Confirm with the application vendor whether it supports SSO-only login and whether its own admin accounts remain outside SSO.
For any SaaS application, confirm that the vendor's SSO feature, and the plan that includes it, supports enforcing SSO for all users.
Applications that cannot speak OIDC or SAML are placed behind a reverse proxy that calls authentik's proxy outpost. The outpost checks the session and applies the same MFA stage before the request reaches the application. Enforcement depends on the proxy path being the only route to the application, so the network design matters as much as the policy.
- Routing: Confirm that the application's backend is reachable only through the proxy, and that no alternate hostname, port or internal route bypasses it.
- Header trust: The application must accept identity headers only from the outpost, or it may trust forged headers from other sources.
- Per-application policy: Each protected hostname needs its own policy binding, and new hostnames added later need the same review.
- Outpost availability: If the outpost is down, decide in advance whether requests fail closed, and test that behavior.
- Coverage gaps: Static assets, API paths and health checks may be excluded from the proxy rules, so list every excluded path and assess it.
If the application has its own login screen that a user can reach without the proxy, treat Safeguard 6.3 as not yet met for that application until you have verified the network path.
LDAP and RADIUS clients usually submit a username and password directly and cannot display a browser-based MFA prompt. Enforcement therefore depends on how the client sends credentials and whether authentik can challenge the second factor within that protocol. The reader must confirm this for each client rather than assume that a directory service covers it.
- Protocol limits: Confirm which second factor methods work through the LDAP bind or RADIUS exchange for each client, and whether the client supports a challenge response at all.
- Service accounts: Bind accounts used by applications for directory lookups are not interactive users, so document how they are protected and restricted instead of applying MFA to them.
- Password-only paths: Where a client can only send a password, the account is not covered by centralized MFA for that path. Record it as an exception with a compensating control.
- Logging: Confirm that authentication attempts over LDAP and RADIUS appear in logs that you can retain and review.
- Client inventory: Maintain a list of every client bound to the directory, since a client missed in the inventory is a client missed in the MFA review.
Safeguard 6.3 and 6.5 are not met by the directory alone for these clients. Ask the vendor or test the client against your configuration before you record coverage.
Remote access tools, VPN gateways, firewall management interfaces and infrastructure consoles are the places where administrative access is exercised. Safeguard 6.5 requires MFA on every account with administrative access to an enterprise asset where the asset supports it, including assets a service provider manages. The key question is whether each console can delegate its login to authentik, and whether a local administrator account remains usable.
- Administrative accounts: Apply MFA to every account with administrative rights, including accounts on appliances and cloud consoles that a provider operates for you.
- Local fallback accounts: Identify each local account, store its credentials under controlled access, and decide when it may be used.
- Provider-managed assets: Ask the service provider in writing how it enforces MFA on administrative access and what evidence it will supply.
- Session controls: Confirm session lengths and re-authentication for privileged consoles, since a long-lived session can outlast the MFA check.
- Unsupported devices: Where a device cannot use MFA, record the exception and the compensating control in your asset inventory.
Confirm with each vendor whether its console supports SSO or MFA delegation, and do not record Safeguard 6.5 as met for any console you have not tested.
Access revocation and dormant accounts under Safeguard 5.3
Safeguard 5.3 asks for dormant accounts to be deleted or disabled after 45 days of inactivity, where supported, and access revocation depends on the same central account record. The cards below separate the steps that cut access at the source, the sessions and tokens that outlive it, and the local accounts that authentik cannot reach.
Disable leavers at the central source
Revocation starts with disabling the user in the directory or identity source that authentik reads from, not in each application. Confirm which source is authoritative for your workforce, whether that is a directory, an HR-driven sync or manual administration, and who triggers the disable step on a leaver's last day. A user disabled in authentik should be unable to start new logins, which you can verify by testing a disabled test account against each protected application.
Revoke sessions and tokens
Disabling an account does not automatically end sessions or tokens that were issued before the change. Check how long access tokens and refresh tokens remain valid for each OAuth2/OIDC provider, and whether sessions already open in a browser or on a mobile client end when the user is disabled. Document the revocation behavior you observe in a test, because the answer changes with the protocol and the client application.
Find dormant accounts after 45 days
Safeguard 5.3 sets a 45-day inactivity threshold for dormant accounts, where the platform supports it. Export last-login data from authentik and from the directory it reads, then compare it against the threshold on a scheduled basis. Decide in advance whether a dormant account is disabled or deleted, and who approves the action, so the outcome is repeatable and visible in your records.
Bound privileged access
Administrative accounts need the shortest path to removal. Review which authentik groups grant administrative roles and which external applications map to them, and confirm that removing a person from those groups removes their elevated access. Pay attention to standing privileges that persist after a role change, and to service or break-glass accounts that do not follow the normal leaver process and need their own owner and review date.
Verify local accounts in downstream apps
Applications that keep their own user tables can retain accounts after authentik disables the SSO identity. Inventory each connected application and record whether it creates local users on first login, whether it supports SCIM or another deprovisioning path, and who removes accounts it holds. Check at least one leaver per application to confirm that local access ends, since a disabled SSO login does not always remove an account the application still stores.
Questions buyers ask before hiring help with CIS Controls and authentik
Does authentik alone satisfy the CIS Controls?
No. authentik can enforce several Safeguards in Controls 5 and 6, including central account management, MFA on internet-facing applications and MFA on administrative accounts, but CIS does not certify any single product. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. Each Safeguard is verified against its own measures in the CIS Controls Assessment Specification, so you still need account inventories, admin account policies, offboarding procedures and evidence of how each application is protected. Whether a given application supports MFA through authentik is something to confirm for that application before you rely on it.
What drives the licensing cost of authentik for this work?
The main licensing decision is the edition. The authentik core code is under the MIT license, and the pricing page lists a free Open Source edition with community support only. The Enterprise edition is priced at $5 per user per month billed annually, plus $0.02 per external user per month, according to the authentik pricing page. Some features this topic relies on, such as enhanced audit logging and password history, are listed as Enterprise-only, so confirm which features your access model needs before choosing a tier. Enterprise Plus, starting at $20k annually, adds dedicated support with SLAs and FIPS compliance for FedRAMP requirements. Check the current pricing page for changes.
What hosting cost should we plan for an authentik deployment?
Hosting is usually a smaller cost than the labor, but it recurs every month. The Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. The Kubernetes guide recommends a separately managed PostgreSQL for production rather than the bundled demonstration database, which is a cost to plan for. Your size, redundancy targets, backup storage and the number of applications and outposts will set the real footprint. Ask for hosting assumptions in any quote, and confirm them against your own cloud or data center prices.
What does the integration and testing work cost depend on?
Effort scales with the number of applications that must sign in through authentik and how each one speaks its protocol. OAuth2/OIDC, SAML and LDAP are standard provider types, while applications that cannot speak those protocols need the proxy provider and forward auth. Each application needs its MFA enforcement tested, including the admin accounts and any remote access path. Testing covers login with each second factor, account disablement, group membership changes and the logs that show them. Ask any provider to list the applications in scope, the protocol for each, the test cases and who signs off on them.
What does our team need to provide for the engagement?
Most of the input must come from your side. You need an inventory of user accounts and their sources, a list of internet-facing and administrative applications, your current MFA options and any directory that should remain the system of record. You also need named owners for approvals, access groups, offboarding steps and the dormant-account rule your policy sets. Access to your cloud accounts, DNS, certificates and reverse proxies is needed to deploy and test. Ask for a written list of client inputs in the scope document, because missing inputs are a common cause of delay.
What makes the timeline longer or shorter?
The timeline depends on the number of applications in scope, whether an existing directory must be synchronized, how many applications need forward auth instead of native SSO, and how quickly your owners approve policies. Upstream sources such as an existing directory add reconciliation work. Applications that do not support MFA, or that need a compensating control, take longer to document. Your change windows and testing environments also set the pace. Request a phased plan with a written scope and dated milestones, and ask which items depend on your approvals.
Can our own IT team do this work internally?
Often yes, if the team has experience with identity protocols, PostgreSQL, reverse proxies and container or Kubernetes operations, and if it can own the evidence. The harder parts are usually the application-by-application MFA checks, the admin account separation and the written evidence that maps each Safeguard to a measure. Internal teams should also plan for upgrades, since authentik publishes security releases with at least 24 hours of advance notice and lists supported versions. A fixed-scope engagement can cover part of the work, and retainers can cover ongoing upgrades and testing. Weigh your team's capacity against these tasks.
What does DeployOpen not certify?
DeployOpen does not issue CIS Controls certifications, audit reports or attestations. DeployOpen plans, implements, hardens and documents authentik inside your infrastructure, and prepares systems and evidence for assessment. Independent assessors decide whether your implementation meets the Safeguards. CIS Controls Accreditation, which is run with CREST, covers organizations that provide CIS Controls services, and that is a separate question from the outcome of any assessment. Ask any provider, including DeployOpen, which party issues each report and which evidence you will own at handover.
What authentik does not cover for CIS Controls 5 and 6
authentik centralizes sign-in and enforces MFA where it reaches the login path, but it does not decide who should have access or whether every asset routes through it. The cards below mark the gaps that remain with your team, your HR processes and your service providers, and what to confirm in your own environment.
Applications that bypass MFA
Safeguard 6.3 covers internet-facing applications where the application supports MFA, and CIS accepts MFA enforced centrally by an SSO provider. Applications that still accept local passwords, API keys or legacy protocols outside authentik can skip that check entirely. Inventory every externally exposed application, confirm whether it sends users through authentik, and record any app that cannot be routed through it as an exception with its own compensating control.
Service-provider-managed assets
Safeguard 6.5 extends MFA to administrative accounts on enterprise assets, including assets a service provider manages. An authentik instance can only enforce MFA for administrators who sign in through it. Managed hosting, vendor consoles and provider-run appliances may have their own local admin accounts, so confirm with each provider which admin logins can be federated and which must be covered by contract terms and their own MFA.
Joiner and leaver HR process
Safeguard 5.6 expects accounts to be managed from one central place, but authentik does not know when someone is hired, transferred or terminated unless a process feeds it. Without an authoritative HR or directory source and a documented offboarding step, disabled accounts and forgotten access will persist. Confirm who triggers account creation and disablement, how fast that happens, and how it is recorded.
Periodic access reviews
Safeguard 5.3 asks for dormant accounts to be deleted or disabled after 45 days of inactivity where supported, and authentik's logs can show last sign-in activity. Detecting dormancy and deciding whether an entitlement is still needed are different tasks. Access reviews are a business process owned by application owners and managers, with sign-off records kept outside the platform. Confirm the review cadence, owners and evidence format before relying on authentik as the source.
Endpoint and network controls
Remote network access controls under Control 6 depend on more than the sign-in step. authentik can authenticate VPN, firewall and remote access sessions where the protocol allows, but device health, patch status, endpoint MFA for local logins and network segmentation are controlled elsewhere. Confirm which network paths require an authentik login, which do not, and who owns the controls around the authenticated session.
Enterprise-only features you may need
Some controls depend on features outside the open-source edition, including Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. Check the pricing page against your required integrations and log retention before you commit to a design. Ask for a written statement of which features are in your chosen edition, and confirm license terms for the enterprise directory.
Which authentik edition covers these controls
Map each capability your CIS Controls plan needs to an edition before you scope the work. authentik publishes three editions: Open Source at no license fee, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually, according to the authentik pricing page. Most of the code sits under the MIT license, but code in the authentik/enterprise/ directory falls under a separate enterprise license, so the licensing boundary follows the feature boundary rather than the repository as a whole. Confirm that split against the authentik LICENSE on GitHub before your legal team reviews it.
For this topic, the features that matter most are the Enterprise-only items on the pricing page: Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. If your directory is Entra ID or Google Workspace, the account lifecycle work under Safeguard 5.6 and the dormant account review under Safeguard 5.3 may depend on those integrations. If you rely on privileged access management or enhanced audit logs for administrative access evidence under Safeguard 6.5, those requirements also point toward Enterprise. Core MFA for applications through OAuth2/OIDC, SAML and LDAP providers is not listed as Enterprise-only on that page, so confirm that reading with the vendor before you rely on it.
Write a capability matrix with one row per control need, such as central account source, MFA for each internet-facing application, MFA for administrative consoles, and dormant account disablement, and mark the edition that supplies each row. Ask authentik directly for current edition terms, per-user and external-user billing definitions, and whether support tiers change the scope of an implementation. Pricing and feature placement can change between releases, so record the date and version you checked. DeployOpen can help map these needs to editions as part of a written scope, but the vendor's current terms are the authority.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For CIS Controls account and access management, the work starts with a written scope that maps each in-scope Safeguard to a configured authentik setting and a piece of evidence you can show an assessor.
How we scope
- Inventory the applications, directories and administrative systems that need central account management and MFA.
- Record which applications are internet-facing, which support SAML or OIDC, and which need a proxy outpost.
- Agree in writing which Safeguards are in scope and which are owned by your HR, IT or service provider processes.
- Confirm the deployment target, PostgreSQL arrangement and authentik edition before any build work starts.
How we build
- Configure central identity sources, groups and provider bindings so access follows one account record per person.
- Enforce MFA for administrative groups and externally exposed applications through authentik flows and policies.
- Set dormant-account handling and access revocation steps as documented, tested procedures in the deployment.
- Test each control path with sample users, including lockout, MFA enrollment and removal of a leaver's access.
How we hand over
- Deliver a written configuration record mapping each in-scope Safeguard to the authentik settings that implement it.
- Document the evidence sources, such as event logs and group membership exports, and where your team retrieves them.
- Provide runbooks for onboarding, offboarding, dormant account review and MFA reset requests.
- Walk your operations and security staff through the configuration and the verification results.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
- Ongoing support, authentik upgrades and continuous testing are available under a retainer.
- Re-check the mapping when authentik releases a new version or when your application inventory changes.
- DeployOpen prepares systems and evidence for assessment; independent auditors and certification bodies issue any formal opinion.
