Edit

Microsoft Entra ID and PCI-DSS Requirement 8

  • Article

Requirement 8: Identify Users and Authenticate Access to System Components
Defined approach requirements

8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

PCI-DSS Defined approach requirements Microsoft Entra guidance and recommendations
8.1.1 All security policies and operational procedures that are identified in Requirement 8 are:
Documented
Kept up to date
In use
Known to all affected parties		 Use the guidance and links herein to produce the documentation to fulfill requirements based on your environment configuration.
8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. Use the guidance and links herein to produce the documentation to fulfill requirements based on your environment configuration.
PCI-DSS Defined approach requirements Microsoft Entra guidance and recommendations
8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed. For CDE applications that rely on Microsoft Entra ID, the unique user ID is the user principal name (UPN) attribute. Microsoft Entra UserPrincipalName population
8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
Account use is prevented unless needed for an exceptional circumstance.
Use is limited to the time needed for the exceptional circumstance.
Business justification for use is documented.
Use is explicitly approved by management
Individual user identity is confirmed before access to an account is granted.
Every action taken is attributable to an individual user.		 Ensure CDEs using Microsoft Entra ID for application access have processes to prevent shared accounts. Create them as an exception that requires approval.
For CDE resources deployed in Azure, use managed identities for Azure resources to represent the workload identity, instead of creating a shared service account. What are managed identities for Azure resources?
If you can’t use managed identities and the resources accessed are using the OAuth protocol, use service principals to represent workload identities. Grant identities least privileged access through OAuth scopes. Administrators can restrict access and define approval workflows to create them. What are workload identities?
8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises. Microsoft Entra ID has on-premises connectors to enable hybrid capabilities. Connectors are identifiable and use uniquely generated credentials. Microsoft Entra Connect Sync: Understand and customize synchronization
Cloud sync deep dive
Microsoft Entra on-premises application provisioning architecture
Plan cloud HR application to Microsoft Entra user provisioning
Install the Microsoft Entra Connect Health agents
8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
Authorized with the appropriate approval.
Implemented with only the privileges specified on the documented approval.		 Microsoft Entra ID has automated user account provisioning from HR systems. Use this feature to create a lifecycle. What is HR driven provisioning?
Microsoft Entra ID has lifecycle workflows to enable customized logic for joiner, mover, and leaver processes. What are Lifecycle Workflows?
Microsoft Entra ID has a programmatic interface to manage authentication methods with Microsoft Graph. Some authentication methods such as Windows Hello for Business and FIDO2 keys, require user intervention to register. Get started with the Graph authentication methods API
Administrators and/or automation generates the Temporary Access Pass credential using Graph API. Use this credential for passwordless onboarding. Configure a Temporary Access Pass in Microsoft Entra ID to register Passwordless authentication methods
8.2.5 Access for terminated users is immediately revoked. To revoke access to an account, disable on-premises accounts for hybrid accounts synchronized from Microsoft Entra ID, disable accounts in Microsoft Entra ID, and revoke tokens. Revoke user access in Microsoft Entra ID
Use Continuous Access Evaluation (CAE) for compatible applications to have a two-way conversation with Microsoft Entra ID. Apps can be notified of events, such as account termination and reject tokens. Continuous access evaluation
8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity. For hybrid accounts, administrators check activity in Active Directory and Microsoft Entra every 90 days. For Microsoft Entra ID, use Microsoft Graph to find the last sign-in date. How to: Manage inactive user accounts in Microsoft Entra ID
8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
Enabled only during the time period needed and disabled when not in use.
Use is monitored for unexpected activity.		 Microsoft Entra ID has external identity management capabilities.
Use governed guest lifecycle with entitlement management. External users are onboarded in the context of apps, resources, and access packages, which you can grant for a limited period and require periodic access reviews. Reviews can result in account removal or disablement. Govern access for external users in entitlement management
Microsoft Entra ID generates risk events at the user and session level. Learn to protect, detect, and respond to unexpected activity. What is risk?
8.2.8 If a user session has been idle for more than 15 minutes, the user is required to reauthenticate to reactivate the terminal or session. Use endpoint management policies with Intune, and Microsoft Endpoint Manager. Then, use Conditional Access to allow access from compliant devices. Use compliance policies to set rules for devices you manage with Intune
If your CDE environment relies on group policy objects (GPO), configure GPO to set an idle timeout. Configure Microsoft Entra ID to allow access from Microsoft Entra hybrid joined devices. Microsoft Entra hybrid joined devices

8.3 Strong authentication for users and administrators is established and managed.

For more information about Microsoft Entra authentication methods that meet PCI requirements, see: Information Supplement: Multi-Factor Authentication.

