When you're choosing authentication factor(s) as part of an MFA system, a "one size fits all" approach just doesn't work. Organizations must balance usability, cost and security in order to provide the right amount of security without impacting the user experience, which could alienate their user base.
But how do you choose the right step-up MFA mechanism for your particular environment? You might want to consider these variables when making your choices:
Strength: How many false positives? How many false negatives? What are the security risks? What attacks are you trying to prevent? Is it password compromise or insider threat?
IT benefits: Is the authentication method easy to deploy? Will it require additional IT resources? Can it work across multiple channels (e.g., online, telephony, etc.)?
Usability: Customer adoption goes up if you provide multiple options for authentication. But are the mechanisms easy to use? Will end users accept the new process? Can users be expected to have a device capable of supporting a particular mechanism? Will users be concerned about privacy? If a user chooses not to opt-in to a particular mechanism (perhaps because of disability), is there a fallback?
As an example from the consumer world, Google supports a number of different MFA mechanisms--everything from text messages and phone calls to security keys and verification codes. These mechanisms account for different preferences and constraints of their users, but they also serve as backup when the primary mode is unavailable.
For a consumer mobile app, MFA capabilities should be integrated with any existing native application, rather than requiring the customer to download a separate authentication application. For example, Twitter app users can turn on what's called a "two-step verification" from within the app, and they're prompted to approve certain operations--for example, signing on to their account from a previously unknown machine.
Industry-specific benefits: Are there aspects of the mechanism that make it better suited for certain industries or functional areas? For example, if employees have to wear gloves to do their jobs, fingerprint-based biometrics may not be the best choice.
Initial purchase cost: Is there a cost per user that will grow each time a new user is added? What are replacement costs, both for physical devices and associated administrative processes?
Deployment cost: How much will it cost to deploy the authentication mechanism? Is client software or hardware required? If so, how is that distributed to customers and what are the costs of doing so? Is the registration process self-serve?
Some may argue that hardware tokens provide better security than mobile-based soft token models, but the associated higher costs and poor usability makes them less acceptable.
We've argued that the optimal mix of cost-effectiveness, security and usability for an MFA system is best achieved through a combination of explicit and overt sign-on mechanisms with implicit and passive contextual mechanisms. The decision of when to rely on invisible contextual factors and when to require one or more of the explicit mechanisms should be based on a risk assessment. A risk-based model ensures that the user is confronted with explicit authentication UX only when necessary, with passive contextual authentication becoming more and more the default.