| Control | Status | |
|---|---|---|
| Identity & Access Management (IAM) | Mechanisms exist to facilitate the implementation of identification and access management controls. | |
| Retain Access Records | Mechanisms exist to retain a record of personnel accountability to ensure there is a record of all access granted to an individual (system and application-wise), who provided the authorization, when the authorization was granted and when the access was last reviewed. | |
| Authenticate, Authorize and Audit (AAA) | Mechanisms exist to strictly govern the use of Authenticate, Authorize and Audit (AAA) solutions, both on-premises and those hosted by an External Service Provider (ESP). | |
| Identification & Authentication for Organizational Users | Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) organizational users and processes acting on behalf of organizational users. | |
| Group Authentication | Mechanisms exist to require individuals to be authenticated with an individual authenticator when a group authenticator is utilized. | |
| Replay-Resistant Authentication | Automated mechanisms exist to employ replay-resistant authentication. | |
| Acceptance of PIV Credentials | Mechanisms exist to accept and electronically verify organizational Personal Identity Verification (PIV) credentials. | |
| Identification & Authentication for Non-Organizational Users | Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) third-party users and processes that provide services to the organization. | |
| Acceptance of PIV Credentials from Other Organizations | Mechanisms exist to accept and electronically verify Personal Identity Verification (PIV) credentials from third-parties. | |
| Acceptance of Third-Party Credentials | Automated mechanisms exist to accept Federal Identity, Credential and Access Management (FICAM)-approved third-party credentials. | |
| Acceptance of External Authenticators | Mechanisms exist to restrict the use of external authenticators to those that are National Institute of Standards and Technology (NIST)-compliant and maintain a list of accepted external authenticators. | |
| Identification & Authentication for Devices | Mechanisms exist to uniquely identify and centrally Authenticate, Authorize and Audit (AAA) devices before establishing a connection using bidirectional authentication that is cryptographically- based and replay resistant. | |
| Identification & Authentication for Third Party Systems & Services | Mechanisms exist to identify and authenticate third-party systems and services. | |
| Multi-Factor Authentication (MFA) | Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for: (1) Remote network access; (2) Third-party systems, applications and/or services; and/ or (3) Non-console access to critical systems or systems that store, transmit and/or process sensitive/regulated data. | |
| Network Access to Privileged Accounts | Mechanisms exist to utilize Multi-Factor Authentication (MFA) to authenticate network access for privileged accounts. | |
| Network Access to Non-Privileged Accounts | Mechanisms exist to utilize Multi-Factor Authentication (MFA) to authenticate network access for non-privileged accounts. | |
| Local Access to Privileged Accounts | Mechanisms exist to utilize Multi-Factor Authentication (MFA) to authenticate local access for privileged accounts. | |
| User Provisioning & De-Provisioning | Mechanisms exist to utilize a formal user registration and de-registration process that governs the assignment of access rights. | |
| Change of Roles & Duties | Mechanisms exist to revoke user access rights following changes in personnel roles and duties, if no longer necessary or permitted. | |
| Termination of Employment | Mechanisms exist to revoke user access rights in a timely manner, upon termination of employment or contract. | |
| Role-Based Access Control (RBAC) | Mechanisms exist to enforce a Role-Based Access Control (RBAC) policy over users and resources that applies need-to-know and fine-grained access control for sensitive/regulated data access. | |
| Identifier Management (User Names) | Mechanisms exist to govern naming standards for usernames and systems. | |
| User Identity (ID) Management | Mechanisms exist to ensure proper user identification management for non-consumer users and administrators. | |
| Identity User Status | Mechanisms exist to identify contractors and other third-party users through unique username characteristics. | |
| Dynamic Management | Mechanisms exist to dynamically manage usernames and system identifiers. | |
| Cross-Organization Management | Mechanisms exist to coordinate username identifiers with external organizations for cross-organization management of identifiers. | |
| Privileged Account Identifiers | Mechanisms exist to uniquely manage privileged accounts to identify the account as a privileged user or service. | |
| Pairwise Pseudonymous Identifiers (PPID) | Mechanisms exist to generate pairwise pseudonymous identifiers with no identifying information about a data subject to discourage activity tracking and profiling of the data subject. | |
| Authenticator Management | Mechanisms exist to: (1) Securely manage authenticators for users and devices; and (2) Ensure the strength of authentication is appropriate to the classification of the data being accessed. | |
| Password-Based Authentication | Mechanisms exist to enforce complexity, length and lifespan considerations to ensure strong criteria for password-based authentication. | |
| PKI-Based Authentication | Automated mechanisms exist to validate certificates by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information for PKI-based authentication. | |
| Automated Support For Password Strength | Automated mechanisms exist to determine if password authenticators are sufficiently strong enough to satisfy organization-defined password length and complexity requirements. | |
| Protection of Authenticators | Mechanisms exist to protect authenticators commensurate with the sensitivity of the information to which use of the authenticator permits access. | |
| No Embedded Unencrypted Static Authenticators | Mechanisms exist to ensure that unencrypted, static authenticators are not embedded in applications, scripts or stored on function keys. | |
| Default Authenticators | Mechanisms exist to ensure default authenticators are changed as part of account creation or system installation. | |
| Password Managers | Mechanisms exist to protect and store passwords via a password manager tool. | |
| Adaptive Identification & Authentication | Mechanisms exist to allow individuals to utilize alternative methods of authentication under specific circumstances or situations. | |
| Re-Authentication | Mechanisms exist to force users and devices to re-authenticate according to organization-defined circumstances that necessitate re-authentication. | |
| Account Management | Mechanisms exist to proactively govern account management of individual, group, system, service, application, guest and temporary accounts. | |
| Automated System Account Management (Directory Services) | Automated mechanisms exist to support the management of system accounts (e.g., directory services). | |
| Removal of Temporary / Emergency Accounts | Automated mechanisms exist to disable or remove temporary and emergency accounts after an organization-defined time period for each type of account. | |
| Disable Inactive Accounts | Automated mechanisms exist to disable inactive accounts after an organization-defined time period. | |
| Restrictions on Shared Groups / Accounts | Mechanisms exist to authorize the use of shared/group accounts only under certain organization-defined conditions. | |
| Account Disabling for High Risk Individuals | Mechanisms exist to disable accounts immediately upon notification for users posing a significant risk to the organization. | |
| System Account Reviews | Mechanisms exist to review all system accounts and disable any account that cannot be associated with a business process and owner. | |
| Emergency Accounts | Mechanisms exist to establish and control "emergency access only" accounts. | |
| Privileged Account Management (PAM) | Mechanisms exist to restrict and control privileged access rights for users and services. | |
| Privileged Account Inventories | Mechanisms exist to inventory all privileged accounts and validate that each person with elevated privileges is authorized by the appropriate level of organizational management. | |
| Periodic Review of Account Privileges | Mechanisms exist to periodically-review the privileges assigned to individuals and service accounts to validate the need for such privileges and reassign or remove unnecessary privileges, as necessary. | |
| User Responsibilities for Account Management | Mechanisms exist to compel users to follow accepted practices in the use of authentication mechanisms (e.g., passwords, passphrases, physical or logical security tokens, smart cards, certificates, etc.). | |
| Credential Sharing | Mechanisms exist to prevent the sharing of generic IDs, passwords or other generic authentication methods. | |
| Access Enforcement | Mechanisms exist to enforce Logical Access Control (LAC) permissions that conform to the principle of "least privilege." | |
| Access To Sensitive / Regulated Data | Mechanisms exist to limit access to sensitive/regulated data to only those individuals whose job requires such access. | |
| Database Access | Mechanisms exist to restrict access to databases containing sensitive/regulated data to only necessary services or those individuals whose job requires such access. | |
| Use of Privileged Utility Programs | Mechanisms exist to restrict and tightly control utility programs that are capable of overriding system and application controls. | |
| Dedicated Administrative Machines | Mechanisms exist to restrict executing administrative tasks or tasks requiring elevated access to a dedicated machine. | |
| Least Privilege | Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions. | |
| Authorize Access to Security Functions | Mechanisms exist to limit access to security functions to explicitly-authorized privileged users. | |
| Non-Privileged Access for Non-Security Functions | Mechanisms exist to prohibit privileged users from using privileged accounts, while performing non-security functions. | |
| Privileged Accounts | Mechanisms exist to restrict the assignment of privileged accounts to management-approved personnel and/or roles. | |
| Auditing Use of Privileged Functions | Mechanisms exist to audit the execution of privileged functions. | |
| Prohibit Non-Privileged Users from Executing Privileged Functions | Mechanisms exist to prevent non-privileged users from executing privileged functions to include disabling, circumventing or altering implemented security safeguards / countermeasures. | |
| Account Lockout | Mechanisms exist to enforce a limit for consecutive invalid login attempts by a user during an organization-defined time period and automatically locks the account when the maximum number of unsuccessful attempts is exceeded. | |
| Session Lock | Mechanisms exist to initiate a session lock after an organization-defined time period of inactivity, or upon receiving a request from a user and retain the session lock until the user reestablishes access using established identification and authentication methods. | |
| Pattern-Hiding Displays | Mechanisms exist to implement pattern-hiding displays to conceal information previously visible on the display during the session lock. | |
| Session Termination | Automated mechanisms exist to log out users, both locally on the network and for remote sessions, at the end of the session or after an organization-defined period of inactivity. | |
| Permitted Actions Without Identification or Authorization | Mechanisms exist to identify and document the supporting rationale for specific user actions that can be performed on a system without identification or authentication. | |
| Identity Proofing (Identity Verification) | Mechanisms exist to verify the identity of a user before issuing authenticators or modifying access permissions. | |
| Management Approval For New or Changed Accounts | Mechanisms exist to ensure management approvals are required for new accounts or changes in permissions to existing accounts. |