Identification and Authentication (IA)

What is Identification and Authentication (IA)?

Identification and Authentication (IA) is a technical measure that prevents unauthorized access to computer systems by verifying the identity of users and processes. This informational guide details how the Centers for Medicare & Medicaid (CMS) applies IA requirements from: 

• NIST Special Publication (SP) 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations
• HHS Policy for Information Security and Privacy Protection (IS2P)
• CMS Information Systems Security and Privacy Policy (IS2P2)
• CMS Acceptable Risk Safeguards (ARS)

How IA works at CMS

CMS ensures that only authorized personnel are granted access to its information systems, critical information, and resources, while maintaining the security and confidentiality of sensitive data and Controlled Unclassified Information (CUI).  This is enforced through: 

• Use of unique user and device identifiers
• Implementation of multi-factor authentication (MFA)
• Enforcement of strict password and cryptographic controls
• Deployment of device certificates and secure remote access (VPN/VDI) 

Key Security Measures 

The key security measures that support Identification and Authentication at CMS are described below.

Identification and Authentication (IA) of Organizational Users  

Organizational users are personnel who are accessing a CMS system (whether that system is hosted by CMS or hosted by a CMS contractor) for the purposes of performing duties associated with their CMS employment or contractual relationship. This includes CMS employees, CMS contractor/subcontractor staff, and CMS-contracted researchers.  

CMS systems are configured to uniquely identify and authenticate organizational users or processes to verify the identity of a user, process or device as a prerequisite to granting access. The Office of Information Technology (OIT) is required to assign all users a unique identification before allowing them to access CMS systems. 

The following details the CMS-specific process for IA of organizational users: 

• Employ effective identity proofing and authentication processes, compliant with HHS and NIST SP 800-63-3, for organizational users when CMS sensitive information (e.g., CUI, Personally Identifiable Information (PII), Protected Health Information (PHI)) is to be accessed, modified, or released.
• Require the use of system and/or network authenticators and unique user identifiers in order to access an application, or any managed system.
• Leverage the CMS Help Desk support that requires user identification for any transaction that has information security and privacy implications, including password resets or account lockout resets.
• Use multi-factor authentication (MFA).
• Comply with the requirements in Homeland Security Presidential Directive 12 (HSPD-12)  

Multi-factor Access to Privileged Accounts and Non-Privileged Accounts 

Privileged accounts refer to a user who is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform. Examples of privileged users at CMS are System/Network Administrator, Website Owner/Administrator, System Developer and Maintainer.  

CMS practices for multi-factor access to privileged accounts include:  

• Utilize Personal Identity Verification (PIV) credentials as directed by HSPD-12 and Federal Information Processing Standards (FIPS) 201-3.
• Implement authentication mechanisms, including two-factor authentication, to authenticate privileged organizational users.
• Comply with HHS and CMS Identification, Credential, and Access Management (ICAM) standards.
• Require a minimum of two-factor authentication (e.g., PIV and personal identification number (PIN)) to gain access to CMS systems.
• Implement specific procedures for using a PIV to connect to the VPN: Getting Started with Remote Access to the CMS Network 

Non-privileged accounts are users or groups that do not have elevated privileges or access to sensitive systems or data. Just like privileged accounts, CMS still requires two-factor authentication, such as a PIV and PIN, to gain access to CMS system while complying with the requirements in HSPD-12. 

Individual Authentication with Group Authentication 

At CMS, each user must be individually authenticated before granting access to shared resources, even if they are part of a group that also uses shared authentication. This helps to mitigate risks associated with shared accounts. 

Access to Accounts - Replay Resistant 

Replay resistance is the capability of an authentication process that prevents attackers from successfully impersonating a legitimate user by replaying captured authentication messages. 

CMS adopts the following practices to protect against replay attacks. 

• Implement replay-resistant authentication mechanisms for all network access to both privileged (administrative) and non-privileged accounts.
• Employ protocols that use a nonce (RSA token numeric) by offering unique, unpredictable values used in authentication processes.
• Utilize challenges such as Transport Layer Security (TLS), which provides authentication and integrity protection, including replay protection. 

