Keycloak for PCI DSS requirement 8

How Keycloak supports PCI DSS requirement 8 access controls

If you run or support a cardholder data environment (CDE), you need login controls that an assessor can test and trace back to evidence. Keycloak can configure the technical parts of requirement 8: unique identity records, session idle timeout, password length and lockout settings, one-time passwords (OTP), WebAuthn and passkeys. Whether those settings satisfy each sub-requirement also depends on your processes, where the CDE boundary sits, and the assessor's judgment about how the evidence meets the requirement. DeployOpen prepares systems, configuration and evidence for that review, but it does not certify compliance. The PCI SSC does not validate compliance either. The payment brands decide who must validate, and a Qualified Security Assessor (QSA) or a self-assessment questionnaire, with its Attestation of Compliance, documents the outcome.

The identity lifecycle controls in requirements 8.2.5 and 8.2.6 are mostly procedural. Keycloak gives each person a separate user record, which supports unique IDs, but it does not decide on its own when a dormant account is disabled. Requirement 8.2.6 expects inactive accounts to be removed or disabled within 90 days, and 8.2.5 expects access for terminated users to be revoked immediately. You will need a recurring review, or automation that reads last-login data and disables accounts, plus a documented offboarding step that the identity provider is part of. Confirm which last-login fields your Keycloak version exposes to reporting and automation, and plan to show an assessor a run of that process, not only its design.

Requirements 8.2.8, 8.3.4, 8.3.6 and 8.3.7 are the settings most teams configure first. In the realm, set the session idle timeout so users must re-authenticate after more than 15 minutes of inactivity, and set the password policy to at least 12 characters containing both letters and numbers, with a history that blocks reuse of the last four passwords. Configure brute force protection so user IDs lock after no more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed. Confirm the exact option names and behavior in the Keycloak version you deploy, then test each value with a real login attempt. Point-of-sale accounts that can only see one card number at a time may fall under the exception in PCI SSC FAQ 1147, so agree that scope with your assessor early.

Requirement 8.4 and 8.5 are where most design decisions sit. Keycloak supports OTP policies, WebAuthn, passkeys with conditional and modal user interfaces, and recovery codes, which can cover MFA for CDE access (8.4.2), non-console administrative access (8.4.1) and remote access from outside your network (8.4.3). Phishing-resistant factors have specific limits: PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys can qualify for 8.4.2, while FAQ 1596 says phishing-resistant authentication alone does not satisfy 8.4.1 or 8.4.3. Under 8.5.1, the MFA system must use at least two different factor types, require all factors to succeed, and resist replay attacks. Decide early whether administrators can bypass MFA, how recovery codes are issued and stored, and who may approve a time-limited exception in writing.

Mapping PCI DSS requirement 8 sub-requirements to Keycloak settings

This table maps the PCI DSS v4.0.1 requirement 8 sub-requirements covered on this page to the Keycloak configuration area that supports each one, and to the controls that stay outside Keycloak. Use it to scope configuration work, then confirm each setting name and value against the Keycloak server administration guide for your release. The main takeaway is that Keycloak covers authentication logic, while HR processes, downstream applications and network access controls still need evidence of their own.