PCI-DSS Defined approach requirements Microsoft Entra guidance and recommendations
8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
Something you know, such as a password or passphrase.
Something you have, such as a token device or smart card.
Something you are, such as a biometric element.		 Microsoft Entra ID requires passwordless methods to meet the PCI requirements
See holistic passwordless deployment. Plan a passwordless authentication deployment in Microsoft Entra ID
8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components. Cryptography used by Microsoft Entra ID is compliant with PCI definition of Strong Cryptography. Microsoft Entra Data protection considerations
8.3.3 User identity is verified before modifying any authentication factor. Microsoft Entra ID requires users to authenticate to update their authentication methods using self-service, such as mysecurityinfo portal and the self-service password reset (SSPR) portal. Set up security info from a sign-in page
Common Conditional Access policy: Securing security info registration
Microsoft Entra self-service password reset
Administrators with privileged roles can modify authentication factors: Global, Password, User, Authentication, and Privileged Authentication. Least privileged roles by task in Microsoft Entra ID. Microsoft recommends you enable JIT access and governance, for privileged access using Microsoft Entra Privileged Identity Management
8.3.4 Invalid authentication attempts are limited by:
Locking out the user ID after not more than 10 attempts.
Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.		 Deploy Windows Hello for Business for Windows devices that support hardware Trusted Platform Modules (TPM) 2.0 or higher.
For Windows Hello for Business, lockout relates to the device. The gesture, PIN, or biometric, unlocks access to the local TPM. Administrators configure the lockout behavior with GPO or Intune policies. TPM Group Policy settings
Manage Windows Hello for Business on devices at the time devices enroll with Intune
TPM fundamentals
Windows Hello for Business works for on-premises authentication to Active Directory and cloud resources on Microsoft Entra ID.
For FIDO2 security keys, brute-force protection is related to the key. The gesture, PIN or biometric, unlocks access to the local key storage. Administrators configure Microsoft Entra ID to allow registration of FIDO2 security keys from manufacturers that align to PCI requirements. Enable passwordless security key sign-in

