Identification and Authentication (IA)

Identification and Authentication (IA) 

Identification and Authentication (IA) is a technical measure that prevent 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); and the 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 

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, such as 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. 
• The use of 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:  

• Utilizing 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, is used to authenticate privileged organizational users.
• Complying with HHS and CMS Identification, Credential, and Access Management (ICAM) standards.
• Requiring a minimum of two-factor authentication (e.g., PIV and personal identification number (PIN)) to gain access to CMS systems.
• Implementing 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. 

• Implements 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.  
• Utilizes 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: 

• Systems are configured and required to accept PIV-compliant credentials.
• Conducts background investigations, adjudicates the results per HHS National Security Clearance Processes, and issues identity credentials to employees and contractors who require long-term (greater than 6 months) routine access to federally controlled facilities and/or information systems. 
• Adopts the Enterprise User Administration (EUA) Identity and Credentialing Tool (ICT) New Users Guide document to guide the user on how to request a PIV card. 
• The PIV status tracker provides CMS contractors and Contracting Officer Representatives (CORs) with visibility into the badging process.
• Complies 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. Ensuring that it 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.  
• Remote access to the CMS secure Virtual Private Network (VPN) or Virtual Desktop Infrastructure (VDI) requires CMS provided/approved software packages and secure user system account credentials, along with strict security requirements, including up-to-date system patches, malware detection, and FIPS 140-3 validated encryption.
• CMS requires appropriate digital certificates/keys for local wireless connections to all CMS issued devices.
• CMS identifies and categorizes applications as either allowed (allowlisted) or disallowed (denylisted) for use on approved devices, with users restricted to using only approved applications from authorized app stores.  
• CMS requires users to adhere to acceptable use policies for mobile devices and removable media, including the HHS Rules of Behavior (RoB).  
• All systems and network devices under CMS control are required to display a notice and consent banner upon user authentication, acknowledging 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: 

• CMS disables 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)). 
• Organizational users are assigned unique identifiers after authorization by designated approvals. 
• Laptops, workstations and printers are identified with unique tag numbers and network devices are assigned unique identifiers. 
• CMS reviews 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.
• CMS prevents 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: 

• The CMS IDM System plays a central role, offering users a platform to manage their accounts, including changing passwords and security questions.  
• CMS follows best practices for key management through its Key Management Handbook, ensuring systems are well-protected.
• CMS employs password-based authentication subject to minimum and maximum lifetime restrictions and reuse limitations.
• CMS enforces strong password policies, including minimum length, character complexity, and password history restrictions.
• CMS regularly reviews and revokes 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 and, similarly, when passwords are part of multi-factor authenticators. It is important to note that mobile devices are excluded from password complexity requirements.

The following documents CMS-specific process for Password-Based Authentication: 

• The CMS password-based authentication policy requires strong, unique passwords that are at least eight (8) characters for regular user passwords and fifteen (15) for administrator or privileged accounts.
• At CMS, passwords must be cryptographically protected and not contain personal information or parts of the user's ID.
• Passwords cannot be the same as the user's last six passwords and can only be changed once every 24 hours. 
• Users may be assigned a temporary password for their first login, but they must change it to a permanent password immediately.
• Users are encouraged 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.  
• CMS also uses two-factor authentication (2FA) in addition to password authentication for added security. 

Please note that High and HVA systems have additional complexity and history requirements, like: "Additionally, password requirements apply for High and HVA systems. 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, including issuing, maintaining, and revoking 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. 

The following details the CMS specific process for the implementation of this security requirement: 

• CMS systems ensure passwords are unreadable (obscured or masked) during authentication, encrypted during transmission, and securely stored. 
• Both system and application installations contain encrypted password files, using encryption compliant with FIPS 140-3 requirements. 
• 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.    

The following documents CMS Cryptographic Module Authentication practices: 

• CMS implements 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.
• CMS System Developer Maintainers (SDM) or Application Teams are responsible for implementing secure and compliant cryptography (e.g., FIPS 140-3) within the Application.
• 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.
• All CMS systems must 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, including public users.  

At CMS, these users include: 

• Beneficiaries
• Providers
• Non-CMS-contracted researchers 

The following are CMS-specific practices for implementing this requirement:

• Employ 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.
• Require the use of authenticators and unique user identifiers for non-organizational users.
• CMS Help Desk support requires user identification for any transaction that has information security and privacy implications. 

If systems cannot meet these requirements, components may make risk-based decisions (RBDs) in accordance with CMS-defined RBD and Authorized 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.  

The following outlines CMS practices for accepting PIV credentials from other agencies: 

• Implement processes for the electronic verification of PIV identity assertions from other agencies.
• Accept and leverage 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). 
• Establish and maintain 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.   

The following documents CMS practices for acceptance of external authenticators: 

• CMS generally accepts only external authenticators that comply with NIST SP 800-63B, or meet or exceed the minimum federal government-wide requirements.  
• Maintain and document a list of accepted external authenticators. 
• CMS uses Experian as the external authentication service provider for the identity verification process.
• The CMS IDM system requires registration of a phone or computer to obtain the necessary security code, providing an extra layer of security (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. This requirement confirms the user’s continued presence or action before proceeding, serving as an additional security layer. Examples of this CMS or system-defined situations could be due to a change in a user role or access, when executing an administrative or privileged function, after a fixed time-period and among others. 

The following documents CMS defined 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. 

• 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.