Requirement	What it asks in plain terms	Keycloak configuration area	What remains outside Keycloak
8.2.5	Revoke access for terminated users immediately.	Users area: disable or delete the account. Confirm the steps in the server administration guide's user management section.	HR termination trigger, timing evidence, and removal from applications that do not authenticate through Keycloak.
8.2.6	Remove or disable accounts inactive for 90 days or more.	Users area and user attributes. Confirm whether your release supports inactivity-based disabling in the server administration guide.	Scheduled inactivity reports, review sign-off, and cleanup of accounts held in directories or applications outside Keycloak.
8.2.8	Require re-authentication after a session has been idle for more than 15 minutes.	Realm settings, Sessions tab: idle timeout and client session settings. Confirm names in the server administration guide's sessions section.	Idle timeouts in applications, VPNs and jump hosts that do not use Keycloak sessions, and any documented exception such as point-of-sale accounts.
8.3.4	Lock user IDs after no more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed.	Realm settings, Security defenses: brute force detection. Confirm lockout duration and unlock options in the server administration guide.	Lockout behavior in directories or applications that authenticate separately, and the identity confirmation process for unlocks.
8.3.6	Passwords used as factors must be at least 12 characters and include numbers and letters.	Authentication, Policies, Password policy: length and character rules. Confirm available rules in the server administration guide.	Password rules for federated directories such as Active Directory, service accounts, and systems that set their own passwords.
8.3.7	Block reuse of any of the last four passwords.	Authentication, Policies, Password policy: password history. Confirm the history setting and its scope in the server administration guide.	History enforcement in federated directories and applications that store their own passwords, and their change procedures.
8.4.1, 8.4.2, 8.4.3	Require MFA for administrative access into the CDE, all CDE access, and remote access from outside the network.	Authentication flows with OTP, WebAuthn or passkeys, applied to CDE clients. Confirm options in the server administration guide.	MFA on VPNs, bastions, consoles and hypervisors outside Keycloak, vendor remote access, and phishing-resistant exception review.
8.5.1	MFA must resist replay, resist bypass unless documented and approved, use two factor types, and require all factors to succeed.	Authentication flow design with two factor types and no optional bypass step. Confirm flow options in the server administration guide.	Time-limited bypass approvals, factor device management, and evidence that the factor provider resists replay attacks.

Unique IDs and inactive account handling under PCI DSS 8.2

Requirement 8.2 depends on two things Keycloak cannot decide for itself: one identity per person, and timely disabling or removal of accounts. Keycloak stores users in a realm, and each user record is the object you disable, remove or audit. The control works only if every person who touches the cardholder data environment (CDE) has exactly one Keycloak user, and if that user's status changes when the person's employment or contract changes. Before you configure anything, decide which system is the source of truth for joiners, movers and leavers. In most organizations that is HR or a corporate directory, and Keycloak is a consumer of that record rather than the origin of it.

Requirement 8.2.5 requires access for terminated users to be revoked immediately, and Requirement 8.2.6 requires inactive user accounts to be removed or disabled within 90 days of inactivity. These two obligations need different triggers. Termination is an event that must reach Keycloak at once, so the lifecycle process should disable the user in the realm (and end active sessions) as part of the offboarding step, not in a nightly batch. Inactivity is a measured condition, so it needs a rule that evaluates last-login data, a named owner for the report, and a documented disable action. Confirm with the Keycloak version you run whether last-login timestamps are stored and reportable in your configuration, and whether the admin console or the Administration REST API exposes them for your query. Do not assume the console shows this by default.

Shared credentials need a deliberate position. PCI SSC FAQ 1080 addresses shared authentication credentials and makes clear that generic or shared accounts conflict with the unique-ID intent of 8.2.1 and 8.2.2. In Keycloak, the practical rule is to avoid creating shared users at all. Where a legacy system or service account truly needs a non-personal identity, record it as an exception with an owner, a justification, and a compensating control agreed with your Qualified Security Assessor, and keep it out of the normal user population so that inactivity reports do not hide it. Review every such account against the FAQ before you rely on it in an assessment.

Plan the process around a few concrete decisions: which attribute in the HR or directory feed maps to the Keycloak username, how disable and delete actions are separated (disabling preserves the audit trail, deletion may conflict with your retention rules), who approves exceptions, and how the 90-day evidence is produced each month. Automated provisioning through SCIM or a directory connector can reduce manual steps, but it still has to be tested against a leaver scenario. Confirm the inactivity tracking and reporting behavior against the exact Keycloak release you deploy, since this is the part of the control most likely to differ between versions and most likely to need a documented manual procedure.

