authentik for PCI DSS requirement 8

authentik for PCI DSS requirement 8 authentication: what it covers and what it does not

authentik can enforce most of the PCI DSS v4.0.1 requirement 8 controls that govern access into the cardholder data environment (CDE) and remote access, but scope, the choice between the defined and customized approach, and the assessment itself remain with your organization and its assessor. If you run or are planning a CDE on self-managed identity, the requirements this page addresses are 8.2.5 (termination revocation), 8.2.6 (inactive accounts), 8.2.8 (idle session re-authentication), 8.3.4 (invalid attempt lockout), 8.3.6 (password rules) and 8.4.1 to 8.4.3 (MFA for administrative, CDE and remote access). DeployOpen plans, configures and documents authentik in your infrastructure and prepares the evidence that supports these controls. DeployOpen does not issue reports, attestations or certifications. A Qualified Security Assessor or your self-assessment remains the basis for validation.

Several requirements depend on things authentik does not decide. Whether a given system is in the CDE, which accounts are administrative, and which connections count as remote access are scoping questions that come before any identity design. Requirement 8 also reaches beyond the identity provider: applications that authenticate against their own local user stores, shared or service accounts, and administrative consoles that bypass SSO may each need separate handling. Confirm with your assessor whether your planned controls will be assessed under the defined approach or the customized approach, because that choice changes the evidence you produce.

Phishing-resistant passkeys deserve a separate decision. PCI SSC guidance says FIDO2-compliant synced passkeys can satisfy the 8.4.2 MFA exemption for accounts that use only phishing-resistant authentication, but that passkeys alone do not satisfy 8.4.1 or 8.4.3. Plan a second factor for administrative and remote access paths and check the current FAQ wording with your assessor before you rely on the exemption. Also confirm which authentik features your edition provides for password history, enhanced audit logging and privileged access, because the authentik pricing page lists several of these as Enterprise-only features.

Mapping PCI DSS requirement 8 controls to authentik configuration

This table maps the requirement 8 controls covered here to the authentik capability that addresses each one and the configuration to set. Use the capability column to find the right mechanism, and the configuration column as the list to verify in your own environment before an assessor reviews it. The main takeaway is that most of these controls depend on flows, policies and provider settings, so each application that reaches the cardholder data environment needs its own configuration check and evidence.

Requirement	What it asks for, in plain terms	authentik capability	Configuration to set or confirm
8.4.1, admin access	A second factor for administrative logins into the CDE, outside the console.	MFA enforced in an authentication flow bound to the admin application or proxy provider.	Bind an MFA stage to administrator groups. Confirm the enforcement path in your version.
8.4.2, all CDE access	A second factor for every access into the CDE, including standard users.	The same flow approach applied to each OIDC, SAML, LDAP or proxy provider that fronts CDE systems. Accounts using only phishing-resistant authentication may be exempt.	Require MFA on every provider that fronts the CDE. Confirm any passkey exemption with your QSA, since FAQ 1596 says passkeys alone do not satisfy 8.4.1 or 8.4.3.
8.4.3, remote access	A second factor for all remote network access that could touch the CDE.	Proxy, OIDC or SAML providers for remote tools. RADIUS or LDAP may cover VPN clients, depending on protocol support.	Map each VPN gateway and remote tool to a provider. Confirm with your VPN vendor how MFA is handled over RADIUS or LDAP.
8.2.8, idle sessions	Users re-authenticate after a session has been idle for more than 15 minutes.	Session and inactivity timeouts set in flows or provider settings. Confirm the exact setting in your version.	Set the idle timeout to 15 minutes or less on each CDE provider. Test with an idle session and keep the result as evidence.
8.3.4, lockout	User IDs lock after no more than 10 failed attempts, for at least 30 minutes or until identity is confirmed.	Failed-login handling in flows and policies. Confirm lockout threshold, duration and unlock method in your version.	Set the attempt limit to 10 or fewer and the lock period to 30 minutes or more. Test a full lockout and unlock cycle.
8.3.6, password rules	Passwords of at least 12 characters that include both numbers and letters.	Password rules applied through password policy stages. Password history is listed as an Enterprise feature on the pricing page.	Set minimum length to 12 with numeric and alphabetic characters. Confirm your edition if you also need password history.
8.2.5, leavers	Access for terminated users is revoked immediately.	Account disablement in authentik. Automated deprovisioning depends on your source or SCIM design, so confirm it.	Drive deactivation from your HR or directory source. Confirm how active sessions and tokens are ended, and record the time taken.
8.2.6, inactive accounts	Inactive user accounts are removed or disabled within 90 days.	Account state and last-login data are the inputs. Confirm which inactivity report or policy option your version provides.	Run a recurring check for accounts with no login in 90 days and disable the matches. Keep each run's output as evidence.

