Identity Management

• PIA Validation (PIA Refresh/Annual Review)
• Other - PIA renewal and added PII field Mailing address

In support of the American Recovery and Reinvestment Act (ARRA), the Health Information Technology for Economic and Clinical Health Act (HITECH), and the Patient Protection and Affordable Care Act of 2010, also known as Affordable Care Act (ACA), Centers for Medicare & Medicaid Services (CMS) has implemented an Identity Management (IDM) system. Identity Management (IDM) is an Identity and Access Management (IAM) system that provides application program interface (API) and user interface services as a means for users needing access to CMS applications to self-identify, apply for and receive credentials in the form of a single-factor authentication, User Identifier (UserID) and Password and/or Multi-Factor Authentication (MFA). IDM manages the lifecycle of user IDs, passwords, and the supporting data collected from the users from issuance through deprovisioning and archival.

IDM services are grouped into a few main areas:

Registration Service – This function allows new users to register with IDM and obtain a single digital identity that can be used across CMS applications that are integrated with IDM. 

Authentication Service – This function confirms the user’s identity attributes and access privileges. It is available only to users who have completed the registration process and have a valid credential. The Authentication Service validates that users have a valid credential issued to them by providing something they know (e.g., a password), something they have (e.g., a security token), or a combination of those factors.

Authorization Service – provides for integrating applications that support multi-level approval for system access. It tracks and manages the assignments of IDM Solution roles to individual users and provides role detail information to participating applications. It also provides the ability to check the authorization against an authoritative data source and provision user information to various CMS repositories.

Identity Proofing- Remote Identity Proofing (RIDP) is integrated with Experian, using credit and demographic data to verify users at NIST IAL2 standards.

Identity Lifecycle Management (IDLM) Service – This function allows user information to change over time in a controlled and auditable manner within IDM. User information can be managed by the user through self-service or by an Authorized Help Desk user.

Reporting- Integrates with AWS QuickSight to provide dashboards and reports with:

Role-based access

Operational and monitoring metrics

Filtering, exporting, and printing features

User Interfaces

Accessible via: 

IDM UI (IDM Apps)

CMS Enterprise Portal (My Enterprise Portal)

Okta Dashboard

Custom application-built UIs

All interfaces are 508 compliant and browser compatible.

Help Desk Support 

Tier 1 (Application Help Desks): Initial user support

Tier 2 (IDM Team): Escalation support for IDM-specific issues

Key functions include account unlock, temporary passwords, and identity record updates

IDM collects, maintains and stores the following information on external and internal CMS system users: First Name, Last Name, Date of Birth, E-mail Address, Mailing address, Phone Number, Social Security Number, User Identifier (User ID) and Password and Organization Name.

The Social Security Number is used to check for registrant uniqueness within the system. The Username and Password are stored and are created by the user. Under some circumstances, the password may be reset to a temporary value by a helpdesk technician.

The User Identifier (User ID) and Password are used to grant access to applications that users have been authorized to access.

Identity Management (IDM) is an Identity and Access Management (IAM) system that provides application program interface (API) and user interface services as a means for users needing access to CMS applications to self-identify, apply for and receive credentials in the form of a single-factor authentication, Username and Password and/or Multi-Factor Authentication (MFA). IDM manages the lifecycle of user IDs, passwords, and the supporting data collected from the users from issuance through deprovisioning and archival.

IDM collects, stores and maintains the following information: First Name, Last Name, Date of Birth, E-mail Address, Mailing address, Phone Number, Social Security Number, User Identifier (User ID) and Password and Organization Name.

The Social Security Number is used to check for registrant uniqueness within the system. The First Name, Last Name, Date of Birth, Phone Number, and Organization Name are used by the approver to approve the user’s request for access.

The Username and Password are used to grant access to application that users have been authorized to access.

Application tier 1 and tier 2 helpdesk (HD) users and approvers of the tier 1 /vertical applications will verify the end-user's PII before assisting users. This retrieval is normally done by leveraging the user's username, Date of birth and/or last four of SSN in the search section of the HD user interface.

• Social Security Number
• Name
• Date of Birth
• E-Mail Address
• Mailing Address
• Phone Numbers
• Other - Organization Name, Username and Password

• Employees
• Public Citizens
• Business Partners/Contacts (Federal, state, local agencies)
• Vendors/Suppliers/Contractors

U.S.C. § 7701(c)(1), Appellate procedures
U.S.C. 552a(b)(1), Records Maintained on Individuals
5 U.S.C. Section 301, Departmental Regulations