What evidence Keycloak produces for a PCI DSS assessor

An assessor testing requirement 8 samples evidence that shows how Keycloak is configured and how it behaved over time. The items below separate point-in-time configuration from event records, because each needs a different capture method and a different retention plan. Confirm each item against your own realm settings and log pipeline before the assessment window opens.

Realm and user configuration exports

Realm exports and user listings show the settings in force at a dated point, including password policy, session timeouts, brute force detection and the status of each account. Export through the admin console or the Admin REST API, store the file with a timestamp and the Keycloak version, and record who ran it. Confirm that the export includes the brute force and session settings, since those carry requirements 8.2.8 and 8.3.4. Exports can contain sensitive values, so restrict who can hold them.

Password and session policy snapshots

Assessors often ask for a dated record of password rules and session lifetimes, not only the current state. Capture the password policy, the SSO session idle and maximum values, and any client-level overrides, then keep each capture beside the change ticket that set the value. Check that the policy enforces the 12-character minimum with numbers and letters under 8.3.6 and the four-password history under 8.3.7. Screenshots help, but an export is easier to compare over time.

MFA enrollment and required-factor settings

Requirement 8.4 expects MFA for access into the cardholder data environment, and 8.5.1 expects at least two factor types that must all succeed. Keep the authentication flow definition, the conditional MFA or required action settings, and the OTP or WebAuthn policy as evidence. Pair these with an enrollment report listing which accounts hold each factor type. Confirm whether any accounts depend on phishing-resistant authentication alone, since PCI SSC FAQs 1595 and 1596 limit where that route applies.

Admin event records

Admin events record configuration changes such as realm settings, client and user edits, and role assignments. They form the change trail behind every policy in this section and show who could alter lockout, timeout or MFA values. Enable admin event saving, decide whether representations are included, and confirm where the records are stored. Test one change to a password or MFA setting and check that it appears with the actor and time. Keep these records apart from the realm export so each setting can be traced to its author.

Login event and failure records

Login events show successful and failed sign-ins per user, which assessors use to test the lockout after 10 invalid attempts under 8.3.4 and the inactivity rules under 8.2.6. In Keycloak 26.8, login failures are persisted to the database by default, so lockout evidence sits in that store unless you change the setting. Retention, log shipping and access to the audit store are your responsibility. Set a retention period that covers the assessment window, forward events to a central log platform, and restrict who can query or delete them.

Prometheus metrics from the management interface

When started with metrics enabled, Keycloak exposes Prometheus-format metrics at /metrics on its management interface. These show request and login activity over time, which helps you spot unusual authentication volume and corroborate event records. Confirm that the endpoint is reachable only from your monitoring network and never from the public frontend. Metrics do not replace event records, so keep scrape data under your own retention policy and confirm which histograms your version exposes.

How CDE scope and the approach you choose change the Keycloak design

Requirement 8 applies to access into the cardholder data environment (CDE), so the boundary you draw around it decides which Keycloak settings must follow the PCI DSS rules. Before you configure anything, list which realms, clients and admin console functions can reach systems in the CDE. A payment application client that issues tokens for CDE access falls under the MFA and timeout rules for that access. A marketing or internal HR realm that never touches the CDE may not. The admin console deserves separate treatment, because administrative access into the CDE falls under 8.4.1 and administrators can change the settings that enforce every other control. Map each realm, client, role and admin group to a yes or no answer on CDE access, and keep that map as scoping evidence.

Requirement 8 is met through one of two approaches. The defined approach follows the requirement as written, with the values and mechanisms it names. The customized approach, available to entities with robust security and risk management, meets the stated objective of a requirement in a different way. The PCI SSC blog on compensating controls versus the customized approach explains that these are different paths and that a compensating control is not the same thing as a customized implementation. If your design departs from a defined-approach setting, for example a different MFA mechanism or a timeout arrangement that differs from the 15-minute idle rule, you need a documented objective, a risk analysis, the evidence that supports the design, and agreement from your Qualified Security Assessor before the configuration goes live. Retrofitting that agreement after an assessment starts is far harder.