How phishing-resistant passkeys change the MFA scope for CDE access

Requirement 8.4.2 requires MFA for all access into the cardholder data environment (CDE), but PCI DSS v4.0.1 adds an exception: it does not apply to accounts that use only phishing-resistant authentication. That exception is the reason passkeys matter for this design. PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys qualify, while FAQ 1596 says that qualification alone does not satisfy requirement 8.4.1 for non-console administrative access or 8.4.3 for remote network access. Read together, the two FAQs mean a passkey can remove the second factor for ordinary CDE access accounts, but it does not by itself remove MFA from administrator or remote access paths.

For authentik, this splits the access design into two policy sets. Standard CDE application accounts can use a passkey-only authentication flow if every account in that population is restricted to phishing-resistant authenticators. Administrative console access and remote network access still need a second, independent factor that satisfies 8.4.1 and 8.4.3, so the authentication stages and policy bindings for those applications, outposts and VPN or RAC entry points should be set separately from the general flow. Check that a user who holds both a passkey and a TOTP device cannot fall back to the weaker path on a privileged application.

Before relying on the exception, confirm with your Qualified Security Assessor how each authenticator in your environment is classified, including whether your passkeys are synced or device-bound and which FIDO2 certification your implementation holds. Document the accounts, groups and applications covered by the exception in your scoping and evidence, and review the list whenever a new authenticator type or flow is added. The PCI DSS standard page is the reference for the requirement text, but the classification decision belongs to your assessor.

Open source or enterprise: which edition fits a requirement 8 build

The Open Source edition costs nothing to license and gives you the core identity functions a CDE access design depends on. You can configure providers for OAuth2/OIDC, SAML, LDAP, proxy and RADIUS, place cardholder data environment applications and remote access entry points behind one login, and build the flows and policies that govern MFA, session handling and lockout. Support is limited to the community Discord, so no contracted response is available for a production cardholder environment.

Core providers: OAuth2/OIDC, SAML, LDAP, proxy and RADIUS providers give you a single sign-on path into CDE applications and remote access gateways.
Enterprise-only controls: mTLS client certificate authentication, password history and enhanced audit logging are listed on the pricing page as Enterprise features, so they are not part of this tab.
Support model: the community Discord is the only listed support channel, with no ticket queue or service levels.
Compensating work: without password history and enhanced audit logging, you must meet password reuse rules and produce access event evidence through your own processes and log forwarding.
Edition boundaries: the code in the open-source project is under the MIT license, which covers most of the repository.

Confirm the Open Source column on the authentik pricing page before you commit, because edition contents can change between releases.

Configuring authentik for requirement 8 in sequence

This sequence takes a team from scoping the cardholder data environment to a tested authentik configuration that covers MFA, passkeys, idle re-authentication, lockout, password rules and account removal. The result is a set of controls and evidence that the entity and its assessor can review against requirement 8.