Executive Order 9397, the Debt Collection Improvement Act (PUBLIC LAW 104–134—APR. 26, 1996), 31 United States Code (U.S.C.) § 7701(c)(1), and 5 U.S.C. 552a(b)(1)

• Online
• Email

• Within the OPDIV

• Members of the Public
• Private Sector

• Private Sector: Experian Information Solutions, Inc. provides Remote Identity Proofing (RIDP) services. PII is sent to Experian over a secure channel using Federal Information Processing Standards (FIPS) 140-2 compliant encryption. Experian enables IDM to prove the identity of users.

The disclosure of any Personally Identifiable Information (PII) within the Identity Management (IDM) system is formally documented and accounted for through multiple mechanisms to ensure transparency, accountability, and compliance with the ARS and federal regulations.

Disclosures are logged through:

Interconnection Security Agreements (ISA) – All third-party data exchanges involving PII, such as with Experian for Remote Identity Proofing (RIDP), are governed and documented via active ISAs that clearly define permissible use and safeguards.

CMS Incident Management Process – Any unauthorized or unintended disclosure of PII triggers the formal incident response protocol:

A ServiceNow ticket is immediately generated to capture all relevant incident details, including what was disclosed, when, how, and by whom.

A structured incident investigation is conducted to assess impact, identify root causes, and determine corrective actions.

Findings from the investigation are fully documented within the ServiceNow ticket and a formal incident report is provided to the data owner(s) of the affected system(s).

Remediation actions are implemented based on the severity and nature of the incident, in alignment with CMS security and privacy policies.

Additionally, all disclosure incidents and related actions are tracked to support audit readiness, risk mitigation, and compliance reporting to CMS leadership and oversight bodies as needed.

Individuals are notified that their personal information will be collected through a Privacy Act Statement, which is presented during the initial registration process and again on a recurring basis (e.g., annually or at login). This statement is included as part of the Terms and Conditions, which users must affirmatively accept in order to proceed.

The Privacy Act Statement informs users that the Identity Management (IDM) system will collect their Personally Identifiable Information (PII) for the purpose of identity proofing, authentication, and access management. It explains how the information will be used, maintained, and shared in accordance with federal privacy laws, including the Fair Credit Reporting Act (FCRA), and states that explicit consent is required to use identity verification services.

This process ensures individuals receive prior notice and provide informed consent before any PII is collected or processed.

Users are presented with a Privacy Act Statement that outlines the purposes for which their Personally Identifiable Information (PII) is collected and how it will be used. This statement is included in the Terms and Conditions during the initial registration process and is reaffirmed at each login. Additionally, a warning banner is displayed on the login page indicating that the system is a government-operated system and subject to monitoring.

In the event of major changes to the system that impact the disclosure or use of PII, users will be notified through updates to the Terms and Conditions and Privacy Act Statement. Continued use of the system after such changes constitutes acknowledgment and acceptance of the revised terms. Users have the option to discontinue use of the system at any time, thereby opting out of the use of their PII in IDM.

IDM ensures the periodic review of PII to maintain its integrity, accuracy, relevance, and availability in accordance with CMS policy and federal guidelines. While individual CMS applications are responsible for the initial collection and validation of PII, IDM conducts annual reviews as part of its Cybersecurity and Risk Assessment Program (CSRAP) to validate the appropriateness of retained PII, ensure it remains necessary for business purposes, and complies with CMS Acceptable Risk Safeguards (ARS).

These reviews include verification of data integrity checks, evaluation of data retention practices, and audits of user access and activity logs. IDM enforces role-based access control (RBAC) and the least privilege principles, ensuring only authorized personnel can access PII. All PII is encrypted in transit and at rest using FIPS 140-2 validated cryptographic modules. Data accuracy and relevancy are further supported through integration with authoritative data sources where feasible. Findings from these reviews are documented and used to inform remediation activities, if required.

• Users: IDM account users have access to only their PII. This information is used to identify the user and allow them to manage their IDM user account.
• Administrators: Administrators and direct Contractors have access to PII to facilitate the process of managing user accounts, creating new user accounts and disabling inactive user accounts. Administrators also have access to PII to maintain and test IDM.
• Contractors: Administrators and direct Contractors have access to PII to facilitate the process of managing user accounts, creating new user accounts and disabling inactive user accounts. Administrators also have access to PII in order to maintain and test IDM.