Confirm scope and approach with your payment brand or QSA before configuration starts, not after. Ask them which systems they consider in scope, whether any Keycloak realm or client is out of scope and what evidence supports that position, and whether they accept a customized approach for any part of requirement 8. Ask how they expect Keycloak session settings, admin console access and federated identities to be documented. Ask whether a phishing-resistant authentication design needs the same scope analysis as a standard MFA design. Write the answers into the design record with dates and names of the people who gave them.

Plan for scope drift. A new client added to a shared realm, a new federation link to a directory that serves CDE systems, or a new administrator group can move systems into scope without anyone changing the requirement mapping. Assign an owner to review the realm and client inventory on every change, and record the reason for each new client's scope decision. Also check that environments used for testing or staging do not contain production cardholder data or live credentials for CDE systems, because those environments may then fall into scope as well.

The cost and effort of this work depend on how many realms, clients and federated directories sit near the CDE, how much of the design needs an alternative approach, and how many assessor review cycles you expect. Ask any implementation partner to price the scoping review, the approach documentation and the assessor consultation as separate line items, so you can see what is one-time and what must be repeated when scope changes. Ask for a list of the assumptions they make about your environment, and for a statement of which decisions remain with your QSA or payment brand.

What Keycloak does not cover in PCI DSS requirement 8

Keycloak can enforce several Requirement 8 settings, but much of the requirement depends on processes, network design and records outside the platform. The cards below list the gaps to plan for before an assessment. The Report on Compliance or Self-Assessment Questionnaire with an Attestation of Compliance is produced by the assessed entity and its Qualified Security Assessor, and DeployOpen and the Keycloak project do not produce it.

Inactive and terminated accounts

Requirement 8.2.6 requires inactive accounts to be removed or disabled within 90 days, and 8.2.5 requires access for terminated users to be revoked immediately. Keycloak can disable accounts, but it only learns about a leaver when something tells it to act. Check the HR feed or ticket trigger that disables the Keycloak user, who owns that workflow, and how the 90-day inactivity check is run, reviewed and kept as evidence.

CDE boundary and network controls

If Keycloak authenticates access to the cardholder data environment, its hosts, database, reverse proxy and admin endpoints fall inside the scope your assessor defines. Requirement 8 depends on network controls that limit who can reach the login flow and the Administration REST API. Document which hostnames, proxy paths and database connections are in scope, and confirm the admin console is reachable only from approved administrative networks.

MFA bypass exceptions and authorization

Requirement 8.5.1 requires that MFA cannot be bypassed, including by administrators, unless management documents and authorizes the bypass for a limited time. Any administrator who can reset credentials or change required actions can create a bypass, so those permissions need the same scrutiny as the exception itself. Define who may approve a temporary exception, record its reason and expiry, review open exceptions regularly, and confirm the factors in use are at least two different types.

Authentication method per population

Requirements 8.4.1 to 8.4.3 require MFA for administrative access, all access into the CDE and remote network access. The phishing-resistant note in v4.0.1 removes the MFA requirement only for accounts that use phishing-resistant authentication alone. Keycloak supports OTP, WebAuthn and passkeys, but the right choice differs for staff, administrators, customers and service accounts. Assessor FAQs treat synced passkeys and phishing-resistant authentication differently by requirement, so confirm each population's method against the current FAQs before writing it into policy.

Third-party and vendor remote access

Requirement 8.4.3 applies MFA to all remote network access from outside the entity's network, including third parties and vendors. Keycloak can enforce MFA for accounts it holds, but vendor access often arrives through a VPN, jump host or the vendor's own identity provider, none of which Keycloak sees. Inventory every remote path, decide whether each vendor identity lives in Keycloak or is brokered, and keep vendor account reviews and sponsor approvals in the access policy.

