> ## Documentation Index > Fetch the complete documentation index at: https://docs.ulm.m1amdocs.com/llms.txt > Use this file to discover all available pages before exploring further. # Multi-Factor Authentication Multi-factor authentication (MFA) is a security measure that allows a user to register additional pieces of evidence (or "factors") to protect their identity, like a backup mobile number or a third-party app. End users commonly reuse passwords across multiple websites/services. If a malicious attacker discovers a password and compromises one service that belongs to a user, the attacker could use the same password to access other important services or resources that the user owns. MFA prevents the compromise of a user's ULM User ID in the event that their single factor (e.g. password) is compromised because even with the correct username and password, an attacker is stopped by the need for evidence that they cannot produce. If a user attempts password-based authentication from a new or unknown device, and there is one or more secondary factors registered with their Digital Identity Management User ID, then Digital Identity Management prompts the user to supply proof of their identity, using one of those factors, before the system proceeds. ## MFA Types **Digital Identity Management AuthN ID** – the user registers one of their verified Digital Identity Management authN IDs (i.e., email or mobile) as an MFA secondary factor using the [Register Email or Mobile as MFA](../../processGuide/topics/c_registerAuthnAsMFA) Process. If MFA is triggered during an authentication attempt, Digital Identity Management issues an [action token](https://docs.saas.amdocs.comvin/bundle/b_processGuide/page/topics/c_actionTokens.html) as a short form, custom One-time Passcode (OTP) and sends it to the external channel. The user then supplies that OTP to the client UI, and the client then passes the OTP back to Digital Identity Management in a [Process Step](../../processGuide/topics/c_processStep) request. | Redeeming the Digital Identity Management Action Token | | - | | As a general rule, Digital Identity Management action tokens are redeemed with the [Session Token](../../processGuide/topics/c_sessionToken) API, wherein the token value is provided in the API request URL. However, this scenario is an exception wherein the client application must instead provide the OTP (and PKAT) in the body of a Process Step [Process Step](../../processGuide/topics/c_processStep) request. | | **Authenticator App** – the user registers an [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238) compliant third-party authentication app to their Digital Identity Management User ID as an MFA secondary factor using the [Register Authenticator App as MFA Process](../../processGuide/topics/c_registerAuthnApp). If MFA is triggered, Digital Identity Management calls the Authenticator service, and the application then sends a Time-based OTP (TOTP) to the user. The user supplies that TOTP to the client UI that then passes the TOTP in a [Process Step](../../processGuide/topics/c_processStep) request. | For example, if an attacker discovers that an email address is the second factor, they may target the email account in order to gain access and retrieve MFA codes for verification. Conversely, mobile phones are more commonly the victim of an attack called "simjacking," wherein persistent attackers call the carrier's customer service line and pretend to be the user that they are attacking, in order to transfer service to a SIM card under the attacker's control. If successful, the attacker controls the victim's phone number and can receive MFA codes. **Note:** As a best practice, end users should be encouraged to leverage mobile authenticator apps. If an attacker discovers that MFA is in use, they may then target their attacks against the secondary factor itself. Authenticator apps are not subject to remotely operated attacks such as these; the apps can only be compromised by physical access to an unlocked device. Supported Authenticator Apps include any [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)-compliant app. Known apps include: * Google Authenticator * Microsoft Authenticator * LastPass Authenticator (LogMeIn, Inc.) * 1Password (AgileBits, Inc.) * Authy (Twilio, Inc.) ## MFA Trigger Criteria Digital Identity Management triggers MFA challenge when the following three conditions are met: * The active Digital Identity Management Process prompts the user to supply a password for authentication. * The user has at least one MFA secondary factor registered to their Digital Identity Management User ID. * The user is attempting to authenticate from an unknown device. Currently MFA support has been implemented with two specific Process-driven scenarios: * a user invokes the Authenticate User Process with their authN ID and password. * If the supplied credentials are valid, the Process prompts for MFA. * a user invokes the Onboard and Authenticate User with Social Account Process. The following conditions apply: * The Process calls the specified social provider. * The provider returns an email or mobile to Digital Identity Management. * Digital Identity Management discovers an existing Digital Identity Management User ID with the registered email or mobile. * The User ID does not have an association with the social account. * The Process prompts the user for their password to prove that they own this User ID. * If the supplied credentials are valid, the Process prompts for MFA. ## Trusting Devices When a Digital Identity Management Process prompts for an MFA check, it also allows the user to specify whether or not they want to **trust** the device. Trusting a device means that Digital Identity Management Processes will not prompt the user for a verification token on every subsequent authentication attempt from that particular device. End users may wish to "trust" devices which are always under their control (e.g. personal phones, laptops). Conversely, end users should not trust devices they do not always have access to or do not own (e.g. public computers). Below is an example of the MFA prompt from the Authenticate User Process: ``` **MFA Prompt** { "processId": "eec918ff-5db4-4fee-a601-5ff76a099c8e", "processName": "authentication.AuthenticateUser.v1.0", "stepName": "TwoFACodePrompt", "displayMessage": "Please input required information", "output": { "pkat": "babec3b7-96b5-47f4-b697-4683820d55af", "attemptsRemaining": 5 }, "parameters": { "code": "String", "pkat": "String", "trustedDevice": "Boolean" } } ``` The client UI should include a checkbox for the user to signify whether or not they want to trust the current device from which they are authenticating. If the user opts to trust the device, that relationship is then saved in Digital Identity Management as an attribute on the User-to-Runtime association. Digital Identity Management does not prompt for MFA during sign-in from trusted devices. End users may wish to "trust" devices which are always under their control (e.g. home set-top boxes or desktop computers). End users should not trust devices they do not always have access to or do not own (e.g. a friend's laptop). End users are free to revoke trust from devices at any time, should the trust be broken (e.g. the user selling their mobile phone to someone else, or on fears a device has been compromised). **Note:** End users who enable MFA on their profiles must be aware that, by recovering their profile, should they lose their password and/or second factor (e.g. if they receive verification codes by SMS, but their phone number changes), it may be more difficult to recover your account/access (depending on customer service policies). Organizations may not allow customer service agents to disable two-factor authentication on user profiles on behalf of a user, if that user has no way to prove their identity to the customer service agent. **Parent topic:**[User Authentication](../topics/c_userAuthentication) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.