IDM employs role-based access controls (RBAC) to ensure that access to Personally Identifiable Information (PII) is restricted to authorized users based on the principle of least privilege. Access is granted only to individuals whose roles require it to perform their official duties. System users—such as administrators, developers, and contractors—must submit access requests that specify the required level of access.

Each access request undergoes a formal review and approval process, which includes verification and approval by the designated business owner or their representative (e.g., Contracting Officer’s Representative). Access decisions are documented and reviewed periodically to ensure ongoing needs and appropriateness. Additionally, all access to PII is logged and monitored, and users are required to complete appropriate security and privacy training before being granted access.

IDM uses the principle of the least privilege and role-based access controls (RBAC) to ensure that individuals, including system administrators, developers, and contractors, are only granted access to the minimum amount of Personally Identifiable Information (PII) necessary to perform their job functions. Access is based on assigned roles that are approved by the business owner or their delegate, and all access requests must specify the level and purpose of access required.

Additionally, IDM enforces periodic access reviews and account recertifications to validate that access remains appropriate. Technical safeguards, such as attribute-based access controls (ABAC), data masking, and system auditing, are used to prevent unauthorized access and to ensure that users cannot access more data than is necessary for their official duties.

All personnel with access to the Identity Management (IDM) system, including system owners, program managers, developers, operators, and contractors—are required to complete the CMS Information Systems Security and Privacy Awareness (ISSPA) Training. This training is mandatory when users are initially issued their CMS User ID and must be retaken on an annual basis.

The ISSPA Training covers responsibilities related to the handling of Personally Identifiable Information (PII), applicable federal privacy and security requirements, and CMS policies. Role-based training is also provided to individuals with elevated privileges or responsibilities related to system operations and data protection.

CMS tracks training compliance through its Learning Management System (LMS), and system access is contingent upon completion. 

National Archives and Records Administration (NARA), General Records Schedule (GRS) 3.1, 3.2, 4.3 states that IDM will destroy/delete all records that are 7 years 6 months, 10 years 6 months, or 20 years 6 months old, based on the maximum level of operation of the Certification Authority, or when no longer needed for business, whichever is later. IDM will delete/destroy all records when the agency determines they are no longer needed for administrative, legal, audit or other operational purposes. The following are all NARA approved records schedules for IDM:

1. Master Files

   1. Registration - username/password and challenge question/answers, allows users to prove their identity by associating federate credentials as well as using these credentials for subsequent authentication

      DISPOSITION: Destroy/delete when 7 years 6 months - 20 years 6 months old, based on the maximum level of operation of the Certification Authority, or when no longer needed for business, whichever is later.

      (Disposition Authority, N1-GRS-07-003, item 13a1)

2. Authorization - manages applications as well as entitlements within applications as requested items to end users; integration of CMS applications into IDM; connects with application stores specific to Federal Exchange using the database connector.

   Regarding GRS:5.1/5.2
   Where applicable IDM will follow disposition instructions. IDM does not maintain any agency office record storage, non-recordkeeping electronic records, non-mission related committee records nor does IDM maintain any transitory/intermediary records. In the event of such a record IDM will follow the disposition requirements as set forth.

The Identity Management (IDM) system secures Personally Identifiable Information (PII) through a combination of administrative, technical, and physical controls in accordance with CMS policies and federal security standards.

Administrative: IDM enforces the principle of least privilege and role-based access control (RBAC) to ensure users and administrators are only granted access to the minimum PII necessary for their official duties. Access requests must be formally submitted, specifying the required access level, and are subject to review and approval by designated business owners or their representatives. All users must complete the CMS Information Systems Security and Privacy Awareness (ISSPA) training upon account issuance and annually thereafter.

Technical: IDM is hosted in a secure Amazon Web Services (AWS) environment and is designed using industry best practices, including secure coding standards, encryption of data in transit and at rest, multi-factor authentication (MFA), audit logging, and continuous monitoring. The system is assessed against applicable Federal Information Security Modernization Act (FISMA) requirements and implements NIST 800-53 controls to ensure the confidentiality, integrity, and availability of PII.

Physical: IDM is hosted within AWS Federal Risk and Authorization Management Program (FedRAMP) authorized data centers that implement layered physical security measures. These include on-site security personnel, surveillance, badge access, and biometric screening to restrict access to authorized personnel only.

My Enterprise Portal

IDM Self Service

IDM Apps

• Session Cookies - Collects PII?: No
• Persistent Cookies - Collects PII?: No