Password rules beyond the platform

Keycloak can enforce password length, character rules, history and lockout for accounts in a realm, but Requirement 8.3 also reaches systems that do not authenticate through Keycloak. Requirement 8.3.6 sets a 12-character minimum with both numbers and letters, 8.3.4 requires lockout after no more than 10 invalid attempts, and 8.3.7 bars reuse of the last four passwords. Check local, service, appliance and database accounts outside Keycloak against the same rules, and confirm how their passwords are hashed and stored.

Configuration sequence for requirement 8 in Keycloak

This sequence takes Keycloak from scope agreement to an assessor-ready evidence pack for PCI DSS requirement 8. Each step closes with a check you can show, from TLS and admin separation through password, session, lockout and MFA settings to the bypass procedure and test log.

Confirm scope and approach with the assessor
Agree in writing with your Qualified Security Assessor, or with the team completing your SAQ, which systems form the cardholder data environment (CDE), which remote paths reach it, and whether requirement 8 will use the defined approach or the customized approach. Ask the assessor how they expect Keycloak configuration and logs to be evidenced and which identities count as administrators. Done when the scope statement and approach are on file and the assessor has confirmed the Keycloak realms, clients and admin paths in scope.
Confirm Keycloak edition, version and database
Record the distribution you will run, either the open source Keycloak project or the Red Hat build of Keycloak, and the exact version you will certify against. The current Keycloak release is 26.8.1, published October 13, 2026, so confirm with your vendor and your change calendar whether that release or another supported line fits. Select a production database from the supported list, such as PostgreSQL 14 to 18, and confirm the default dev-file database is not used. Decide between automatic and manual schema migration at startup. Done when the version, distribution and database are written into the configuration baseline.
Deploy TLS and separate the admin hostname
Follow the production guidance to encrypt all communication with TLS, place Keycloak behind a reverse proxy with path restrictions, and serve the admin console and Administration REST API on a hostname or context path separate from public frontend URLs. Limit administrative access to a management network or the CDE, and require MFA for every admin session. Test that the admin paths do not respond on the public listener. Done when an external check shows only the public sign-in and application endpoints, and the TLS and proxy settings are captured in the baseline.
Define the identity lifecycle feed
Name the authoritative source for workforce and third-party identities, such as HR records or an identity governance system, and decide how joiners, movers and leavers reach Keycloak. Each person gets a unique user ID, and any shared or generic account is documented as an exception for assessor review. Build a process that revokes terminated users immediately and disables or removes accounts after 90 days of inactivity, as requirements 8.2.5 and 8.2.6 require. Set up last-login reporting that drives the inactivity check. Done when a test leaver is disabled in the source system and the change appears in Keycloak with a timestamp.
Set session, password and lockout policy and test each value
In the realm settings, set the session idle timeout so users must re-authenticate after more than 15 minutes of inactivity. Configure a password policy requiring at least 12 characters with both numbers and letters, a history rule that blocks reuse of the last four passwords, and brute-force detection that locks a user ID after no more than 10 invalid attempts for at least 30 minutes or until identity is confirmed. Review the point-of-sale exception in PCI SSC FAQ 1147 with the assessor. Test each value with a scripted attempt and log the result. Done when every setting has a passing entry in the test log.
Configure MFA factors and required-factor logic
Enable OTP, WebAuthn or passkeys, and recovery codes, then build authentication flows that require MFA for CDE access and for remote network access from outside your network, including third parties and vendors. Requirement 8.5.1 needs at least two different factor types, and all factors must succeed before access is granted. Confirm with the assessor whether any synced passkey meets the criteria in PCI SSC FAQ 1595, because FAQ 1596 states that phishing-resistant authentication alone does not satisfy 8.4.1 or 8.4.3. Done when test logins from inside and outside the network each require the expected factors and a failed factor blocks access.
Define bypass authorization and enable logging
Write a bypass procedure that names who may approve an MFA bypass, the approval record, the time limit and the review after use, since requirement 8.5.1 requires management to document and authorize any bypass for a limited time, including bypasses by administrators. Configure the break-glass path to be disabled by default and logged. Enable Prometheus-format metrics with --metrics-enabled=true on the management interface, then turn on login and admin event logging. Set event retention to what your policy and assessor require and confirm events reach your log platform. Done when a test bypass produces an approval record and matching login and admin events.
Produce the evidence pack and test log
Assemble the configuration export, scope statement, policy and bypass records, a dated export or screenshot of each setting, the lifecycle test results, and a test log that maps each test to its requirement number. If you run the Keycloak Operator, set manual approval mode for operator updates, as its documentation strongly recommends. Test every upgrade in a non-production environment against the upgrade notes, including the 26.8 changes to SMTP StartTLS and backchannel logout validation, before approving it. Done when the assessor has the pack and has confirmed which items they will sample. DeployOpen prepares this evidence, and the assessor issues the findings.

