8.2 User identification and account lifecycle

What PCI DSS 8.2 asks for and why assessors focus on it

When an assessor or a payment brand asks for proof that account IDs are managed across their lifecycle, they want to see that every person and every account in the cardholder data environment can be tied to one accountable identity from creation to removal. Requirement 8.2 covers that lifecycle: unique IDs, tightly controlled shared accounts, approved changes to accounts, immediate revocation for terminated users, disabling inactive accounts within 90 days, controls on third-party remote access accounts, and idle session timeouts of 15 minutes. Each of these is a separate test, so a gap in any one of them can fail the requirement even when the rest of the account process works. The underlying risk is simple. An orphaned account belongs to someone who has left or a process that no longer exists, and nobody is watching it. A shared account hides who did what, so a card data incident cannot be traced to a person. A stale account that still works after months of inactivity gives an attacker a quiet entry point that looks legitimate in the logs. Assessors focus on 8.2 because these failures are common and hard to see from the outside, and because account misuse often sits behind card data breaches. The requirement is hard in practice because identity data rarely lives in one place. Users may exist in a corporate directory, in local accounts on servers, in database logins, in cloud consoles and in vendor portals, and a leaver removed from the directory can remain active everywhere else. Before the assessment, confirm with your team which systems in the cardholder data environment hold their own user stores, who owns the leaver process for each one, and how you would prove the removal date for a sample of former staff. Those answers shape most of the remediation work.

Which accounts and teams PCI DSS 8.2 reaches

Requirement 8.2 applies to every account that can touch the cardholder data environment, but the workload changes sharply depending on how those accounts are shared, who owns them and how they reach the environment. The cards below name the scoping decisions that most often change the effort, so you can settle them before you size the controls.

User accounts inside the CDE

Every named user who can log in to a system in the cardholder data environment falls under 8.2, including administrators, support staff and developers with production access. The decision to make is which systems and directories count as in scope, since a corporate directory that feeds CDE logins brings its joiner, mover and leaver processes into the assessment. Confirm the list of in-scope systems against your data-flow diagram, then trace each one to the identity source that creates and removes its accounts.

Systems that could affect the CDE

PCI DSS scope extends beyond systems that store or process card data to systems that could affect their security, such as jump hosts, logging servers, patching tools and domain controllers. An account on one of these supporting systems can grant access to the CDE indirectly, so it needs the same unique ID and revocation discipline. Ask your assessor to confirm which supporting systems they consider connected, because that answer determines how many accounts you must review.

Shared and generic accounts

A shared or generic account, such as a single operations login used by an on-call rotation, is the scoping decision that most often forces a redesign. Under 8.2.2, shared credentials are allowed only in exceptional circumstances and must meet every element of that requirement. Because the standard expects accountability for each action, a password vault that records who checked out a shared ID is the usual way to keep individual identity traceable. Inventory every shared ID before you decide whether to remove it.

Service provider accounts with customer factors

If your organization is a service provider, 8.2.3 adds a condition: customer access must use authentication factors that are unique to each customer, so one customer's credential cannot unlock another's environment. This changes the design of shared hosting consoles, managed support portals and administrative tooling that spans customers. Confirm with your assessor how each tenant's factors are kept separate, and document the mechanism in the same evidence set as your user lifecycle records.

Third-party remote access accounts

Vendors, integrators and managed service staff who connect remotely to the CDE hold accounts that sit outside your HR process, so they are easy to forget. Requirement 8.2.7 expects these accounts to be enabled only for the time needed, disabled when idle, and monitored for unexpected activity. Build a register that records each vendor account, its owner, its approved window and its last use, and reconcile it against the access granted in your remote access tools.

The point-of-sale single-card exception

FAQ 1147 states that the 15-minute re-authentication rule in 8.2.8 does not apply to point-of-sale accounts that have access to only one card number at a time. This exception matters only when the account truly has that narrow access, so the work is in proving it. Map each point-of-sale account to the card data it can reach, and where any account can view several card numbers in one session, apply the standard idle timeout.

How an assessor tests PCI DSS 8.2