Microsoft Authenticator App
To mitigate brute force attacks using Microsoft Authenticator app passwordless sign in, enable number matching and more context.
Microsoft Entra ID generates a random number in the authentication flow. The user types it in the authenticator app. The mobile app authentication prompt shows the location, the request IP address, and the request application. How to use number matching in MFA notifications
How to use additional context in Microsoft Authenticator notifications
8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they're set and reset for each user as follows:
Set to a unique value for first-time use and upon reset.
Forced to be changed immediately after the first use.		 Not applicable to Microsoft Entra ID.
8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
A minimum length of 12 characters (or IF the system doesn't support 12 characters, a minimum length of eight characters).
Contain both numeric and alphabetic characters.		 Not applicable to Microsoft Entra ID.
8.3.7 Individuals aren't allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. Not applicable to Microsoft Entra ID.
8.3.8 Authentication policies and procedures are documented and communicated to all users including:
Guidance on selecting strong authentication factors.
Guidance for how users should protect their authentication factors.
Instructions not to reuse previously used passwords/passphrases.
Instructions to change passwords/passphrases if there's any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.		 Document policies and procedures, then communicate to users per this requirement. Microsoft provides customizable templates in the Download Center.
8.3.9 If passwords/passphrases are used as the only authentication factor for user access (that is, in any single-factor authentication implementation) then either: Passwords/passphrases are changed at least once every 90 days,
OR
The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.		 Not applicable to Microsoft Entra ID.
8.3.10 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (that is, in any single-factor authentication implementation), then guidance is provided to customer users including:
Guidance for customers to change their user passwords/passphrases periodically.
Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.		 Not applicable to Microsoft Entra ID.
8.3.10.1 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (that is, in any single-factor authentication implementation) then either:
Passwords/passphrases are changed at least once every 90 days,
OR
The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.		 Not applicable to Microsoft Entra ID.
8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
Factors are assigned to an individual user and not shared among multiple users.
Physical and/or logical controls ensure only the intended user can use that factor to gain access.		 Use passwordless authentication methods such as Windows Hello for Business, FIDO2 security keys, and Microsoft Authenticator app for phone sign in. Use smart cards based on public or private keypairs associated with users to prevent reuse.

8.4 Multi-factor authentication (MFA) is implemented to secure access into the cardholder data environment (CDE)

PCI-DSS Defined approach requirements Microsoft Entra guidance and recommendations
8.4.1 MFA is implemented for all nonconsole access into the CDE for personnel with administrative access. Use Conditional Access to require strong authentication to access CDE resources. Define policies to target an administrative role (Global Administrator), or a security group representing administrative access to an application.
For administrative access, use Microsoft Entra Privileged Identity Management (PIM) to enable just-in-time (JIT) activation of privileged roles. What is Conditional Access?
Conditional Access templates
Start using PIM
8.4.2 MFA is implemented for all access into the CDE. Block access to legacy protocols that don’t support strong authentication. Block legacy authentication with Microsoft Entra ID with Conditional Access
8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
All remote access by third parties and vendors.		 Integrate access technologies like virtual private network (VPN), remote desktop, and network access points with Microsoft Entra ID for authentication and authorization. Use Conditional Access to require strong authentication to access remote access applications. Conditional Access templates

8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.

PCI-DSS Defined approach requirements Microsoft Entra guidance and recommendations
8.5.1 MFA systems are implemented as follows:
The MFA system isn't susceptible to replay attacks.
MFA systems can't be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
At least two different types of authentication factors are used.
Success of all authentication factors is required before access is granted.		 The recommended Microsoft Entra authentication methods use nonce or challenges. These methods resist replay attacks because Microsoft Entra ID detects replayed authentication transactions.
Windows Hello for Business, FIDO2, and Microsoft Authenticator app for passwordless phone sign in use a nonce to identify the request and detect replay attempts. Use passwordless credentials for users in the CDE.
Certificate-based authentication uses challenges to detect replay attempts.
NIST authenticator assurance level 2 with Microsoft Entra ID
NIST authenticator assurance level 3 by using Microsoft Entra ID

8.6 Use of application and system accounts and associated authentication factors is strictly managed.

PCI-DSS Defined approach requirements Microsoft Entra guidance and recommendations
8.6.1 If accounts used by systems or applications can be used for interactive login, they're managed as follows:
Interactive use is prevented unless needed for an exceptional circumstance.
Interactive use is limited to the time needed for the exceptional circumstance.
Business justification for interactive use is documented.
Interactive use is explicitly approved by management.
Individual user identity is confirmed before access to account is granted.
Every action taken is attributable to an individual user.		 For CDE applications with modern authentication, and for CDE resources deployed in Azure that use modern authentication, Microsoft Entra ID has two service account types for applications: Managed Identities and service principals.
Learn about Microsoft Entra service account governance: planning, provisioning, lifecycle, monitoring, access reviews, etc. Governing Microsoft Entra service accounts
To secure Microsoft Entra service accounts. Securing managed identities in Microsoft Entra ID
Securing service principals in Microsoft Entra ID
For CDEs with resources outside Azure that require access, configure workload identity federations without managing secrets or interactive sign in. Workload identity federation
To enable approval and tracking processes to fulfill requirements, orchestrate workflows using IT Service Management (ITSM) and configuration management databases (CMDB) These tools use MS Graph API to interact with Microsoft Entra ID and manage the service account.
For CDEs that require service accounts compatible with on-premises Active Directory, use Group Managed Service Accounts (GMSAs), and standalone managed service accounts (sMSA), computer accounts, or user accounts. Securing on-premises service accounts
8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login aren't hard coded in scripts, configuration/property files, or bespoke and custom source code. Use modern service accounts such as Azure Managed Identities and service principals that don’t require passwords.
Microsoft Entra managed identities credentials are provisioned, and rotated in the cloud, which prevents using shared secrets such as passwords and passphrases. When using system-assigned managed identities, the lifecycle is tied to the underlying Azure resource lifecycle.
Use service principals to use certificates as credentials, which prevents use of shared secrets such as passwords and passphrases. If certificates are not feasible, use Azure Key Vault to store service principal client secrets. Best practices for using Azure Key Vault
For CDEs with resources outside Azure that require access, configure workload identity federations without managing secrets or interactive sign-in. Workload identity federation
Deploy Conditional Access for workload identities to control authorization based on location and/or risk level. Conditional Access for workload identities
In addition to the previous guidance, use code analysis tools to detect hard-coded secrets in code and configuration files. Detect exposed secrets in code
Security rules
8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:
Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.		 Use modern service accounts such as Azure Managed Identities and service principals that don’t require passwords.
For exceptions that require service principals with secrets, abstract secret lifecycle with workflows and automations that sets random passwords to service principals, rotates them regularly, and reacts to risk events.
Security operations teams can review and remediate reports generated by Microsoft Entra such as Risky workload identities. Securing workload identities with Identity Protection

Next steps

PCI-DSS requirements 3, 4, 9, and 12 aren't applicable to Microsoft Entra ID, therefore there are no corresponding articles. To see all requirements, go to pcisecuritystandards.org: Official PCI Security Standards Council Site.

To configure Microsoft Entra ID to comply with PCI-DSS, see the following articles.