How much effort does a PCI DSS requirement 8 Keycloak setup take?

What factors change the effort for a Keycloak identity build?

Scope is the largest driver: how many realms, clients and applications sit inside the cardholder data environment (CDE), and how many user populations they serve. Each added realm or application adds configuration, testing and evidence work.

Other drivers:

The existing directory and HR feeds, such as LDAP or Active Directory federation or a manual user process
The MFA method chosen for CDE access
The deployment model, whether cloud accounts, data centers or an air-gapped network
How much evidence your assessor expects you to produce

Scope decisions made early, such as which access paths count as entering the CDE, usually prevent the most rework. Ask any provider to break its quote down by these drivers so you can see which ones move the price.

Can our internal team set up Keycloak for PCI DSS requirement 8 alone?

Yes, for the configuration itself, if your engineers already run Keycloak and understand the requirement 8 controls. Unique user IDs, the 15-minute re-authentication timeout, password rules, lockout and MFA can all be built in-house.

The harder parts sit outside the product. Someone must own the scope decision, maintain the relationship with your Qualified Security Assessor (QSA), decide how exceptions are approved and documented, and confirm that the design meets each requirement as written. Those roles need named owners whether or not a partner is involved.

Teams that lack either Keycloak or PCI experience often find that most of their time goes into interpreting requirements and testing. Assess your skills honestly before deciding.

What does DeployOpen need from our team before work starts?

DeployOpen needs decisions and access more than it needs hardware. Expect to provide:

Confirmed scope: which systems, networks and administrative paths are inside or outside the CDE
Environment access: the target environments and your change process
Identity data: directory extracts and HR joiner, mover and leaver feeds, with rules for handling personal data
An MFA decision: the method and factor combination your environment can support
A named owner: someone who can approve exceptions and accept the design
Engineer time: reviewers and test windows

Missing any of these usually delays the schedule. The written scope should list each dependency so both sides agree on it before work begins.

How long does a fixed-scope Keycloak engagement usually take?

The duration depends on scope, and the written agreement fixes it before work starts. Timelines follow the number of realms and applications, the directory and HR integrations, the MFA rollout, and the amount of testing and evidence required.

A single realm with one directory and a standard MFA method is a much narrower job than several realms with federated identity and a phased cutover. Because most engagements are fixed-scope, DeployOpen states deliverables and timelines in writing. Changes to scope are handled through a written change to that agreement.

Ask any provider for a schedule with named milestones, the dependencies on your team, and the test windows it assumes. Be cautious of any timeline quoted before the scope has been mapped.

Does DeployOpen certify that our Keycloak setup meets PCI DSS?

No. DeployOpen does not issue audit reports, attestations or certifications. It plans, configures, documents and tests the Keycloak controls for requirement 8, and it prepares the systems, controls and evidence that your assessment will examine.