This table compares each 8.2 sub-requirement group with the test an assessor usually runs, the evidence they request and the findings that come up most often. Assessors sample accounts and compare directory records with system account lists and termination tickets, so the gaps show up where those sources disagree.

Requirement group	Test approach	Evidence requested	Common findings
Unique IDs (8.2.1)	Sample user IDs across systems in scope and confirm each maps to one person	Directory export, system account lists, HR roster for the sampled IDs	Duplicate or generic IDs reused by several staff
Shared and generic accounts (8.2.2)	Confirm each shared ID is an approved exception and that individual accountability holds	Exception records, approval, password vault logs showing individual checkout	Shared admin logins with no individual trace; FAQ 1080 limits when these are acceptable
Approved account changes (8.2.3)	Trace a sample of new accounts and privilege grants back to an approval	Access request tickets, approver sign-off, change logs	Accounts created directly on systems without a ticket
Termination revocation (8.2.5)	Match leaver records from HR against disabled accounts and check timing	HR termination dates, account disable timestamps, termination tickets	Accounts left active after departure, or disabled days later than the HR record
Inactive accounts (8.2.6)	Pull last-login data and confirm accounts idle beyond 90 days are removed or disabled	Last-login reports, disable or removal records, review output (FAQ 1066)	Dormant service-style user accounts never reviewed
Third-party remote access (8.2.7)	Confirm vendor accounts are enabled only for the work window and monitored	Vendor access schedules, enable and disable logs, monitoring alerts	Vendor accounts left permanently enabled after a project closes
Idle session timeout (8.2.8)	Test an idle session on in-scope systems and check re-authentication at the 15-minute mark	Configuration exports, screenshots or test results, FAQ 1147 scoping note for point-of-sale accounts	Timeouts set on the portal but not on admin consoles or jump hosts

How to implement PCI DSS 8.2 in sequence

This sequence turns the 8.2 account lifecycle into a working set of controls, each with a named output that an assessor can sample. Work through it in order so that identity records, exception handling and deprovisioning exist before you test them.

Inventory every system holding CDE accounts
List each system, application, database, jump host and cloud console that stores or can reach the cardholder data environment, and record where local user accounts exist. Assign an owner to each entry and note whether accounts are human, shared, service or third-party. The output is an account inventory that the rest of the sequence reads from. You know it is done when every CDE component has at least one owner and an account type recorded.
Define a single source of truth for identities
Choose one directory or identity provider as the authoritative record of users and groups, such as a self-hosted LDAP directory or an identity broker that federates to your existing directory. Connect the CDE systems to it through single sign-on or directory binding where the platform supports it. The output is a documented identity source and a list of systems that authenticate against it. Confirm each platform's integration options with its vendor before committing.
Enforce unique IDs and an exception process for shared accounts
Configure the directory so that every person gets a unique ID, and remove or rename generic accounts that multiple people use. Where a shared credential is unavoidable, write an exception procedure that meets every element of 8.2.2 and records approval, scope and review. Use a password vault where it helps tie each use of a shared ID to an individual. The output is a unique-ID standard, a register of approved shared accounts and vault access logs. Your assessor will check both the exception record and the accountability trail.
Wire joiner, mover and leaver events to deprovisioning
Connect your HR or access request source to the identity source so that creating, changing or ending a user drives the matching account change in each CDE system. Use provisioning connectors where available, such as SCIM 2.0 push from an identity provider, and document any system that still needs manual steps. Approved changes must flow through a recorded request. The output is a tested leaver path that revokes access for terminated users immediately, plus a change log for role moves. Test it by terminating a sample test account and confirming revocation in every connected system.
Set inactivity and idle timeout controls
Configure the directory and each CDE system to disable or remove accounts that have been inactive for the period defined in 8.2.6, and to require re-authentication after the idle limit in 8.2.8. Check the point-of-sale exclusion described in PCI SSC FAQ 1147 before applying it to any system, and document any system that is exempt and why. Store the settings in version control where possible. The output is a configuration record per system and a report of accounts flagged for inactivity. Confirm the exact settings with each system's documentation.
Configure third-party access with enable-on-demand and monitoring
Create a separate account class for third-party remote access under 8.2.7. Keep these accounts disabled by default, enable them only for an approved window tied to a ticket, and disable them when the work ends. Log their sessions and set alerts for activity outside the approved window. The output is an enable-on-demand procedure, a list of third-party accounts with their approval records, and monitoring evidence. Assessors commonly ask for a sample of these approvals against actual login records.
Test each control with a sample before the assessment
Select a sample of active accounts, shared accounts, leavers, inactive accounts and third-party accounts, and trace each one through the controls you built. Record the expected result, the observed result and any gap, then fix gaps and retest. Keep the test scripts, screenshots, exports and tickets in one evidence folder mapped to 8.2.1 through 8.2.8. The output is a pre-assessment test record that your internal team or independent advisers can review. The assessor makes the final determination, so present the evidence as your own testing rather than as a validation.