Acceptance of PIV Credentials 

CMS mandates the use of PIV credentials, such as PIV cards, for access to its facilities and information systems. This aligns with HSPD-12 and FIPS 201 - 03 regulations, which require a common identity standard for federal employees and contractors. CMS also accepts PIV-I credentials, which are issued by non-federal identity providers that meet the PIV-I requirements defined by the Federal Bridge Certification Authority (FBCA).   

CMS adopts the following practices for acceptance of PIV credentials: 

• Configure systems to require the acceptance of PIV-compliant credentials.
• Conduct background investigations, adjudicate the results per HHS National Security Clearance Processes, and issue identity credentials to employees and contractors who require long-term (greater than 6 months) routine access to federally controlled facilities and/or information systems.
• Instruct users on how to request a PIV card by providing this guidance document from the Enterprise User Administration (EUA): Identity and Credentialing Tool (ICT) New Users Guide.
• Provide CMS contractors and Contracting Officer Representatives (CORs) with visibility into the badging process through the PIV status tracker.
• Comply with The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard and NIST 800-116 R1 Guidelines for the Use of PIV Credentials in Facility Access to ensure the use of PIV credentials for physical access to federal facilities and secured areas.  

For information regarding PIV security certificates, contact Badging@cms.hhs.gov. 

Device Identification and Authentication 

CMS determines the required strength of authentication mechanisms based on the security category of the information systems. This ensures that CMS uniquely identifies and authenticates defined types of devices that require authentication mechanisms to control remote network access before initiating the connection.  

CMS device identification and authentication practices include:  

• Complying with Health Insurance Portability and Accountability Act (HIPAA) technical policy and procedure requirements for systems that maintain PHI to allow access only to those persons or software programs that have been granted access rights.
• Requiring CMS provided/approved software packages and secure user system account credentials in order to gain remote access to the CMS secure Virtual Private Network (VPN) or Virtual Desktop Infrastructure (VDI). Access to these systems also comes with strict security requirements, including up-to-date system patches, malware detection, and FIPS 140-3 validated encryption.
• Requiring appropriate digital certificates/keys for local wireless connections to all CMS-issued devices.
• Identifying and categorizing applications as either allowed (allowlisted) or disallowed (denylisted) for use on approved devices. Additionally, users may access only approved applications from authorized app stores.  
• Requiring users to adhere to acceptable use policies for mobile devices and removable media, including the HHS Rules of Behavior (RoB).
• Requiring all systems and network devices under CMS control to display a notice and consent banner upon user authentication, to acknowledge monitoring and usage restrictions. 

Note: At a minimum, all CMS information systems must be filtered by Media Access Control (MAC) and/or Internet Protocol (IP) address when accessing remote systems. For specific procedures connecting to the CMS network using VPN, visit Getting Started with Remote Access to the CMS Network. 

Identifier Management 

CMS utilizes a comprehensive Identity Management (IDM) system to manage user access to its various systems and data, which also ensures the proper management of system identifiers. Preventing the reuse of identities to different individuals, groups, roles, or devices ensures that the appropriate users and devices are accessing sensitive information.  

CMS-specific process for Identifier Management include: 

• Disabling user accounts after 30 days for High systems, 60 days for Moderate systems, or 90 days for Low systems (or by the days detailed in the System Security and Privacy Plan (SSPP)).
• Assigning unique identifiers to organizational users after authorization by designated approvals.
• Identifying laptops, workstations, and printers with unique tag numbers, and assigning unique identifiers to network devices.
• Reviewing user accounts regularly (at least every 365 days), changing shared account authenticators when individuals leave a group, and aligning these processes with personnel termination procedures.
• Preventing the reuse of identifiers for a minimum of three (3) years.  

Identify User Status 

CMS identifies the status of employees and contractors through characteristics that provide additional context about the people with whom organizational personnel are communicating. This measure helps prevent the inadvertent sharing of sensitive information with unauthorized users.

