PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom

Foundational Identity and Access ManagementSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c8.2 Unique identity and federated user lifecycle

Assign a unique identifier to each user and manage the identity lifecycle (creation, changes, removal) to ensure accountability for actions on system components.

Quick Wins
Foundational
Efficient
Optimized
Effort: Medium Impact: High Applies to CDE: Yes

Requirement 8

Identify Users and Authenticate Access to System Components

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

8.2 User identification and related accounts are managed throughout their lifecycle
  • 8.2.1 Unique ID assigned to each user before access Covered
  • 8.2.2 Group/shared/generic IDs managed by exception only Your responsibility
  • 8.2.3 Service providers use unique auth factors per customer (SP only) Covered
  • 8.2.4 Add/delete/modify of user IDs and auth factors is authorized and managed Covered
  • 8.2.5 Access for terminated users is immediately revoked Covered
  • 8.2.6 Inactive user accounts removed/disabled within 90 days Covered
  • 8.2.7 Third-party remote-access accounts enabled only when needed and monitored Covered
  • 8.2.8 Re-authentication required after 15 minutes idle Covered

How to implement on AWS

Give every person a unique identity and no shared accounts so all activity is attributable. In a single AWS account this is native IAM: one IAM user (or federated principal) per person, prohibit shared credentials, and remove/disable inactive accounts within 90 days (8.2.6) using the IAM credential report plus an AWS Config check and remediation. As you grow, evolve to IAM Identity Center federated with your corporate IdP (SCIM joiners/leavers) — note that enabling IAM Identity Center adopts AWS Organizations. Attribute every action in CloudTrail to the unique identity.

Practical implementation

How this control is implemented in each reference architecture:

Native IAM path for a single account: a unique identity per person, no shared accounts, and automated removal of inactive accounts within 90 days — ready to evolve to federation later.

  1. Create a unique IAM user (or federated principal) per person and prohibit shared accounts, so every action is attributable.
    Account access IAM
  2. Detect inactive accounts/credentials with the IAM credential report, and disable or remove them within 90 days (8.2.6) using the AWS Config managed rule iam-user-unused-credentials-check with automated remediation (or a scheduled Lambda).
    Identity lifecycle IAM AWS Config
  3. Ensure CloudTrail attributes every action to the unique identity for accountability.
    Account logging CloudTrail
  4. Evolution: when you outgrow local IAM users, federate with your corporate IdP via IAM Identity Center (SCIM joiners/leavers). Note this enables AWS Organizations.
    Identity lifecycle (as you scale) IAM Identity Center

How to validate: There are no shared accounts, each person has a unique identity, inactive accounts are disabled/removed within 90 days (credential report + Config remediation), and CloudTrail shows actions tied to unique identities.

Avoid: A shared 'ops' login used by several people, or leaving dormant IAM users active indefinitely. Give each person a unique identity and automate removal of inactive accounts.

Single-account, 3-tier →

One federated identity source governs unique IDs across all accounts, and deprovisioning removes access everywhere at once.

  1. Use IAM Identity Center + IdP via SCIM as the single source of unique identities across all accounts.
    Identity / security account → PCI OU IAM Identity Center AWS Organizations
  2. Deprovision at the IdP so access is removed from every account simultaneously.
    Identity lifecycle IAM Identity Center
  3. Preserve unique attribution in the central CloudTrail (org trail to the log-archive account).
    Log archive account CloudTrail Amazon S3

How to validate: A single IdP governs identities org-wide, a test leaver loses access across all accounts at once, and the org CloudTrail attributes actions uniquely.

Avoid: Separate user directories per account. Deprovisioning gets missed somewhere; centralize identity with one IdP + SCIM.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineinterview

Testing procedures

  • Interview personnel and examine audit logs to verify each user has a unique ID and that access can be uniquely attributed to individuals (8.2.1.a, 8.2.1.b).
  • Examine account lists and policies to verify shared authentication credentials are only used on an exception basis and managed accordingly (8.2.2.a, 8.2.2.b).
  • Examine information sources for terminated users and access lists to verify terminated user IDs are deactivated or removed (8.2.5.a).
  • Examine the inactive-account process to verify accounts inactive for more than 90 days are removed or disabled (8.2.6).

Evidence in AWS

  • Unique IAM identities (or IdP federation) and absence of shared accounts.
  • IAM credential report and AWS Config iam-user-unused-credentials-check results showing inactive accounts removed/disabled within 90 days (8.2.6).
  • Provisioning/deprovisioning process (SCIM, once federated) and evidence of timely revocation.
  • CloudTrail events attributable to unique identities.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 8.2 — All actions by all users are attributable to an individual.

AWS services

AWS IAM AWS Config AWS IAM Identity Center AWS CloudTrail

Learning resources

References

  • PCI DSS v4.0.1 Requirement 8.2