Which evidence satisfies PCI DSS 8.2

An assessor testing 8.2 looks for proof that account lifecycle controls worked across the whole period under review, not only on the day of the assessment. The cards below cover the artifacts that usually pass and how to keep each one current between audits.

Account inventory exports

A dated export of every user and shared account from each in-scope system, including the CDE, administrative consoles, jump hosts and cloud accounts. Assessors compare it against HR records and the identity provider to confirm each ID is unique and attributable to one person. Schedule the export monthly, store it with a hash or change log, and reconcile differences the same week. The inventory must match what the system actually shows, so export from the system itself rather than from a spreadsheet.

Identity provider and directory configuration

Configuration evidence shows how accounts are created, grouped and removed. Keep exports of the directory schema, group membership rules and provisioning connectors, for example from FreeIPA, Keycloak or authentik. Version-control these configurations so you can show what changed and when. Check that disabling a user in the directory propagates to every connected application, because a configuration that looks correct on paper can still leave local accounts active.

Approved change records for accounts

Each account creation, privilege change and shared-credential change needs a ticket showing who requested it, who approved it and when it was implemented. Link tickets to the identity system's audit log so the approval and the actual change can be matched. Review a sample each month. Gaps usually appear when administrators make quick changes directly in a console, so restrict console access and require tickets for every change.

Termination tickets matched to revocation

For 8.2.5, assessors compare HR termination records with the time access was revoked in each system. Keep the termination ticket, the directory disable event and the application deprovisioning log together for each leaver. The gap between termination and revocation is the figure that gets questioned, so record timestamps in a single time source. Include contractors and departing administrators, who are often missed.

Inactivity reports and disable actions

Run a recurring report of last login dates for every account, then show that accounts past the inactivity threshold were disabled or removed. Under 8.2.6, the limit is 90 days. Automate the report and retain each run, plus the disable actions taken on the flagged accounts. Document exceptions with a named approver so the report does not look like a list of unexplained active accounts.

Idle session timeout configuration

Under 8.2.8, sessions idle beyond the limit must require re-authentication. Keep screenshots or configuration exports from each application, identity provider and jump host that shows the timeout setting, along with the change record for any modification. Test the setting periodically and keep the result. Confirm with your assessor how point-of-sale accounts with single-card access are treated, since PCI SSC guidance addresses that case.

Third-party remote access approvals and logs

Vendor accounts under 8.2.7 should be enabled only for the agreed work window and disabled otherwise. Keep the access request, the approval, the enable and disable log entries, and the monitoring records for activity during each session. Maintain a register of every third-party account with its owner and expiry date, and check the register against the directory each month to catch accounts that stayed enabled after the work ended.

Shared account exception records

Shared credentials are allowed only in exceptional circumstances and must satisfy every element of 8.2.2. Keep a record for each exception that names the account, the business reason, the compensating accountability method, such as a password vault that logs individual check-out, and the approver. Review each exception on a set schedule and remove it when the need ends, since PCI SSC FAQ 1080 makes clear that exceptions must be justified, not assumed.

What meeting PCI DSS 8.2 costs in money and effort