For example, usernames may include designators such as CMS/CTR to indicate that an individual is a contractor, or other labels to identify foreign nationals. These characteristics help CMS staff understand roles and relationships, supporting secure information sharing. For more information on identity verification, see the ICT New Users Guide. 

Authenticator Management 

CMS employs a robust mechanism to manage its information system authenticators, such as passwords, biometrics, PKI certificates, and key cards. Managing authenticators includes periodically changing passwords or other identifiers, thereby reinforcing identity validation and adherence to administrative policies.  

CMS Authenticator Management practices include: 

• Utilizing the CMS IDM System as a platform for users to manage their accounts, including password management and security questions.
• Following best practices for key management as described in the CMS Key Management Handbook, to ensure systems are well-protected.
• Employing password-based authentication subject to minimum and maximum lifetime restrictions and reuse limitations.
• Enforcing strong password policies, including minimum length, character complexity, and password history restrictions.
• Regularly reviewing users, and revoking access for users who no longer require it.

Password-Based Authentication 

CMS implements strong password policies, guided by NIST standards that serve as a critical first line of defense against cyber threats, protecting against unauthorized access and data breaches. This security requirement does not apply when passwords are used to unlock hardware authenticators (e.g., PIV cards). It applies, however, to single-factor authentication of individuals using passwords as individual or group authenticators. Similarly, it applies when passwords are part of multi-factor authenticators. It is important to note that mobile devices are excluded from password complexity requirements.

CMS-specific process for Password-Based Authentication include: 

• Requiring strong, unique passwords that are at least eight (8) characters for regular user passwords and fifteen (15) for administrator or privileged accounts.
• Requiring that passwords must be cryptographically protected and may not contain personal information or parts of the user's ID.
• Mandating that passwords cannot be the same as the user's last six passwords and can only be changed once every 24 hours.
• Allowing users to be assigned a temporary password for their first login, but requiring that they must change it to a permanent password immediately.
• Encouraging users to change their passwords periodically (ideally, every 60 days) to maintain account security. If a user does not log in for 60 days, the account may be disabled.
• Using two-factor authentication (2FA) in addition to password authentication for added security. 

Note: High and HVA systems have additional complexity and history requirements. See Password Requirements on CyberGeek for details by system categorization.

Public Key-Based Authentication 

CMS uses public key cryptography (PKC) and Public Key Infrastructure (PKI) to provide a robust and secure authentication and authorization system, ensuring that only authorized individuals and devices can access sensitive CMS systems and data.   

PKI is a set of policies, processes, server platforms, software, and workstations used to administer certificates and public-private key pairs. This includes the issuing, maintaining, and revoking of public key certificates. CMS uses digital certificates issued by a trusted Certificate Authority (CA) to verify the identity of users and devices. These certificates bind a user's public key to their identity.  

PKI at CMS has two different functions. 

1. What CMS does at authentication. At authentication, CMS systems enforce access controls over private keys and ensure authenticated identities are mapped to accounts.
2. What CMS does to operate PKI securely. When PKI is used, CMS must ensure that information systems:

• Validate certificates by constructing a certification path with status information to an accepted trust anchor and maintain local revocation caches to support this validation.
• Enforce authorized access to the corresponding private key.  
• Map the authenticated identity to the applicable account.
• Handle key generation and transport securely using FIPS 140-3 compliant cryptographic modules and secure channels.

Additional information for PKI deployment requirements can be found in NIST SP 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, and NIST SP 800-15, Minimum Interoperability Specification for PKI Components.       

Protection of Authenticators 

CMS safeguards authenticators commensurate with the security categorization of the information they protect. At CMS, authenticators are protected according to the highest information category of the systems they access. Information categories are determined through the security categorization process.

Authenticator Feedback 

Ensure information systems conceal authentication feedback to prevent use or exploitation by unauthorized individuals. Restricting feedback from the authentication process limits the ability of unauthorized users to compromise the authentication mechanisms for accounts that can access PHI. 

CMS-specific processes for the implementation of this security requirement include: 

