Requirement 2: Apply Secure Configurations to All System Components Defined approach requirements
2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.
PCI-DSS Defined approach requirements
Microsoft Entra guidance and recommendations
2.1.1 All security policies and operational procedures that are identified in Requirement 2 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.
2.1.2 Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.
Use the guidance and links herein to produce the documentation to fulfill requirements based on your environment configuration.
2.2 System components are configured and managed securely.
PCI-DSS Defined approach requirements
Microsoft Entra guidance and recommendations
2.2.1 Configuration standards are developed, implemented, and maintained to: Cover all system components. Address all known security vulnerabilities. Be consistent with industry-accepted system hardening standards or vendor hardening recommendations. Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
2.2.2 Vendor default accounts are managed as follows: If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. If the vendor default account(s) will not be used, the account is removed or disabled.
Not applicable to Microsoft Entra ID.
2.2.3 Primary functions requiring different security levels are managed as follows: Only one primary function exists on a system component, OR Primary functions with differing security levels that exist on the same system component are isolated from each other, OR Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
2.2.5 If any insecure services, protocols, or daemons are present: Business justification is documented. Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
2.3 Wireless environments are configured and managed securely.
PCI-DSS Defined approach requirements
Microsoft Entra guidance and recommendations
2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to: Default wireless encryption keys Passwords on wireless access points SNMP defaults Any other security-related wireless vendor defaults
2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows: Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary. Whenever a key is suspected of or known to be compromised.
Not applicable to Microsoft Entra ID.
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.
Learn to create an initial Azure Active Directory configuration to ensure all the identity solutions available in Azure are ready to use. This module explores how to build and configure an Azure AD system.