Skip to main content

🛡️ AWS IAM User MFA is not enabled for all users with console password🟢

  • Contextual name: 🛡️ User MFA is not enabled for all users with console password🟢
  • ID: /ce/ca/aws/iam/mfa-for-all-users-with-console-password
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Logic​

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-b92b08f41

Description​

Open File

Description​

Multi-Factor Authentication (MFA) adds an extra layer of authentication assurance beyond traditional credentials. With MFA enabled, when a user signs in to the AWS Console, they will be prompted for their user name and password as well as for an authentication code from their physical or virtual MFA token. It is recommended that MFA be enabled for all accounts that have a console password.

Rationale​

Enabling MFA provides increased security for console access as it requires the authenticating principal to possess a device that displays a time-sensitive key and have knowledge of a credential.

Impact​

AWS will soon end support for SMS multi-factor authentication (MFA). New customers are not allowed to use this feature. We recommend that existing customers switch to one of the following alternative methods of MFA.

Audit​

Perform the following to determine if a MFA device is enabled for all IAM users having a console password:

From Console​
  1. Open the IAM console at https://console.aws.amazon.com/iam/.

... see more

Remediation​

Open File

Remediation​

Perform the following to enable MFA:

From Console​

  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
  2. In the left pane, select Users.
  3. In the User Name list, choose the name of the intended MFA user.
  4. Choose the Security Credentials tab, and then choose Manage MFA Device.
  5. In the Manage MFA Device wizard, choose Virtual MFA device, and then choose Continue.

IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic is a representation of the secret configuration key that is available for manual entry on devices that do not support QR codes.

  1. Open your virtual MFA application. (For a list of apps that you can use for hosting virtual MFA devices, see Virtual MFA Applications). If the virtual MFA application supports multiple accounts (multiple virtual MFA devices), choose the option to create a new account (a new virtual MFA device).