This table breaks the cost of meeting Requirement 8.2 into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up. No price figures are supplied for this topic, so use the drivers to build your own estimate and to frame the questions you put to vendors, integrators and assessors. Where self-hosted open source is used, license spend falls away but labor and evidence upkeep remain.

Cost component	One-time or recurring	Who is paid and what drives it
Identity tooling or licenses	One-time setup, then recurring if commercial	Open-source platforms such as authentik, FreeIPA, Keycloak or Zitadel remove license fees, but hosting, patching and support staff still cost money. Commercial identity sources add recurring license spend tied to user count.
Engineering time for integration and deprovisioning	One-time per application, then recurring upkeep	Internal engineers or an implementation partner connect each application in the cardholder data environment to the identity source. Cost rises with the number of applications in the CDE and the number of identity sources.
Inventory and evidence upkeep	Recurring	Staff maintain the account inventory, shared account register, leaver records and session timeout settings. Effort rises with leaver volume, manual provisioning steps and the number of accounts that must be justified.
External testing or review of account controls	Recurring, usually annual or after major change	Independent testers or reviewers check account lifecycle controls. Ask providers to scope account lifecycle tests separately from general penetration testing so the fee reflects the actual work.
Assessor sampling time	Recurring, at each assessment	The QSA samples accounts, leavers, inactive IDs and session timeouts. Effort rises with the number of systems in scope and how easily evidence can be pulled. Confirm assessor fees directly with the QSA firm.

Which open-source identity tools support PCI DSS 8.2 evidence

Requirement 8.2 is proven with records: who holds an ID, when access changed, when it was revoked, and when sessions timed out. The tools below can generate or centralize much of that record, but each one covers a different part of the lifecycle. Your assessor will want to see the configuration and logs from your own environment, so confirm each capability there before relying on it.

authentik SCIM provisioning

authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and removes users from the target application when they lose access. For 8.2.5 and 8.2.6, this is the mechanism that should remove a leaver's access to downstream CDE applications, so the evidence is the sync log showing the deprovisioning event and its timestamp. Confirm that every in-scope application is connected, and test the deprovisioning path before an assessor asks. Note that authentik is MIT licensed, so review your obligations for any modifications you ship.

FreeIPA central directory

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It provides centralized access control and delegated administration through its web UI and command line tools. For 8.2, it can serve as the single authoritative source of unique user IDs, so that each person maps to one account and group membership changes are recorded in one place. Delegated administration helps show that only approved administrators can create or change accounts. Confirm the audit trail for account changes in your deployment. FreeIPA is licensed under GPL-3.0-or-later, so confirm how that license applies to your distribution and integration.

Keycloak single sign-on

Keycloak provides single sign-on, so users authenticate once with Keycloak rather than separately in each application. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to existing OpenID Connect or SAML 2.0 identity providers. For 8.2, a single sign-on point reduces the number of local accounts that must be reviewed for inactivity and termination. Disabling a user in Keycloak then stops access to every integrated application that relies on it. Confirm that applications with local accounts, such as database or administrative consoles, are not left outside this control. Keycloak is Apache-2.0 licensed, which is permissive, but confirm your own attribution and notice obligations.

Zitadel identity brokering

Zitadel acts as a central identity broker, so users can sign in through external identity providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. Applications then trust Zitadel rather than each provider separately. For 8.2, the risk is that a user disabled in the external provider still holds a session or cached access in Zitadel. Confirm how external account disablement propagates, and document the revocation timing you rely on for 8.2.5. Zitadel is licensed under AGPL-3.0-only, which carries network-use source disclosure obligations if you modify it and offer it to users, so have counsel review that before deployment.

Who does what for PCI DSS 8.2

Your organization owns the account lifecycle. The controls only mean something if your own people decide who gets an ID, who approves a change, and who is responsible for removing access when someone leaves. An assessor will ask for the policy and the procedures behind each sub-requirement, and will expect staff to explain them in their own words, so these decisions cannot be handed off.

Account policy: Define how IDs are requested, approved, changed and retired, and who signs off each step.
Authoritative identity source: Name the system of record, such as an HR platform or directory, that drives account creation and termination.
Leaver process: Document how terminations trigger immediate revocation and who confirms it was completed.
Shared and third-party accounts: Keep an inventory of any shared credentials, the exceptional reason for each, and the owner who approves remote third-party access.
Inactivity and session review: Assign an owner for the 90-day inactivity check and the 15-minute idle timeout settings.