Under PCI DSS, an assessment is documented either in a Report on Compliance completed by a QSA or in a Self-Assessment Questionnaire, each backed by an Attestation of Compliance. The payment brands decide which entities must validate. Your QSA, or the assessor for your questionnaire, makes the determination for your environment. Certificates are not recognized as validation.

Ask your assessor early which evidence they will accept for each requirement 8 control, so the build produces it.

How does the MFA method change the effort for requirement 8.4?

The MFA method changes both the build and the evidence. Requirement 8.4 covers MFA for administrative and general access into the CDE, and for remote access from outside your network, including third parties and vendors. Requirement 8.5.1 adds conditions for MFA systems: replay resistance, no bypass unless management documents and authorizes it for a limited time, at least two different factor types, and success of all factors before access is granted.

Keycloak documents OTP policies, WebAuthn, passkeys and recovery codes. Whether a given combination satisfies 8.4 and 8.5.1 in your environment is a decision for your assessor. Recovery codes and bypass paths need the closest scrutiny.

Confirm the factor combination with your assessor before configuring it, because changing it after rollout multiplies the testing.

What should a written quote for this work include?

A quote should follow from a written scope, so define the scope first. Look for these items:

The realms, clients and applications inside the CDE
The directory and HR integrations
The MFA methods in scope
The environments covered, including test and production
An evidence list mapped to each requirement 8 control
The testing approach and who performs it
Handover and documentation
Any recurring work, such as updates or support

Separate one-time build costs from recurring costs. Ask which party pays for assessor time, since that sits outside the build. Ask what changes would trigger a new quote and how they are approved. DeployOpen does not publish a price list, so the written scope is the basis for any figure.

What usually breaks in a Keycloak PCI DSS requirement 8 build?

Most failures come from settings that look correct in isolation but do not hold across the whole access path. Illustrative examples to check:

A session timeout set on the realm while a client keeps its own longer session
Lockout configured for the console but not for logins federated from a directory
Password rules applied to new accounts only
Shared or generic accounts used for support or service work, which conflicts with unique ID requirements
Inactive or terminated users left enabled because the HR feed does not trigger a disable

Admin console and Administration REST API exposure also widens the path into the environment if it is not separated from public hostnames. Test each control with a live sign-in through every path into the CDE, and keep the results as evidence, including the test date and the configuration version.

How DeployOpen scopes Keycloak requirement 8 work

DeployOpen scopes Keycloak for PCI DSS requirement 8 as a fixed-scope written engagement covering unique IDs, inactive account handling, the idle session timeout, password and lockout settings, and MFA for access into the cardholder data environment. We plan, configure, test and document these controls in infrastructure you control, and prepare the evidence your assessor will review, while the assessment itself remains with your QSA or your self-assessment process.

How we scope

The written scope lists which Keycloak realms, clients and admin paths sit inside the cardholder data environment.
We confirm with you which 8.4 access paths apply, including console, remote and third-party access, before configuration begins.
Engagements are fixed-scope, with deliverables agreed in writing before work starts, and ongoing support available as a retainer.

How we build

Configure password policy, lockout and password history settings in the realm, then test each value against the 8.3 requirements.
Set idle session timeouts for 8.2.8, and confirm any point-of-sale exclusion with your assessor.
Enforce MFA for CDE access with two factor types, such as OTP or WebAuthn, aligned to 8.5.1.

How we hand over

Deliver a configuration record mapping each 8.2 to 8.5 setting to its realm, client or flow location.
Provide test evidence for lockout, idle timeout, inactive-account and MFA behavior, ready for your assessor's review.
Document the operating runbook for disabling accounts within 90 days of inactivity and revoking terminated users immediately.

How we support

Plan Keycloak upgrades with the Operator on manual approval, so each release's settings are reviewed before rollout.
Review 8.2 and 8.3 settings after each release, since release notes can change defaults such as login failure storage.
Agree the support scope in writing, including retainer coverage for ongoing configuration review and upgrade testing.