• Ensuring passwords are unreadable (obscured or masked) during authentication, encrypted during transmission, and securely stored.
• Ensuring that both system and application installations contain encrypted password files, using encryption compliant with FIPS 140-3 requirements.
• Ensuring that sensitive fields, including Social Security Numbers (SSNs) and passwords, are masked when displayed to address the threat of unauthorized viewing or disclosure, also known as “shoulder surfing.” 

Cryptographic Module Authentication 

CMS requires the use of cryptographic modules that implement authentication mechanisms to protect its sensitive information and systems. These mechanisms must comply with relevant laws, regulations, and standards, such as FIPS 140-3.    

CMS Cryptographic Module Authentication practices include: 

• Implementing policies that specify the use of FIPS-140-3 tested and validated encryption solutions, including secure VPNs or VDIs, and hardware security modules (HSMs) when appropriate.
• Implementing secure and compliant cryptography (e.g., FIPS 140-3) within CMS applications (this is the responsibility of CMS System Developer Maintainers (SDM) or Application Teams).
• Ensuring that cryptographic functions of message digest hashing and encryption are built into the application code. These functions are used in the authentication process and cannot be invoked by non-privileged or privileged users outside of the authentication process.
• Ensuring that all CMS systems implement cryptographic mechanisms (including encryption) to protect the confidentiality and integrity of sensitive information, including remote sessions and CUI.  

Identification and Authentication (IA) of Non-Organizational Users 

CMS requires its information systems to uniquely identify and authenticate non-organizational users, or processes acting on their behalf, before granting access to CMS systems and networks (unless a risk-based decision determines that authentication is unnecessary). NIST defines non-organizational users as any user who is not an organizational user (this includes members of the public).

At CMS, these users include:

• Beneficiaries
• Providers
• Non-CMS-contracted researchers 

CMS-specific practices for implementing this requirement include:

• Employing effective identity proofing and authentication processes, compliant with HHS and NIST SP 800-63-3, for non-organizational users when CMS sensitive information (e.g., CUI, PII, PHI) is to be accessed, modified, or released.
• Requiring the use of authenticators and unique user identifiers for non-organizational users.
• Requiring user identification for any transaction that has information security and privacy implications when a user is accessing CMS Help Desk support. 

If systems cannot meet these requirements, components may make risk-based decisions (RBDs) in accordance with CMS-defined RBD and Authorization to Operate (ATO) processes.

Acceptance of PIV Credentials from Other Agencies 

CMS ensures its information systems accept and electronically verify PIV credentials from other federal agencies that comply with FIPS 201-03 and related guidance.  

CMS practices for accepting PIV credentials from other agencies include: 

• Implementing processes for the electronic verification of PIV identity assertions from other agencies.
• Accepting and leveraging valid PIV credentials issued by other agencies, when electronically verified, rather than issuing new ones. This applies to both logical and physical access (where authorized).
• Establishing and maintaining agreements (where required) to facilitate cross-government identity federation.

CMS also has procedures for accepting PIV-I (PIV Interoperable) credentials from non-federal entities that meet the PIV-I requirements.   

Acceptance of External Authenticators 

CMS has specific policies and procedures regarding the acceptance of external authenticators, aiming to ensure secure access to its systems while adhering to relevant security standards. These policies primarily focus on using NIST-compliant authenticators and documenting accepted external authentication methods.   

CMS practices for acceptance of external authenticators include:

• In general, accepting only external authenticators that comply with NIST SP 800-63B (or that meet or exceed the minimum federal government-wide requirements).
• Maintaining and documenting a list of accepted external authenticators.
• Using Experian as the external authentication service provider for the identity verification process.
• Requiring registration of a phone or computer to obtain the necessary security code when accessing the CMS IDM system, providing an extra layer of security via MFA.

Use of Defined Profiles 

This security requirement ensures CMS systems comply with NIST-issued profiles for identity management, which address open identity management standards.  

