PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 8 / c8.3
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.3 Eliminate long-lived credentials with temporary access

Replace long-lived static credentials with temporary credentials and securely manage the accounts and authentication factors used by applications and systems.

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.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.6 Use of application and system accounts and associated authentication factors is managed
  • 8.6.1 Interactive login by system/app accounts managed and justified Covered
  • 8.6.2 Passwords for app/system accounts not hard-coded in scripts/config Covered
  • 8.6.3 Passwords for app/system accounts protected and changed periodically Covered

How to implement on AWS

Use IAM roles with temporary credentials (STS) for workloads and CI/CD (IAM Roles Anywhere, OIDC federation). Rotate and store application/system secrets in AWS Secrets Manager with automatic rotation. Remove static access keys. Apply compliant password policies where local credentials exist.

Practical implementation

How this control is implemented in each reference architecture:

Replace static keys with temporary credentials and rotate any remaining application/system secrets automatically.

  1. Use IAM roles with temporary STS credentials for workloads and CI/CD (instance roles, IAM Roles Anywhere, OIDC federation) instead of static access keys.
    App tier (CDE) / CI IAM
  2. Store application/system secrets in Secrets Manager with automatic rotation; remove hard-coded credentials from code and config.
    App tier (CDE) Secrets Manager
  3. Remove existing static access keys and confirm via the IAM Credential Report.
    Whole account IAM

How to validate: The Credential Report shows no active static access keys for workloads, and Secrets Manager shows rotation enabled on application secrets.

Avoid: Leaving a static access key 'for the app'. Use a role with temporary credentials; static keys leak and rarely rotate.

Single-account, 3-tier →

Prefer role-based temporary credentials everywhere and forbid static keys by policy across the org.

  1. Standardize on role-based temporary credentials (Roles Anywhere / OIDC federation) for all workloads and pipelines.
    Each CDE workload account / CI IAM
  2. Forbid creating IAM users / static access keys with an SCP on the PCI OU.
    PCI OU (guardrail) AWS Organizations
  3. Manage and rotate secrets per account in Secrets Manager (no shared secret stores across accounts).
    Each CDE workload account Secrets Manager

How to validate: An SCP test blocks creating an access key in a CDE account, and each account's secrets show rotation enabled.

Avoid: Allowing static keys 'just in one account'. One exception spreads; block key creation org-wide and use roles.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine documentation and observe an authentication to verify user access is authenticated via at least one authentication factor (8.3.1.a, 8.3.1.b).
  • Examine vendor documentation and configurations to verify authentication factors are rendered unreadable with strong cryptography in transit and storage (8.3.2.a).
  • Examine scripts, configuration/property files, and source code to verify passwords/passphrases for application/system accounts are not hard-coded (8.6.2.b).

Evidence in AWS

  • Use of roles/STS and absence of static access keys (Credential Report).
  • Automatic secret rotation configured in Secrets Manager.
  • Compliant password policy where local credentials apply.

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.6 — When used interactively, all actions with accounts designated as system or application accounts are authorized and attributable to an individual person.

AWS services

AWS STS AWS Secrets Manager AWS IAM

Learning resources

References

  • AWS Security Maturity Model: Temporary credentials, Secrets management
  • PCI DSS v4.0.1 Requirements 8.3, 8.6