PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 8 / c8.4
Efficient 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.4 Advanced protection of privileged identities and anomaly detection

Strengthen protection of privileged accounts and detect anomalous authentication behavior to sustain strong authentication at scale.

Quick Wins
Foundational
Efficient
Optimized
Effort: High Impact: Medium 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.3 Strong authentication for users and administrators is established and managed
  • 8.3.1 All access authenticated via at least one strong auth factor Covered
  • 8.3.2 Strong cryptography protects auth factors in transit and storage Covered
  • 8.3.3 User identity verified before modifying an auth factor Your responsibility
  • 8.3.4 Invalid auth attempts limited (lockout) — Cognito/IdP; IAM users need MFA Roadmap
  • 8.3.5 Passwords/passphrases set and reset securely Covered
  • 8.3.6 Minimum password length and complexity Covered
  • 8.3.7 No reuse of the last four passwords/passphrases Covered
  • 8.3.8 Authentication policies documented and communicated to users Your responsibility
  • 8.3.9 If single-factor password: change every 90 days or dynamic analysis Covered
  • 8.3.10 SP customer password guidance (service providers only) Your responsibility
  • 8.3.11 Physical/logical tokens, smart cards, certificates assigned individually Out of scope
8.5 MFA systems are configured to prevent misuse
  • 8.5.1 MFA systems resist replay, cannot be bypassed, use strong factors Covered

How to implement on AWS

Apply just-in-time access to elevated permissions. Detect compromised credentials and anomalous access with GuardDuty (IAM findings). Alert on root usage and changes to MFA configurations. Prefer phishing-resistant factors (FIDO2/passkeys).

Practical implementation

How this control is implemented in each reference architecture:

Reach the optimized state: elevate privilege just-in-time, use phishing-resistant factors, and detect anomalous credential use.

  1. Replace standing admin with just-in-time elevation using native IAM: privileged roles assumed via STS for short-lived sessions, gated by conditions (MFA, approval). Evolution: IAM Identity Center permission sets with session duration give this a managed UX once you adopt it.
    Account access IAM Sts
  2. Prefer phishing-resistant factors (FIDO2 / passkeys) for privileged users' MFA.
    Account access IAM
  3. Detect anomalous credential use and alert on root usage / MFA-config changes with GuardDuty and EventBridge.
    Account-wide detection GuardDuty EventBridge

How to validate: Privileged access is time-boxed via assumed roles (no standing admin), privileged users use FIDO2, and a simulated credential-anomaly GuardDuty finding raises an alert.

Avoid: Standing administrator access 24/7. It is a large attack surface; grant elevation just-in-time (assume-role with MFA/approval) and expire it.

Single-account, 3-tier →

Operate privileged-access management and anomaly detection org-wide, watching credential findings and root usage across every account.

  1. Run just-in-time privileged access centrally through Identity Center with phishing-resistant MFA enforced org-wide.
    Identity / security account → PCI OU IAM Identity Center AWS Organizations
  2. Watch for GuardDuty credential-access findings and root usage across every CDE account from the delegated admin.
    Security tooling account GuardDuty
  3. Alert and drive response centrally (EventBridge) so a credential anomaly in any account is handled consistently.
    Security tooling account EventBridge Security Hub

How to validate: Identity Center enforces JIT + phishing-resistant MFA org-wide, and a simulated credential-anomaly finding in any CDE account surfaces centrally and triggers response.

Avoid: Watching root usage account-by-account. Aggregate GuardDuty to the delegated admin so root/credential anomalies are caught everywhere.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine vendor system documentation to verify the MFA system is not susceptible to replay attacks (8.5.1.a).
  • Interview personnel and observe processes to verify any MFA bypass requests are documented and authorized by management on an exception basis for a limited time (8.5.1.c).

Evidence in AWS

  • GuardDuty findings of type credential access/anomalous behavior and their handling.
  • Just-in-time access configuration for elevated permissions.
  • Documented use of phishing-resistant factors (FIDO2).

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 8.3 — An account cannot be accessed except with a combination of user identity and an authentication factor.
  • 8.5 — MFA systems are resistant to attack and strictly control any administrative overrides.

AWS services

Amazon GuardDuty AWS IAM Identity Center Amazon EventBridge

Learning resources

References

  • AWS Security Maturity Model: Protect privileged accounts