Before engaging anyone, confirm that your team can name each control owner and produce the approval records for the last review period.

Where organizations usually fail PCI DSS 8.2

Most 8.2 findings are not missing technology. They come from account lifecycle steps that depend on someone remembering to act, in systems that do not talk to each other. The cards below cover the gaps assessors most often trace back to HR events, shared credentials, manual checks, timeouts, vendor access and unreconciled inventories.

Leavers still active in one application

The directory disables a departed employee, but a billing tool, reporting console or legacy admin panel keeps a local account that nobody removed. Requirement 8.2.5 expects access for terminated users to be revoked immediately, so the gap is usually in applications that authenticate outside the central source. Check each in-scope application against the HR termination list and confirm that its local accounts are removed or disabled on the same day.

Shared administrator accounts without accountability

Teams often share a single administrator login for a database, firewall or cloud tenant because it is faster than issuing individual IDs. PCI SSC FAQ 1080 allows shared credentials only in exceptional circumstances, and each element of 8.2.2 must still be met. A password vault that ties each checkout to a named person is the usual way to keep accountability, so confirm that every shared credential has a documented exception and an audit trail.

Inactivity checks run by hand and not evidenced

A spreadsheet review of last-login dates may happen once a quarter, but nothing records that it happened or what was disabled. Requirement 8.2.6 expects inactive user accounts to be removed or disabled within 90 days of inactivity, and an assessor will ask for proof across every in-scope system. Automate the last-login report, run it on a schedule, and keep the output and disablement tickets as evidence.

Idle timeouts set only on the directory

Teams configure a session timeout in the identity provider and assume every application inherits it. Requirement 8.2.8 requires re-authentication after more than 15 minutes of idle time at the application level, so a session cached by a web app or thick client can stay open far longer. Test each in-scope application directly by leaving a session idle, and record the observed result rather than relying on the directory setting.

Vendor accounts enabled permanently

Support engineers and integrators often receive remote access accounts that stay enabled long after the work ends. Requirement 8.2.7 asks that third-party remote access be enabled only for the time needed, disabled when idle, and monitored for unexpected activity. Ask each vendor for its access window, tie activation to a change ticket, and confirm that the account is disabled automatically when the window closes.

No reconciled account inventory

Accounts exist in the directory, in each application, in cloud consoles and in service tooling, and no single list reconciles them. Without that list, a terminated user or stale vendor account can hide in a system nobody thought to check, and the 8.2 evidence cannot be produced for the full scope. Build one inventory of accounts per system, reconcile it against the authoritative identity source each quarter, and record every difference with its resolution.

Common questions about PCI DSS 8.2 cost, effort and help

How much effort does PCI DSS 8.2 take, and what drives it?

The effort depends mostly on how many user identities, shared accounts and third-party access paths sit inside the cardholder data environment, and on whether those identities already come from one directory. Requirement 8.2 has eight sub-requirements, so the work splits into identity inventory, lifecycle rules for joiners, movers and leavers, shared account reduction, and session controls. Organizations with a central identity provider usually spend most effort on cleaning up old accounts and proving the lifecycle works. Organizations with local accounts on many systems spend more on inventory and consolidation. Ask any provider for a quote built from your account count, system list and identity sources, and confirm which of these items are one-time and which recur, such as quarterly account reviews.

Can an in-house team meet PCI DSS 8.2 without a consultant?

Yes, an in-house team can meet 8.2 without outside help, because the standard does not require a consultant. The organization owns its controls and must be able to show them to its assessor. The harder questions are whether the team has time to build an inventory of every account, whether it can reconcile HR leaver data with system access, and whether it can document the policies and evidence that show the rules operate. Teams that lack directory administration or identity engineering experience often find the evidence work takes longer than the configuration. An implementation partner can prepare systems and evidence under a written scope, but the organization still answers for the outcome.

