...
- Implementors must work to ensure that the different factors used in the authentication process are independent, meaning that gaining access to one factor must not trivially grant access to the other factor.
- Any factor that is directly accessible using the first factor is no more secure than the single factor by itself, and so is NOT considered a second factor.
- Institutions are expected to provide safeguards to maintain the independence of their supported authentication factor.
- a software/virtual phone that is authenticated using the enterprise password is not an appropriate second factor.
- The MFA profile does not enumerate specific requirements the institution must meet to protect against these forms of authentication dependence, but technical restrictions (where feasible) and user education are highly recommended to mitigate the risks of users deploying factors in a manner that decreases their independence.
- Processes that allow a user to immediately register a new second factor (re-registration) using only their “first factor” enterprise password are no more secure than use of the enterprise password itself.
- Implementors are expected to require greater scrutiny before allowing registration of replacement or additional second factors to prevent attackers with password access from simply registering and immediately using a new second factor. However, the MFA profile does not provide any specific requirements on such registrations.
Note that it is common practice to allow the initial registration of a second factor using only the existing factor, and the MFA profile does not restrict this initial MFA factor registration practiceAdditional second factors can use a existing second factor when registered or the same method as the first second factor.
How Does the MFA Profile relate to (level) of assurance profiles?
...