Confirm CDE scope and approach with the assessor
Before any configuration, the entity confirms with its assessor which systems, user populations and remote access paths sit inside the cardholder data environment, and whether each requirement 8 control will use the defined approach or the customized approach. Scope decisions drive every later step, because MFA under requirements 8.4.1 to 8.4.3 applies to specific access paths. Record the agreed scope and approach in writing. Done when the assessor has accepted a scope list that names the applications, administrative consoles and remote access methods that authentik will protect.
Deploy authentik in infrastructure you control
Your platform team deploys authentik in infrastructure the entity controls. Docker Compose suits test setups and small-scale production, and the Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM. For production, the Kubernetes guide with Helm is the usual path, and the chart's bundled PostgreSQL is intended for demonstration and test use, so a separately managed PostgreSQL instance is needed. Confirm the hosting location, network segmentation and the PostgreSQL backup plan against your own requirements. Done when the server and worker containers are running and the admin console is reachable only through the intended network path.
Check the authentik version against the security policy
Before go-live, the platform team compares the deployed version with the authentik security policy, which lists the release lines currently receiving security fixes. Check the GitHub releases page for the latest release and plan the upgrade path if the deployed line is no longer supported. Subscribe to security notices, since the project announces security releases in advance and your change process needs time to respond. Record the version in your configuration baseline. Done when the deployed version is on a supported line and the check is documented for the assessor.
Enforce MFA on CDE and remote access providers
Create or review the authentik applications and providers for each CDE access path, including administrative consoles and remote network access, and bind them to flows that require a second factor. Confirm which of your second-factor methods satisfy your MFA design, and check whether your remote access gateway or VPN can accept the authentik authentication flow. Ask your assessor how they will test requirement 8.4.1, 8.4.2 and 8.4.3 for each path. Done when a test user cannot reach a CDE application or remote access path without completing MFA, and the test result is saved.
Configure passkeys and idle re-authentication
Enroll phishing-resistant authenticators for users who access the CDE and document which users are on passkeys only. PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys qualify for the 8.4.2 exemption, while FAQ 1596 states that passkeys alone do not satisfy 8.4.1 or 8.4.3, so keep MFA on those paths. Configure session timeouts so that users must re-authenticate after more than 15 minutes of inactivity, as requirement 8.2.8 requires. Test the idle timeout with a real session and record the setting. Done when idle sessions require re-authentication and the passkey population is listed with the authenticator types in use.
Set lockout and password rules
Configure the password policy and account lockout settings in authentik to meet requirement 8.3.4, which requires locking the user ID after no more than 10 invalid attempts for at least 30 minutes or until identity is confirmed, and requirement 8.3.6, which requires passwords of at least 12 characters with numbers and letters. Confirm which edition provides each setting you need, because the pricing page lists password history as an Enterprise feature. Test lockout with repeated failed logins in a non-production tenant. Done when a failed-login test locks the account at the configured threshold and the password rule rejects a non-compliant password.
Wire joiner and leaver removal into access
Connect your HR or ticketing source to authentik so that new users receive access through defined groups and departing users lose access. Requirement 8.2.5 requires access for terminated users to be revoked immediately, and requirement 8.2.6 requires inactive accounts to be removed or disabled within 90 days. Decide whether revocation is driven by directory sync, a manual runbook or an integration, and document the owner of each step. Test a leaver case end to end. Done when a disabled test account loses CDE access on the next attempt and an inactivity report exists that the team reviews against the 90-day limit.
Export evidence for the assessor
Collect the configuration exports, test results, version record, scope document and event logs that show each control working. Confirm with your assessor which evidence format they accept and how long your organization retains it under its own policy. Check that authentication events are logged and forwarded to your central log platform. Done when the assessor has received an evidence package that maps each step to the requirement it supports, and open gaps are recorded for your remediation plan.

Evidence authentik gives a PCI DSS assessor for requirement 8

An assessor testing requirement 8 looks for configuration that shows the control exists and records that show it operated over time. The cards below cover the artifacts to keep from authentik, how to store them, and the point where the assessor, not the team, decides whether they are sufficient.

MFA stage and policy exports

Export the authenticator stages, flow bindings and policies that apply MFA to each application that touches the cardholder data environment (CDE) or remote access. Pair each export with the application it protects, so the assessor can trace every CDE access path to an enforced MFA requirement. Check that no application is bound to a flow that skips the stage, and record who approved each change. Ask the assessor which format they accept for configuration evidence before you export.

Idle timeout and lockout settings

Keep the flow and policy settings that enforce re-authentication after idle periods and lock user IDs after repeated failed attempts. Capture the exact values configured, the session settings they bind to, and the object identifiers, so a reviewer can compare the configuration with the requirement text. Export these settings again after every change, because a single edited policy can change behavior for every application bound to it.