How long does preparing for PCI DSS 8.2 usually take?

No supplied source gives a standard duration for preparing 8.2, so treat any single number with caution. Preparation time depends on the number of identity sources, how many systems have local accounts, whether shared IDs exist for operational reasons, and how much the lifecycle process already runs through an HR-driven workflow. It also depends on how long it takes to remove or reassign inactive accounts safely and to get owners to approve exceptions. Ask providers to break the timeline into inventory, design, deployment and evidence collection, and ask which of those steps depend on your team's availability. Your assessor's timing will also affect the calendar.

What does the client's team need to provide for 8.2 work?

The client's team needs to supply the facts that only it holds. These include the list of systems in the cardholder data environment, the identity sources and their owners, the HR process for hires, role changes and terminations, and the names of anyone who approves access. The team also needs to decide which shared or generic accounts are truly required, and who owns each one. Service accounts used by third parties need named owners and documented remote access windows. Plan time for system administrators to test session timeout settings, because some applications handle idle sessions differently. Confirm these responsibilities in the written scope before work starts.

Can a partner prepare 8.2 evidence without affecting assessor independence?

A partner can prepare systems, configuration records and evidence for 8.2 without affecting an assessor's independence, provided the roles stay clear. The organization owns its controls. The implementation partner prepares systems and evidence. Only a Qualified Security Assessor or another independent assessor tests the controls and issues the Report on Compliance or Attestation of Compliance. Ask any partner to confirm in writing that it will not perform the assessment, and ask your QSA which preparation work it accepts. Agree on the evidence format early so the assessor can test it directly. Keep the scope of preparation separate from the scope of validation.

Does a PCI DSS certificate count as validation for 8.2?

No, a certificate does not count as validation. The PCI SSC states that PCI DSS validation is documented on its official templates, which are a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. The PCI SSC FAQ on compliance certificates makes this point directly, so any document presented as a certificate should be checked against the required templates. Your acquirer or the payment brand decides which validation type applies to you. Ask your assessor to confirm which document will satisfy your contract or payment brand requirement.

What should a quote for PCI DSS 8.2 include?

A useful quote for 8.2 lists the systems and identity sources in scope, the specific sub-requirements covered (8.2.1 to 8.2.8), the deliverables, and the evidence each deliverable produces. It should separate one-time work, such as building the inventory and configuring lifecycle automation, from recurring work, such as periodic account reviews, monitoring of third-party access, and updates after system changes. It should name the assumptions about your environment, the client responsibilities, and what happens if the scope changes. Because DeployOpen does not publish prices, any quote it issues will follow from the written scope. Ask for the same breakdown from any provider you compare.

How DeployOpen prepares PCI DSS 8.2 controls and evidence

DeployOpen plans, implements and documents the identity and account lifecycle controls behind Requirement 8.2 inside your own infrastructure. We prepare the systems and evidence an assessor will check, while your organization owns the controls and an independent QSA decides whether they meet the standard.

How we scope

We inventory every identity source, directory and application that creates, changes or removes user IDs in the cardholder data environment.
The written scope names which shared, generic and third-party remote access accounts exist and how each is approved and monitored.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support available as a retainer.

How we build

We configure a central identity provider so joiner, mover and leaver changes flow from the HR-approved source to target applications.
We set automated disablement for accounts inactive beyond 90 days and session idle timeouts at 15 minutes where 8.2.8 applies.
We configure time-limited, monitored access for third-party remote accounts and document any shared credential under the exceptional-use conditions of 8.2.2.

How we hand over

We deliver configuration records, account lifecycle procedures and sample reports that show revocation and inactivity actions taken.
We document the evidence each sub-requirement needs, so your team and the QSA can trace every control to a system output.
We walk your staff through operating the controls, including how to answer the questions an assessor is likely to ask about 8.2.

How we support

Retainers cover ongoing upgrades, periodic account reviews and updates to the lifecycle configuration as your systems change.
We can re-run evidence collection ahead of your assessment so gaps surface while there is time to fix them.
Ask us to confirm in writing which 8.2 tasks remain with your team, which go to a provider and which belong to the assessor.