Identification and Authentication 3.5.2 (3.5.2)
Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to verify the identity of anyone or anything (users, automated processes, or devices) before granting access to systems containing CUI. Authentication must occur before access is allowed, using methods like passwords, smart cards, biometric readers, or cryptographic tokens. Organizations must manage these authentication credentials throughout their lifecycle, including creation, distribution, and revocation. Factory default credentials (like 'admin/admin') must be changed before systems are put into production. The control emphasizes that authentication is a prerequisite—access cannot be granted until identity is verified.
Control Intent
Prevent unauthorized access to organizational systems by ensuring that only verified and authenticated entities (users, processes, or devices) can gain access to CUI and the systems that store, process, or transmit it.
Who This Control Applies To
- •All systems that store, process, or transmit CUI
- •All user accounts with access to in-scope systems
- •All service accounts and automated processes that access in-scope systems
- •All devices (workstations, servers, mobile devices, network equipment) within the assessment boundary
- •Remote access solutions and VPN endpoints
- •Cloud services and SaaS applications containing CUI
- •Network infrastructure devices (routers, switches, firewalls)
- •Privileged access management systems
- •Identity and access management (IAM) platforms
Not Applicable When
- •Systems that do not store, process, or transmit CUI and are completely isolated from in-scope systems
- •Publicly accessible information systems that contain no CUI and have no connection to CUI systems
- •Physical security systems that operate independently and have no logical access to CUI systems
- •Standalone equipment with no network connectivity and no CUI access (rare in modern environments)
Key Objectives
- 1Verify the identity of all users, processes, and devices before granting access to organizational systems.
- 2Implement authentication mechanisms that provide reasonable assurance of identity verification.
- 3Manage authenticators throughout their lifecycle, including issuance, maintenance, and revocation.
- 4Eliminate or change factory default authentication credentials before systems are placed into production.
Sample Self-Assessment Questions (Partial)
Do all users have unique usernames and passwords to access systems containing CUI?
Are factory default passwords (like 'admin' or 'password') still in use on any systems, devices, or applications?
Implementation Approaches (High-Level)
Active Directory with Enforced Password Policies
Centralized authentication using Microsoft Active Directory (AD) or Azure AD with enforced password policies, account lockout settings, and unique user accounts for all personnel.
Multi-Factor Authentication (MFA) for Remote and Privileged Access
Implementation of multi-factor authentication requiring two or more authentication factors (something you know, something you have, something you are) for remote access, privileged accounts, and high-risk systems.
Certificate-Based Authentication for Devices and Services
Use of digital certificates (PKI) to authenticate devices, service accounts, and automated processes before granting access to systems and networks.
Single Sign-On (SSO) with Centralized Identity Provider
Centralized authentication using a Single Sign-On (SSO) solution (Okta, Azure AD, Google Workspace) that federates authentication across multiple applications and services.
Local Account Management with Documented Procedures
For systems that cannot integrate with centralized authentication, local accounts are managed with documented procedures for creation, password management, and revocation.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If factory default credentials cannot be changed immediately, document the systems affected, the reason for delay, and implement compensating controls such as network segmentation or restricted access. If centralized authentication cannot be implemented across all systems, prioritize high-risk systems (those with CUI access) and document a phased implementation plan. If MFA cannot be implemented immediately, prioritize remote access and privileged accounts, and document a timeline for full deployment. If legacy systems cannot support modern authentication, document the systems, the technical limitations, and implement compensating controls such as network isolation, restricted access, or enhanced monitoring. If service account authentication cannot be strengthened immediately, document the accounts, their purpose, and implement compensating controls such as restricted permissions and audit logging. POA&Ms should include specific milestones, responsible parties, and target completion dates for each remediation activity. Compensating controls must be documented and assessed to ensure they provide equivalent protection.
Frequently Asked Questions
Does this control require multi-factor authentication (MFA)?
No, this control does not explicitly require MFA. It requires authentication of users, processes, and devices before granting access, but does not specify the number of factors. However, MFA is a common and effective implementation, especially for remote access and privileged accounts. CMMC Level 2 does not mandate MFA, but it may be required at higher levels or as a best practice.
What counts as an acceptable authenticator under this control?
Acceptable authenticators include passwords, passphrases, PINs, cryptographic keys, digital certificates, hardware tokens, smart cards, biometric identifiers (fingerprint, facial recognition), and one-time password devices. The key requirement is that the authenticator provides reasonable assurance of identity verification before access is granted.
Do service accounts and automated processes need to be authenticated?
Yes, this control explicitly requires authentication of users, processes, and devices. Service accounts and automated processes must authenticate before accessing systems. This can be achieved through passwords, API keys, certificates, or other cryptographic methods. Unauthenticated or anonymous service accounts are not acceptable for systems containing CUI.
What should we do if a legacy system cannot support modern authentication methods?
If a legacy system cannot support modern authentication, document the technical limitation and implement compensating controls. Compensating controls may include network segmentation to isolate the system, restricted access controls, enhanced monitoring and logging, or physical security measures. A POA&M should document the limitation, the compensating controls, and a plan to upgrade or replace the system if feasible.
How do we prove that factory default credentials have been changed?
Evidence includes system build checklists or provisioning procedures that document the credential change process, configuration backups showing non-default credentials, screenshots of authentication settings, or audit logs showing initial password changes. Assessors may also request live demonstrations of login attempts using known factory defaults to verify they no longer work.
Can we use shared accounts if we track who uses them?
Shared accounts are strongly discouraged because they eliminate individual accountability, which is required by other CMMC controls (e.g., 3.1.1, 3.3.3). If shared accounts are unavoidable due to technical limitations, they must be documented, access must be logged, and compensating controls (such as secondary authentication or session recording) must be implemented. A POA&M should document the plan to eliminate shared accounts.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.