Password rule configuration

Retain the password policy that governs length, character composition and reuse for the users who reach the CDE. Note which policy is bound to which group, and whether any directory source or local account bypasses it. Passwords are one part of requirement 8, so pair this export with the MFA evidence rather than presenting it alone. Confirm with your assessor how they want the policy shown if it is enforced by a source outside authentik.

Account disable and removal register

Maintain a list of every account with access to the CDE, showing when it was disabled or removed and the request that drove the change. Reconcile this list against the active user export on a schedule your team defines, since a disabled account that still holds group memberships is a common finding. Inactive accounts and terminated users are handled on different timelines, so record both dates separately.

Forwarded authentication event logs

Forward authentication events from authentik to the entity's central log system, and keep proof that the forwarding ran. The records should show successful and failed logins, MFA challenges, lockouts and account changes, each with a timestamp and user identifier. Test the pipeline by generating a known event and finding it in the central store. Confirm retention with the team that owns the log platform, because authentik's own retention is not the entity's record.

Version and change records

Keep a record for each authentik version upgrade and each configuration change, including the release notes reviewed, the test result and the approver. Security fixes are announced in advance, so note the date you received each announcement and when you applied it. Retaining these entries shows that the control has been maintained, which an assessor will check against the release history in use during the assessment period.

What authentik does not settle for requirement 8

authentik enforces identity controls for the applications it fronts, but it does not define your cardholder data environment. Scope definition and network segmentation stay with the entity. Your assessor will expect a documented scope that shows which systems, networks and administrative paths reach the CDE, and which controls keep out traffic that never passes through authentik. If a jump host, database console or payment application can be reached without an authentik flow, requirement 8 controls on the authentik side do not cover that path. Confirm the scope boundary with your QSA or your acquirer before you finalize the design, and map every entry point into the CDE to an authentication path you can show.

Authenticators and endpoints outside authentik need separate handling. Shared accounts, service credentials, local administrator logins on servers and application-local passwords that bypass authentik are common in payment environments and will fall outside the SSO design unless you find them and remove or control them. Inventory these accounts, decide which can be retired and which need a documented compensating control or an approved customized approach, and record the decision. Plan for a review of application-local login pages, because an application that still accepts a local password beside the SSO button can undermine the MFA and lockout settings you configured in authentik. Password history is listed on the authentik pricing page as an Enterprise feature. Before you rely on it for any password-reuse rule, ask your assessor to confirm how it maps to the relevant requirement, and confirm with the authentik project which license covers the feature you plan to use.

The PCI DSS standard is under review. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026, and as of October 2026 it had announced no release date for a new version. Track the PCI SSC for changes, and recheck your requirement 8 mapping when a new version is published, since control numbers and wording may move. Also remember that the PCI SSC does not enforce compliance. The payment brands and your acquirer decide who must validate and which enforcement programs apply, so ask them directly which validation type and deadlines apply to your entity before you scope the project.

How much effort does authentik for PCI DSS requirement 8 take?

What drives the effort and cost of authentik for PCI DSS requirement 8?

The main drivers are the size of your cardholder data environment (CDE), the number of applications and administrative paths that reach it, and the identity sources you already run. Each one changes how many integrations, policies and test cases must be built. Other drivers are the passkey rollout, since phishing-resistant authenticators need enrollment and recovery design for every user group, and the evidence design, meaning how you will show auditors that the controls work. The approach you choose also matters. The defined approach follows the requirement's wording directly, while the customized approach needs documented analysis that the control meets the stated objective. Ask for a written scope that lists each effort driver separately so you can see what changes the price if one of them moves.

Which parts of authentik for PCI DSS requirement 8 are one-time work?

One-time work includes the initial deployment, the configuration of MFA stages and policies for CDE and remote access, the idle session and lockout settings, the password rules, the passkey enrollment flows, the lifecycle integration with your HR or directory source, and the first round of testing and evidence capture. Documentation of how each control maps to the requirement is also usually built once and then maintained. Confirm in the written scope which of these items are included, and whether the work covers a single environment or several.