... see more

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 4 Regulated entities would typically put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes.88no data
💼 APRA CPG 234 → 💼 5 The strength of identification and authentication would typically be commensurate with the impact should an identity be falsified. Common techniques for increasing the strength of identification and authentication include the use of strong password techniques (i.e. length, complexity, re-use limitations and frequency of change), utilisation of cryptographic techniques and increasing the number and type of authentication factors used. Authentication factors include something an individual: a. knows - for example, user IDs and passwords; b. has - for example, a security token or other devices in the person’s possession used for the generation of one-time passwords; c. is - for example, retinal scans, hand scans, signature scans, digital signature, voice scans or other biometrics.33no data
💼 APRA CPG 234 → 💼 6 The following are examples where increased authentication strength is typically required, given the impact should an identity be falsified: a. administration or other privileged access to sensitive or critical information assets; b. remote access (i.e. via public networks) to sensitive or critical information assets; c. high-risk activities (e.g. third-party fund transfers, creation of new payees)22no data
💼 APRA CPG 234 → 💼 44a malicious acts by an insider with highly-privileged access, potentially involving collusion with internal or external parties;11no data
💼 APRA CPG 234 → 💼 45 An understanding of plausible worst case scenarios can help regulated entities identify and implement additional controls to prevent or reduce the impact of such scenarios. One example is malware that infects computers and encrypts data, both on the infected computer and any connected storage, including (corporate) networks and cloud storage. Such attacks reinforce the importance of protecting the backup environment in the event that the production environment is compromised. Common techniques to achieve this include network segmentation, highly restricted and segregated access controls and network traffic flow restrictions.3537no data
💼 APRA CPG 234 → 💼 j. multi-factor authentication for privileged access, remote access and other high-risk activities;22no data
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [IAM.5] MFA should be enabled for all IAM users that have a console password1no data
💼 AWS Well-Architected → 💼 SEC02-BP01 Use strong sign-in mechanisms3no data
💼 CIS AWS v1.2.0 → 💼 1.2 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password1no data
💼 CIS AWS v1.3.0 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password1no data
💼 CIS AWS v1.4.0 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password1no data
💼 CIS AWS v1.5.0 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password - Level 1 (Automated)1no data
💼 CIS AWS v2.0.0 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password - Level 1 (Automated)1no data
💼 CIS AWS v3.0.0 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password - Level 1 (Automated)1no data
💼 CIS AWS v4.0.0 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Automated)1no data
💼 CIS AWS v4.0.1 → 💼 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Automated)1no data
💼 CIS AWS v5.0.0 → 💼 1.9 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Automated)1no data
💼 CIS AWS v6.0.0 → 💼 2.9 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Automated)1no data
💼 Cloudaware Framework → 💼 Multi-Factor Authentication (MFA) Implementation16no data
💼 FedRAMP High Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)18no data
💼 FedRAMP High Security Controls → 💼 IA-2(1) Multi-factor Authentication to Privileged Accounts (L)(M)(H)3no data
💼 FedRAMP High Security Controls → 💼 IA-2(2) Multi-factor Authentication to Non-privileged Accounts (L)(M)(H)3no data
💼 FedRAMP High Security Controls → 💼 IA-2(6) Access to Accounts —separate Device (M)(H)3no data
💼 FedRAMP High Security Controls → 💼 IA-2(8) Access to Accounts — Replay Resistant (L)(M)(H)3no data
💼 FedRAMP Low Security Controls → 💼 IA-2(1) Multi-factor Authentication to Privileged Accounts (L)(M)(H)3no data
💼 FedRAMP Low Security Controls → 💼 IA-2(2) Multi-factor Authentication to Non-privileged Accounts (L)(M)(H)3no data
💼 FedRAMP Low Security Controls → 💼 IA-2(8) Access to Accounts — Replay Resistant (L)(M)(H)3no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)18no data
💼 FedRAMP Moderate Security Controls → 💼 IA-2(1) Multi-factor Authentication to Privileged Accounts (L)(M)(H)3no data
💼 FedRAMP Moderate Security Controls → 💼 IA-2(2) Multi-factor Authentication to Non-privileged Accounts (L)(M)(H)3no data
💼 FedRAMP Moderate Security Controls → 💼 IA-2(6) Access to Accounts —separate Device (M)(H)3no data
💼 FedRAMP Moderate Security Controls → 💼 IA-2(8) Access to Accounts — Replay Resistant (L)(M)(H)3no data
💼 ISO/IEC 27001:2013 → 💼 A.9.3.1 Use of secret authentication information33no data
💼 ISO/IEC 27001:2022 → 💼 5.15 Access control1431no data
💼 ISO/IEC 27001:2022 → 💼 8.2 Privileged access rights710no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1934no data
💼 NIST CSF v1.1 → 💼 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)1923no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization42no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated53no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties116no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-2(1) Account Management _ Automated System Account Management418no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3(15) Access Enforcement _ Discretionary and Mandatory Access Control13no data
💼 NIST SP 800-53 Revision 5 → 💼 IA-2(1) Identification and Authentication (organizational Users) _ Multi-factor Authentication to Privileged Accounts3no data
💼 NIST SP 800-53 Revision 5 → 💼 IA-2(2) Identification and Authentication (organizational Users) _ Multi-factor Authentication to Non-privileged Accounts3no data
💼 NIST SP 800-53 Revision 5 → 💼 IA-2(6) Identification and Authentication (organizational Users) _ Access to Accounts —separate Device3no data
💼 NIST SP 800-53 Revision 5 → 💼 IA-2(8) Identification and Authentication (organizational Users) _ Access to Accounts — Replay Resistant3no data
💼 PCI DSS v3.2.1 → 💼 8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components.6119no data
💼 PCI DSS v3.2.1 → 💼 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.3no data
💼 PCI DSS v3.2.1 → 💼 8.3.2 Incorporate multi-factor authentication for all remote network access originating from outside the entity's network.1no data
💼 PCI DSS v3.2.1 → 💼 8.6 Where other authentication mechanisms are used, use of these mechanisms must be assigned.1no data
💼 PCI DSS v4.0.1 → 💼 8.3.1 All user access to system components for users and administrators is authenticated.1no data
💼 PCI DSS v4.0.1 → 💼 8.3.10.1 If passwords/passphrases are used as the only authentication factor for customer user access then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed.1no data
💼 PCI DSS v4.0.1 → 💼 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, and physical and/or logical controls ensure only the intended user can use that factor to gain access.1no data
💼 PCI DSS v4.0.1 → 💼 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.3no data
💼 PCI DSS v4.0.1 → 💼 8.4.2 MFA is implemented for all non-console access into the CDE.3no data
💼 PCI DSS v4.0.1 → 💼 8.4.3 MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE.1no data
💼 PCI DSS v4.0 → 💼 8.3.1 All user access to system components for users and administrators is authenticated.11no data
💼 PCI DSS v4.0 → 💼 8.3.10.1 If passwords/passphrases are used as the only authentication factor for customer user access then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed.1no data
💼 PCI DSS v4.0 → 💼 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, and physical and/or logical controls ensure only the intended user can use that factor to gain access.11no data
💼 PCI DSS v4.0 → 💼 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.13no data
💼 PCI DSS v4.0 → 💼 8.4.2 MFA is implemented for all access into the CDE.13no data
💼 PCI DSS v4.0 → 💼 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.11no data