To ensure open identity management standards are viable, robust, reliable, sustainable, and interoperable, CMS implements the OMB memorandum Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM) Policy M-19-17. This memorandum requires federal agencies to continue implementing the requirements of HSPD-12 and NIST SP 800-63-3 to enable agency-wide use of PIV credentials.

Re-Authentication 

This requirement ensures users re-authenticate under defined circumstances or situations. It confirms the user’s continued presence or action before proceeding, serving as an additional security layer. Example circumstances for re-authentication include:

• When there are changes to a user's role or access
• When executing an administrative or privileged function
• After a fixed time period

CMS has defined the following re-authentication circumstances: 

• CMS information systems, along with GFE computers distributed to CMS federal staff and contractors, are configured with a fifteen (15) minute device lock on the operating system. The user will be required to re-authenticate themselves to continue accessing CMS resources.
• Some applications, like Windows and UNIX servers, are configured to lock the application after thirty (30) minutes of inactivity. The user will be required to re-authenticate themselves to continue accessing CMS resources.
• If a security breach or suspicious activity is detected, the system might prompt a re-authentication to verify the user's identity and ensure the session is secure.
• If a device is locked (e.g., after multiple failed login attempts), the user may need to re-authenticate to unlock it and regain access.
• If the user's password or other credentials change, re-authentication might be necessary to update the system with the new information.   

Identity Proofing 

Identity proofing is the process of providing evidence to a Credential Service Provider (CSP) to establish the validity of a claimed identity, enabling the CSP to assert it at a specified assurance level.

The CMS Identity Management Manual describes the Remote Identity Proofing (RIDP) process used for verifying the identities of users who request roles. All users requesting access to a CMS application with a Level of Assurance (LOA) 3 security rating must undergo RIDP. Users with foreign addresses are not eligible for online or phone proofing.   

Verification occurs in the following order:  

• Online Proofing - An identity verification procedure that uses Experian’s computer-based Identity Verification service.
• Phone Proofing - An identity proofing procedure that uses Experian’s telephone-based Identity Verification service. Phone proofing is only available if the user is unable to verify their identity using online proofing.
• Manual Proofing - An identity proofing procedure performed by an application’s Tier-1 Help Desk in accordance with its policies. Manual proofing is not available for all applications and is offered only if both online and phone proofing are unsuccessful.

CMS follows standards and guidelines specifying identity assurance levels for proofing, as defined in NIST 800-63-3 and NIST 800-63A. 

Identity Evidence, Validation, and Verification 

This requirement reduces the likelihood of individuals using fraudulent identification to establish an identity and increases the effort required by potential adversaries. It also requires that presented identity evidence be validated and verified through CMS-defined and approved methods. This is accomplished through the RIDP process, which involves collecting, validating, and verifying identity evidence.

• CMS uses documentary evidence, or a combination of documents and biometrics, to fulfill this control.
• CMS follows standards and guidelines specifying acceptable forms of evidence, as outlined in NIST 800-63-3 and NIST 800-63A. 

In-Person Validation and Verification 

This requirement mandates that validation and verification of identity evidence be conducted in person before a designated registration authority. In-person proofing reduces the likelihood of fraudulent credentials being issued because it requires the physical presence of individuals, the presentation of physical identity documents, and actual face-to-face interactions with designated registration authorities.  

This is implemented through the RIDP process, which involves collecting identification evidence from individuals.

CMS follows standards and guidelines specifying acceptable methods of in-person identity proofing, as defined in NIST 800-63-3 and NIST 800-63A. 

Address Confirmation 

CMS may use out-of-band methods to increase assurance that the individual associated with an address of record is the same person who participated in registration. Guidelines include:

• Require a current residential address where the individual receives important mail related to finances and other personal information (used by the Experian system to verify identity).
• If an individual has a recent address change, prior addresses may be used for identity proofing.
• Do not enter extraneous symbols in the address field. To confirm the correct format, refer to USPS Look Up a Zip Code. 

CMS follows standards and guidelines specifying acceptable methods for address confirmation, as defined in NIST 800-63-3 and NIST 800-63A.