The most frequently asked questions (FAQ) by IDM users are listed below.
IDM Migration FAQs
1. Will EIDM users need to create new accounts to access IDM?
No, all users who have an account in EIDM will be migrated to IDM. Users will be migrated to the new system with their current User ID, password, role(s), and core attributes.
2. What does the system do when a user changes their profile and it matches an existing profile (i.e., creating a duplicate profile)?
IDM, just like EIDM, performs a uniqueness check by comparing the combination of First Name + Last Name + Email Address. When a user attempts to create or modify a profile that subsequently fails this uniqueness check, IDM will display an error preventing the user from creating a duplicate profile.
3. Do users need to log into their accounts within a certain period after the migration?
There is no limit by which a user should login after migration. We recommend that all users login to EIDM a prior to the actual migration to ensure the email address associated with their account is correct and accessible. The reason for this is that email will be the default MFA and self-service device in IDM.
4. Will you disable accounts after a certain period of inactivity? If so, how long?
We will continue to disable accounts after 180 days of inactivity. Furthermore, we will continue to delete accounts after 365 days of inactivity, if the user does not have any roles in IDM.
5. Will end users experience any changes to their accounts during migration? If so, what?
Users should not experience any changes to their current roles and attributes in EIDM. Those same roles and core attributes will be migrated to IDM. Every effort is being made to migrate roles and attributes exactly as they are in EIDM, so that users can immediately access their applications after the migration.
6. Will users who do not have any roles be migrated to IDM?
Yes, we will migrate all users, regardless of if they have a role or not. Once in IDM, if an account remains in-active and has no roles then we will delete that account after 365 days.
7. How will annual certification be handled in IDM?
Annual Certification (AC) is not included in the IDM Minimum Viable Product (MVP). However, AC is in the backlog for development after we deploy the MVP. As in EIDM, AC is not an inheritable control. Applications are responsible for certifying their users in accordance with CMS' security policies. IDM will continue to provide a place to keep a record of user certification status and provide reporting. While the requirements for AC in IDM have not been finalized we anticipate that there will be a set period of time (much like Open Enrollment) that users will be recertified, as opposed to users being required to be recertified by the anniversary of receiving their role. Additionally, IDM will no longer remove roles from users that do not have their roles recertified. Instead, we will generate a report for Business Owners that communicates which users are out of compliance. It will be the responsibility of the application to remove the roles of users who should no longer have them.
8. REST APIs in IDM versus REST APIs in EIDM, will there be significant changes?
No, the IDM RESTful APIs are planned to be nearly the same as their EIDM counterparts.
9. Will existing user data in EIDM be migrated to IDM?
Yes, with the exception of Multi-Factor Authentication (MFA) devices, which cannot be migrated. User IDs and passwords, along with core attributes, have already been migrated to Okta (the authentication component of IDM). This information is kept synchronized between EIDM and IDM in near real time, so that if a user changes their password in EIDM it will automatically be ‘synched’ in IDM.
10. What happens to pending requests that are not yet approved?
Requests that are not approved before the cutover will not be migrated. They will be canceled in EIDM and the user has to re-request it in IDM.
11. When do I need to take action on the pending role requests in my queue in order for the roles to be migrated?
Our recommendation is to complete all the approvals by noon on the day of cutover at the latest. One of our activities on migration night is to conduct a final data migration before we migrate the application.
12. When will user role data be migrated to IDM from EIDM for the applications that are migrating in the Production environment?
The data migration process will commence on the evening of Jan 3rd. Any changes to role data in EIDM will be migrated to IDM at the end of every day starting the 4th of January.
13. If the role data is migrated on the 3rd, can I login anytime between the 4th and 15th to see my access in IDM?
Users can start logging into the system starting Jan 11th. However, users will not be able to make any changes to their role information. User can set their passwords, MFA devices etc., not role information updates will be disabled till the 15th.
14. Will User Guides for the IDM system be made available?
The IDM User Guide, along with other helpful documentation such as the Application Tier 1 Help Desk Training is available. We encourage applications to tailor the IDM User Guide for their end users. Prior to the migration, the IDM User Guide will also be published to the IDM Public Facing Partner page on CMS.gov.
EIDM Availability Post Go-Live
15. Will EIDM lower environments be available after Jan 15th Go-Live?
Yes, EIDM lower environments will be available till the final cutover on the 12 of February. However, once an app is migrated to production, any changes to user roles for the migrated application are not allowed in EIDM.
EUA Applications & Users
16. Can IDM Authenticate EUA Users?
IDM is capable of providing authentication and MFA services to EUA applications. Users from integrated EUA applications may login to IDM using their four-character EUA User ID and password. At the time of login, IDM passes the user’s credentials to the Enterprise LDAP for validation; eLDAP then returns the validation result to IDM. Please note that four-character User IDs must still be created and managed in EUA and cannot be created in IDM. The minimum length of a valid IDM User ID is six characters.
17. My EUA application is integrated with IDM, how to I get access to my application?
Role management for integrated EUA applications is completed by requesting the appropriate application job code in EUA. You will not be able to request a role in an EUA application within IDM or the Enterprise Portal. For the correct job code information please consult your application's documentation.
18. Will there be a user registration freeze?
No, there will not be a freeze on new users or a date by which new users must be created in EIDM in order to be migrated to IDM. There is user sync between EIDM and IDM, so if a user is created in EIDM that user is simultaneously created in IDM. Regardless of whether that user has a role or not, all users will be migrated from EIDM to IDM.
19. What kind of searches will be available to Application Tier 1 Help Desk users?
Within the Help Desk UI there are two methods to search for users, Application Search and Enterprise Search. Enterprise Search looks for users across the entire system, while Application Search looks for users that have a role within a specific application.
20. What happens if a Help Desk user changes someone’s email to an email that is already used in the system?
As in EIDM, multiple accounts can use the same email address in IDM. When a new user is created in IDM we conduct a uniqueness check on the combination of their First Name, Last Name, and Email. If a user already exists with that exact combination then the system will throw an error. The same uniqueness check occurs when a Help Desk user attempts to change a user’s email address. If that exact combination already exists within the system then an error will be thrown. However, if the change passes the uniqueness check, then the user's email address would be changed.
21. Can a Help Desk user provide a one-time MFA code to an end user who doesn’t have access to their MFA factor?
No, the one-time MFA code functionality is not part of IDM's MVP. This may be considered as a future enhancement, but at the time of migration Help Desk users will not be able to trigger a one-time MFA code.
Level of Assurance (LOA)
22. What is the LOA associated with my application?
Applications do not have an LOA, roles and people have an LOA. The LOA that is tied to a role is based on the data that a user is able to access once they've been granted the role.
23. How is the LOA decided for my application’s roles?
Application Information System Security Officers (ISSO), in coordination with the Business Owner, are responsible for deciding the appropriate LOA for roles within the application. In IDM, any role that is deemed to be LOA3 will require users who request that role to complete Remote Identity Proofing (RIDP) through Experian; these users will also be required to go through MFA each time they login to IDM.
24. How will MFA change in IDM?
Okta will handle MFA in IDM, as opposed to Symantec in legacy EIDM. The following factors have been approved for use in IDM:
- Short Message Service (SMS)/Text Message
- Interactive Voice Response (IVR)
- Google Authenticator (Smart Phone App)
- Okta Verify (Smart Phone App)
Please note that in IDM there will be no desktop client available for MFA. Users are strongly encouraged to add additional MFA devices to their profile.
25. How will migrated users complete MFA during their first login to IDM?
Email will be the default MFA device for all users who are required to login with MFA. This will allow all migrated MFA users to use MFA on their first login. The IDM Team decided upon email as the default MFA factor as 71% of MFA logins are performed using email in EIDM.
26. What if I no longer have access to the email associated with my account?
Users who no longer have access to the email address associated with their EIDM account must log into EIDM prior to the migration and change their email address to one that they can access. If it is found that the user does not have access to the email address associated with their account after the migration has been completed, then the user must contact their application's Tier 1 Help Desk. Application Tier 1 Help Desks have the ability to change the email address associated with a user's account.
27. Will I be able to opt into MFA in IDM?
In IDM, MFA will not be required for LOA1 or LOA2 roles. MFA will only be required for LOA 3 roles. In legacy EIDM we offered LOA2 roles the option to opt into MFA, however in IDM we will no longer offer optional MFA for LOA2 roles.
Current LOA2 users who opted for MFA in EIDM will be migrated to IDM with MFA. We are not taking MFA away from them. New LOA2 users in IDM will not be required to have MFA, nor will they have the option to opt in for MFA.
28. How will you handle MFA for test accounts in the lower environment?
MFA requirements are static, regardless of environment. If an account requires MFA in EIDM then it will require MFA in IDM.
29. Will Help Desk users still be able to unlock my locked MFA device?
In IDM there is no MFA unlock feature because Okta, IDM’s MFA provider, does not lock devices due to incorrect attempts. If a user completes five unsuccessful attempts to complete MFA, then Okta will lock the account. The user must then unlock their account through self-service, or by contacting their Tier 1 Help Desk for assistance.
User Interface/Functionality Changes
30. What UI changes can end users expect in IDM?
The biggest difference in IDM is the new IDM UI that SAML integrated applications will leverage to complete authentication, authorization (role management), and user profile management. SAML integrated applications typically access their application directly through the application's URL, which then redirects the user to IDM's login page. After a successful authentication, the user is then direct back to their application.
The URL for the IDM UI is https://home.idm.cms.gov/
The CMS Enterprise Portal will continue to leverage IDM to handle authentication and authorization. Applications integrated with the Portal will continue to access their application by selecting the app tile on the Portal landing page.
The URL for the CMS Enterprise Portal remains unchanged, and is https://portal.cms.gov/
Security Question & Answer (SQA)
31. How does the security questions in legacy EIDM differ from Security Question & Answer (SQA) in IDM?
In legacy EIDM users were required to have three security questions that they answered to make user profile updates and complete self-service functions (forgot password, unlock account, etc.). In IDM, we are shifting to a single Security Question & Answer (SQA) that users will be prompted to establish during new user registration. SQA will not be used for profile updates, but are necessary to perform self-service functions such as user unlock or password reset.
32. Will my EIDM Security Questions be migrated to IDM?
Yes, we will migrate one of the three EIDM security questions to IDM. This question will be selected and migrated at random, so it is important that users are familiar with their EIDM security questions and answers.
33. Will I be able to use my SQA to complete a self-service function during my first login to IDM?
Yes, users will be able to complete self-service functionalities to assist in their first login to IDM. Again, this will require a user to answer the security question that was migrated to IDM. Once logged into IDM, users can change their SQA in IDM.
Self Service Reporting
34. Will the self-service reporting functionality be available in IDM?
Self-service reports are now part of the IDM MVP. The reporting functionality will be available immediately after the migration to IDM. The self-service reporting functionality requires a user to request a role in the IDM Reports application before they are granted access.
35. Will I be able to execute export reports via the Help Desk UI in IDM?
We understand that application Tier 1 Help Desk users leveraged the export functionality in EIDM to execute reports in EIDM. That was possible because in EIDM the number of search results returned to a HD user were uncapped. In IDM user search results are limited to 10 results; if the user is not located the HD user must provide additional search criteria to further narrow the search and locate the user. Help Desk users can still export the results of a user search, however, the maximum number of users included in the export would be ten users.
36. The user base from my application accesses another IDM integrated application at the same time to complete their business, is that still possible?
Yes, users can access more than one integrated application at the same time, within the same browser if there is an active Okta session. Users will not be prompted to login again to the second application they are accessing if the Okta session is active. However, if the user attempts to access multiple applications through two separate browsers (e.g. if the user logged into Application A in Chrome and then attempted to login to Application B in Internet Explorer), or if the Okta session has expired, then they would be required to login again. Okta sessions are terminated after 15 minutes of inactivity.