PCI DSS 4.0
Req 8: Identify and Authenticate Users

PCI DSS 4.0 8.3.1: 8.3.1 Access authenticated with at least one factor

All user access to system components by users and administrators must be authenticated with at least one of these factors: a knowledge factor (for example a password or passphrase); a possession factor (for example a smart card or token device); or an inherence factor (for example a biometric element). Applicability: not intended for point-of-sale terminal user accounts that are limited to a single card number per transaction. This does not replace MFA requirements; it covers in-scope systems that are not otherwise subject to MFA. A digital certificate counts as something you have when unique to one user. Customized approach objective: no account can be reached unless a user identity is presented together with an authentication factor.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 43 controls across 24 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

FedRAMP High · 6 controls

  • AC-17 Remote Access
  • IA-2 Identification and Authentication (Organizational Users)
  • IA-3 Device Identification and Authentication
  • IA-5 Authenticator Management
  • IA-8 Identification and Authentication (Non-Organizational Users)
  • MA-4 Nonlocal Maintenance

FedRAMP Moderate · 6 controls

  • AC-17 Remote Access
  • IA-2 Identification and Authentication (Organizational Users)
  • IA-3 Device Identification and Authentication
  • IA-5 Authenticator Management
  • IA-8 Identification and Authentication (Non-Organizational Users)
  • MA-4 Nonlocal Maintenance

CIS Controls v8 · 4 controls

  • CIS-5.2 Use Unique Passwords
  • CIS-6.3 Require MFA for Externally-Exposed Applications
  • CIS-6.4 Require MFA for Remote Network Access
  • CIS-6.5 Require MFA for Administrative Access

ANSSI Guide d'hygiene informatique (42 mesures, v2.0) · 2 controls

  • ANSSI-HYG-10 Define and Verify Password Selection and Sizing Rules
  • ANSSI-HYG-13 Prefer Strong Authentication Where Possible

Azure Security Benchmark · 2 controls

  • IM-1 Use centralized identity and authentication system
  • IM-6 Use strong authentication controls

CMMC 2.0 · 2 controls

ISO 27701:2019 · 2 controls

  • 6.6.2 User access management
  • 6.6.4 System and application access control

NIST SP 800-53 Rev 5 · 2 controls

  • NIST800-IA-2 IA-2 Identification and Authentication (Organizational Users)
  • SP800-53-IA Identification and Authentication Family

SOC 2 · 2 controls

  • SOC2-CC6.1 CC6.1 Logical access security over protected information assets
  • SOC2-CC6.2 CC6.2 Registering and authorising users before issuing credentials

ASD Strategies to Mitigate Cyber Security Incidents · 1 control

  • ASD37-20 Multi-factor authentication (Essential)

AWS Well-Architected Security Pillar · 1 control

Australia Consumer Data Right - Banking (CDR) · 1 control

  • AUCDR-IS-1 Limit risk of unauthorised access to the CDR data environment

C5 (Germany) · 1 control

CFTC System Safeguards (17 CFR 37, 38, 39, 49) · 1 control

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 1 control

HIPAA Security Rule · 1 control

  • 164.312(d) Person or Entity Authentication (Standard)

ISO 27001:2022 · 1 control

  • 8.5 Secure authentication

ISO 27002:2022 · 1 control

  • 8.5 Secure authentication

NIST Cybersecurity Framework 2.0 · 1 control

NIST SP 800-171 Rev 3 · 1 control

  • 03.05.01 User Identification and Authentication

NIST SP 800-172 · 1 control

  • 3.5.3e Prohibit Connection of Unknown or Unverified System Components

NIST SP 800-66 Rev 2 · 1 control

  • 164.312(d) Person or Entity Authentication (Standard)

PCI 3DS Core Security Standard · 1 control

  • P1-5.3.1 P1-5.3.1 Strong authentication for all access to 3DS systems

UK Cyber Essentials · 1 control

  • CE-AC.2 Authenticate Users Before Granting Access

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Req 8: Identify and Authenticate Users

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 8.3.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

If you hold ISO 27001:202249.6% covered · 141 gapsIf you hold FedRAMP Moderate49.3% covered · 142 gapsIf you hold NIST SP 800-53 Rev 547.5% covered · 147 gapsIf you hold ISO 27002:202243.2% covered · 159 gapsIf you hold CIS Controls v838.2% covered · 173 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.136.4% covered · 178 gaps

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

The graph holds this control, the 43 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll PCI DSS 4.0 controls