Enterprise Deployment Strategies for Multi-Factor Authentication

Background

The introduction of multi-factor authentication (MFA) into an institution must address multiple issues, many of which affect the deployment strategy. Among these are:

• Business drivers. MFA may be deployed to address risk associated with one or more services, for compliance with with policy or legal requirements, or as a security option for members of the institution.
• Acceptance by the user community. MFA may be viewed by the community as yet another straw on the camel's back, or it can be viewed as the result of a necessary and thoughtful process.
• Usability and Accessibility. Solutions should be appropriately usable and accessible.
• Management of risk in the deployment process. The deployment's scope, in terms of services and users, can affect its chances of success.
• Ongoing management of institutional risk. Once MFA is operational, it is subject to audit and other management controls.
• Future uses of multi-factor authentication. Known and potential future uses of MFA within the institution.
• Future-proofing the institution's use of multi-factor authentication. Technology must be refreshed. This is particularly true of authentication technologies, as threats become more effective over time.
• Resource allocation. The resources allocated for the deployment of MFA may be assigned to the central IT organization, or they may be assigned to a business unit with responsibility for specific systems.

This paper discusses a few possible deployment strategies and how they address these issues.  A visual flowchart representation of this issue is available at MFA Business Drivers, Deployment Decision Tree and Integration Patterns.

Analysis of Deployment Strategies

Deploy for One or a Small Number of Individual Services

MFA is integrated into a small number of services and introduced only to the users of those services.  No other services are affected.

• Pros
  • Since requirements for MFA tend to be identified first for individual services, this strategy is likely to align well with business drivers and resource allocation.
  • The scope is well contained, limiting risk in the deployment process.
  • Acceptance by users tends to be high, as they have a greater understanding of the risks associated with the service.
  • Usability can be high, as integration can be customized to the service
  • This may be the only option for some services, particularly those that are not web-based.
• Cons
  • This strategy does not facilitate ongoing audit and other management controls, as each service must be assessed separately.
  • This strategy may experience higher per-user costs to address accessibility concerns, particularly when multiple MFA solutions must be deployed to address those concerns.
  • This strategy does not facilitate future uses of MFA as each new service requires a new integration.
  • This strategy does not provide effective future-proofing, as a technology refresh requires re-integration for each service.

Deploy into the Enterprise SSO but Use for One or a Small Number of Services Initially

MFA is integrated into the enterprise single sign-on (SSO) system (e.g., Shibboleth or CAS), making it available potentially for all services, but use it initially only for a small number of services.

• Pros
  • Since requirements for MFA tend to be identified first for individual services, this strategy is likely to align well with business drivers.
  • The scope is well contained, limiting risk in the deployment process.  However, the scope must include the SSO, as well as the initial services.
  • Acceptance by users tends to be high, as they have a greater understanding of the risks associated with the service.
  • Usability can be high, as integration can be customized to the SSO.
  • By containing all authentication in the SSO, audit and management controls are facilitated.
  • Because of the larger user community, per-user costs to address accessibility can be controlled.
  • Future uses of MFA are facilitated, particularly when the future MFA services are already integrated with the SSO.
  • Future-proofing is enhanced, as integration of new MFA technologies is done in only one place, the SSO.
• Cons
  • This strategy may not align well with resource allocation when the initial services and the SSO are operated by different parts of the institution.
  • The deployment scope must include the SSO, as well as the initial services.

Deploy into the Enterprise SSO as an Option for End Users

MFA is integrated into the enterprise single sign-on system as an option for end users to enhance their security and privacy.

• Pros
  • The strategy aligns well with business drivers and resource allocation (assuming providing the end user option is an objective of the institution).
  • No services are affected, limiting risk in the deployment process.
  • Acceptance by users is high, as it is used only by people who want it.
  • Usability and accessibility can be high, as there are no other constraints than addressing end user concerns.
  • The scope of audit and management controls is limited to end user concerns.
  • The cost of accessibility may be lower, as use of MFA is not an institutional requirement.
  • Future-proofing is enhanced, as integration of new MFA technologies is done in only one place, the SSO.
• Cons
  • Future uses of MFA may not be facilitated.  The technology will be in place, but policies and business processes for service-required MFA may not.

Deploy into the Enterprise SSO as a Requirement for Specific End Users or Roles

MFA is integrated into the enterprise single sign-on system as a requirement for users who perform high-risk transactions.

• Pros
  • The strategy aligns well with business drivers and resource allocation.
  • No services are affected, limiting risk in the deployment process.
  • Acceptance by users can be high, assuming that the users' needs and desires are met.
  • Usability can be high, as integration can be customized to the SSO.
  • The scope of audit and management controls is limited to specific users.
  • The cost of accessibility may be lower, as the user community is constrained..
  • Future-proofing is enhanced, as integration of new MFA technologies is done in only one place, the SSO.
• Cons
  • Future uses of MFA may not be facilitated.  The technology will be in place, but policies and business processes for service-required MFA may not.

Defer Enterprise-Wide Strategy, Allowing Departments to Lead Innovation for MFA

• Pros
  • The strategy aligns well with departmental business drivers and resource allocation.
  • The scope is limited to individual departments, limiting risk in the deployment process.
  • Acceptance by users tends to be high, due to the stronger sense of community within a department.
  • Usability and accessibility can be high than a deployment for the full enterprise, as the user community is smaller.
• Cons
  • This strategy may not align well with enterprise-wide business drivers and resource allocation.  It may also increase the difficulty of achieving enterprise-wide alignment in the future.
  • This strategy does not facilitate ongoing audit and other management controls, as each department must be assessed separately.
  • This strategy may experience higher per-user costs to address accessibility concerns, particularly when multiple MFA solutions must be deployed in each department to address those concerns.
  • This strategy does not facilitate future uses of MFA in other departments.