What recurring work does a PCI DSS requirement 8 setup need after go-live?

Recurring work falls into four groups. authentik itself needs upgrades, and the project's security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, so your upgrade plan must keep you on a supported line. Access reviews must run on the schedule your program sets. Log retention must be configured and verified, and the audit events from authentik must be kept long enough to answer assessor questions. Finally, each assessment cycle requires fresh evidence, such as current configuration exports and test results. Ask the provider whether a retainer covers these tasks or whether they are billed separately.

What does our team need to provide for the engagement?

You will need to name owners for the identity platform, the CDE and the remote access paths, because decisions about policy and exceptions must be made by people who can approve them. You will also need current scope documentation, including a list of systems in the CDE, network paths into it and the administrative accounts that reach it. Application access is required so the work can be tested in your environment, and you should give the provider a contact who can speak for your qualified security assessor or internal assessor. Confirm these inputs in the written scope so both sides agree on who supplies what and by when.

Can our own team implement PCI DSS requirement 8 controls with authentik alone?

A team with strong identity engineering skills and time to spare can build these controls internally, since authentik is open source under the MIT license for most of its code. The harder parts are usually not the configuration itself. They are scoping the CDE correctly, proving each control with evidence, and keeping the setup stable through upgrades. Note that the enterprise directory carries separate licensing, and some features that may matter to this work, such as password history and enhanced audit logging, are listed as enterprise-only on the pricing page. Check that list against your design before you commit to an edition. Many teams split the work: they build internally and bring in a partner for the design review or for the evidence package.

Does DeployOpen certify that our environment is PCI DSS compliant?

No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in your infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Under PCI DSS, validation is documented by a Report on Compliance completed by a Qualified Security Assessor or by a Self-Assessment Questionnaire with an Attestation of Compliance, and the payment brands decide which entities must validate. Your assessor or the relevant payment brand makes the compliance determination.

How do we get an accurate effort estimate before committing?

Ask for a fixed-scope proposal built from a written scope. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list, so the figure comes from the quote that follows the scope. Ask the provider to show which effort drivers they counted, which items are one-time and which recur, what is excluded, and which inputs from your team are assumed. Compare quotes on those assumptions rather than on the total alone.

How DeployOpen scopes and delivers requirement 8 configuration and evidence

DeployOpen plans, implements and documents self-hosted authentik inside your own infrastructure, so requirement 8 controls are configured where your cardholder data environment runs. Work starts with a written scope that maps each control to a concrete authentik setting and a piece of evidence your assessor can review.

How we scope

Written scope lists which CDE access paths, admin consoles and remote access routes authentik will gate for requirement 8.
Scope records which applications sit behind SSO and which legacy accounts or LDAP clients remain outside the design.
Scope names the authentik version, PostgreSQL arrangement and hosting environment, all confirmed with your team before work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any configuration begins.

How we build

Build covers MFA enforcement for CDE access, remote access and non-console administrative access in authentik flows and policies.
Session idle timeout, lockout thresholds and password rules are configured and then tested against the requirement wording.
Phishing-resistant passkey enrollment is set up where your assessor's reading of the requirement supports it, and tested with real users.
Account lifecycle is wired to your joiner, mover and leaver process so inactive and terminated access is removed on the required timelines.

How we hand over

Handover includes configuration documentation mapping each requirement 8 sub-requirement to the specific authentik setting that meets it.
Test records show each control working as designed, including failed-login lockout and idle re-authentication behavior.
Evidence guidance explains which authentik event logs, exports and configuration snapshots to retain for your QSA or internal reviewer.
Runbooks cover changes to policies, adding applications and reviewing access, so your team can operate the controls after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for authentik controls that must stay in place.
Retainer work can cover authentik version upgrades, re-running control tests after changes and refreshing evidence for each assessment cycle.
Confirm with DeployOpen whether a retainer covers scope changes for new CDE applications before you sign.
Compliance readiness is prepared by DeployOpen. Audit reports and attestations are issued by your independent assessor, not by DeployOpen.

authentik for PCI DSS requirement 8 authentication