Expanded use of 2FA on the web

No, required use of 2FA will be phased in (per the schedule below).

Summary:

On June 15, 2022, all faculty are required to use 2FA on the web.

Schedule history:

• Summer 2022
  • June 15, 2022 — all faculty are required to use 2FA on the web.
• Summer 2021
  • June 28, 2021 — UW Bothell requires 2FA for its faculty
• Summer 2020
  • July 1, 2020 — opt-in option is available to faculty

Summary:

All students are required to use 2FA on the web.

Schedule history:

• 2022
  • November 21 — All students are required to use 2FA on the web.
• Summer 2020
  • July 8, 2020 — all students eligible to use Duo
  • July 1, 2020 — opt-in option is available to students

Note: students with appointments as staff are included in the required date for all staff.

Summary:

As of August 31, 2021, all staff (not in UW Medicine) are required to use 2FA on the web.

No target required date has been established for contingent workers.

Note: UW Medicine will assess the impact and implementation plan for 2FA.

Schedule history:

• Summer 2021
  • August 31, 2021 — all staff are required to use 2FA, except for UW Medicine workforce members
• Spring 2021
  • May 3, 2021 — additional units require 2FA for some or all members
    • UW Student Life requires 2FA for its staff
    • UW Graduate School requires 2FA for its staff
    • College of Arts & Sciences requires 2FA for its staff
    • iSchool (Information School) requires 2FA for its staff
• Winter 2021
  • March 1, 2021 — central admin and other units require 2FA
    • UW Facilities requires 2FA for its members
    • UW Finance requires 2FA for its members
    • UW Human Resources requires 2FA for its members
    • Office of Planning & Budgeting requires 2FA for its members
    • Office of the President requires 2FA for its members
    • UW Bothell requires 2FA for its staff
    • UW Tacoma requires 2FA for key staff
  • January 12, 2021 — Message About Phishing and W-2 Forms (annual message to all UW student employees, faculty and staff) recommends opt in to 2FA
• Summer/Autumn 2020
  • December 10, 2020 — UW Information Technology requires 2FA for its members
  • October 20, 2020 — Secure University Data 2020 (annual message to all UW students, faculty and staff ) recommends opt in to 2FA
  • July 1, 2020 — opt-in option is available to employees; individuals begin to opt in

Yes, the opt in to 2FA option on Identity.UW enables voluntary early adoption of 2FA before it’s required. There is no self-service way to opt out after someone has opted in, because it is a proactive step toward required use of 2FA.

Yes, others can opt in early, but only if they are eligible to use 2FA. Refer to the schedule (above) for dates when various populations of people can opt in.

No, there is no self-service option to opt out because early adoption is a proactive step toward required use of 2FA in the future. To ensure people understand they can’t opt out, the opt-in option on Identity.UW asks users to confirm their decision to opt in. If someone’s decision to opt in early creates an undue hardship, they can contact UW-IT for assistance.

Individuals are encouraged to opt in to use 2FA before it is required. To do so, they must be eligible to use 2FA and set up at least one 2FA device.

System owners can already require 2FA by adding 2FA to their IT system via an integration with UW-IT’s UW NetID and authentication infrastructure.

The UW is expanding the use of 2FA to better protect personal and institutional data from threats to passwords, such as phishing scams, reuse of passwords, and other ways passwords are compromised. By expanding the use of 2FA, the UW reduces the likelihood that compromised passwords can be used to gain unauthorized access to systems and data.

2FA is an information security best practice that reduces the likelihood that bad actors can use a compromised password to access protected resources. 2FA requires use of a device, like a smartphone, in addition to a password. Therefore, bad actors must obtain access to the 2FA device in addition to a password to gain unauthorized access to resources protected by 2FA.

2FA reduces the impact that compromised passwords have on individuals and the UW. When a password is compromised (or there is reason to believe it might have been) the UW handles it as a security incident and the UW NetID is suspended. This can be surprising and distressing to the authorized user of the UW NetID because it disrupts their access to services until they can safely recover control of their account. At the same time, the UW must help individuals through the account suspension and recovery process, even while staff manage the security incident, investigate potential system and data breaches, and deliver necessary data breach notifications.

In higher education, institution-wide deployments are common, including at many peer institutions. Learn more about the deployments at University of Michigan, Berkeley, Stanford, UCLA, Indiana University, Penn St, and Utah. Other organizations outside of higher education that promote 2FA as a best current practice include the National Institute of Standards and Technology, Login.gov, Internet Society, as well as Amazon, Apple, Microsoft, GitHub, FaceBook, and Twitch.

Today 2FA is integrated one UW system at a time. Workday, GradePage, and ASTRA are examples of web-based systems that integrate and use 2FA. Non-web systems that use 2FA include interactive logins to many Linux systems, the Hyak research cluster, as well as administrative services hosted on the Keynes server. Many other systems also use 2FA.

Today 2FA is used when a system owner adds it to their information security plan. Decisions to do so depend on risk and compliance needs, use of web or non-web platforms, capabilities of each system, affiliations and size of system user populations, and the 2FA integration options provided by UW-IT.

When expanded use of 2FA is complete, 2FA will be the default when signing in with UW NetID on the web, regardless of what service or website is being accessed. In particular, any service that integrates with and relies on UW-IT’s SSO infrastructure will require 2FA. For example, when the transition is complete, 2FA will be required by default when signing in with UW NetID to access Canvas, Student Personal Services, UW Google, Outlook Web App, Zoom, and hundreds of other services.

The web is a set of open standards and Internet technologies that enables access to resources using everyday web browsers and other compatible software. The web is the primary technology platform used to deliver secure, usable, accessible IT services at the UW, and arguably across the world. By focusing the expansion of 2FA on the web, the UW can protect more systems and data, more quickly and cost-effectively, than adding 2FA to various non-web platforms (which sometimes use the web for user authentication because it’s standardized and web browsers are ubiquitous). This also strategically positions the UW to take advantage of future standards and emerging technologies built on or for the web.

Focusing on the web doesn’t preclude efforts to integrate 2FA into systems on non-web platforms, nor does it preclude efforts to redesign and transition non-web systems to use the web. Currently, some non-web system owners have added 2FA to their IT systems by integrating with UW-IT’s UW NetID and authentication infrastructure.

2FA has become an information security best practice for signing in to online accounts with access to personal or institutional data. Since UW NetIDs are used across the UW community, making them more resilient to threats to passwords makes the entire UW community safer and protects more data, across more systems, more quickly and cost-effectively, than adding 2FA to UW systems one at a time.

Personal UW NetIDs will transition from voluntary opt-in to required use of 2FA in phases based on the affiliation(s) of individual members of the UW community: employees first, then other affiliations, including faculty, students,  research collaborators, alumni, donors, and applicants, as well as the “long tail” of loosely affiliated people whose accounts were created through the Personal UW NetID sponsorship process. Each phase will also involve expanding Duo eligibility, or implementation of other 2FA methods for some affiliations.

Admin UW NetIDs will transition to required use of 2FA in the same overall phase as the Personal UW NetIDs of employees. Note that Admin UW NetIDs are only available for use by employees (and authorized exceptions). They are linked to an employee’s Personal UW NetID, such that they can use the same 2FA devices for both accounts. That is, after an employee sets up a 2FA device, they can use it for 2FA with either their Personal UW NetID or Admin UW NetID(s).

Shared UW NetIDs will be handled separate from other types of UW NetIDs, and they may involve different approaches to risk reduction than accounts used by individuals. Further analysis of Shared UW NetIDs will be completed during a later phase of the initiative. Please contact us if you or your organization have use cases involving use of 2FA with Shared UW NetIDs. We’d like to hear about them earlier in the initiative.

Currently, Clinical Shared UW NetIDs will be included in the same analysis of Shared UW NetIDs. If needs diverge, they will be handled separately.

Other types of UW NetIDs including Temporary UW NetIDs, Application UW NetIDs, and Reserved UW NetIDs will be handled separately, and may involve different approaches to risk reduction.

The initiative will help to promote current best practices for 2FA. Through communications and updated articles on IT Connect, the community will learn tips and recommendations for topics such as:

• enrolling device(s)
• recommended 2FA options
• recommended use while traveling
• recommended use of the “remember me” option on trusted devices

The Duo Mobile application for smartphones and tablets will continue to be the recommended 2FA device for employees, students, and others eligible to use Duo. For individuals who cannot use Duo Mobile physical tokens are provided by UW-IT.

The initiative makes 2FA a routine part of signing in with UW NetID on the web, so the frequency will increase. However, to reduce how often individuals must confirm their identity using their 2FA device, the default 12-hour single sign-on (SSO) duration applies to 2FA on each browser session, with the option to extended it to 30 days using the “remember me” option on trusted computers. Additionally, applications that rely on Microsoft and Google sign-in processes for UW NetID also help reduce 2FA sign-in frequency.

Customers with systems that rely on UW-IT’s SSO infrastructure are the primary focus of the initiative, with some key differences for current and future customers. In general, current customers and their integrations won’t be impacted by the initiative, although customers may need to consider changes to align with current best practices. Future customers (and those planning changes to their integrations of 2FA on the web) should adjust their IT service strategies to align with expanded use of 2FA. To learn more, including current best practices for integrations, refer to add 2FA to your IT system.

Customers who require use of 2FA when signing in to Linux systems such as Hyak won’t be impacted by the expanded use of 2FA on the web. The initiative’s phased approach to expanding 2FA eligibility may help Linux system owners onboard new users (such as students and research collaborators), and updates to current best practices may influence what authentication methods are used.

Administrative services hosted on the Keynes server (keynes.u.washington.edu) aren’t impacted by the initiative to expand the use of 2FA on the web. However, updates to current best practices for 2FA may influence its use on Keynes.

Husky OnNet and Husky OnNet – Department  (HON-D) rely on UW-IT’s SSO infrastructure and will be part of the initiative’s phased approach to opt-in and required use of 2FA. Current HON-D customers who already use 2FA on their instances of HON-D may benefit from the initiative’s phased approach to expanding 2FA eligibility, and updates to current best practices may influence what authentication methods are used.

Customers who have integrated Duo on departmental systems on platforms other than the web generally won’t be impacted by the expansion of 2FA on the web. The initiative’s phased approach to expanding 2FA eligibility may help departmental system owners onboard new users, and updates to current best practices may influence what authentication methods are used.

UW Canvas integrates with UW-IT’s SSO infrastructure for sign-in on the web, and therefore the initiative’s phased approach to opt-in and required use of 2FA will apply to UW Canvas. In turn, expanded use of 2FA will also apply to third-party tools that rely on LTI (Learning Tools Interoperability) integrations with UW Canvas for sign-in on the web.

UW Office 365 supports authentication via modern web methods, as well as “legacy” authentication methods that Microsoft is in the process of retiring. The initiative to expand the use of 2FA on the web will add 2FA only to web browser interactions with UW Office 365. It won’t apply 2FA to the legacy non-web authentication methods; learn more about what it doesn’t cover in the Microsoft cloud. In parallel with the initiative, UW-IT will be working with customers to retire use of legacy authentication for accessing UW Office 365.

UW Google supports authentication via modern web methods, as well as “less secure app access” that Google is in the process of retiring. The initiative to expand the use of 2FA on the web will add 2FA only to web browser interactions with UW Google. It won’t eliminate “less secure app access”. However, in parallel with the initiative, UW-IT will be working with customers to retire the use of Google’s “less secure app access” to UW Google.

CILogon, Globus, NIH electronic Research Administration (eRA) Commons, and other research infrastructure that relies on UW-IT’s SSO infrastructure will be part of the initiative’s phased approach to opt-in and required use of 2FA. Research collaborations that rely on the REFEDS MFA Profile shouldn’t be impacted by the initiative.

The initiative will add 2FA only to web browser interactions with the Microsoft cloud, including UW Office 365, Microsoft Azure, and other applications integrated with UW Azure Active Directory. These services are in scope because they can be accessed via UW NetID accounts managed by the UW for use in the Microsoft cloud. When users sign in to one of these accounts using a web browser, the Microsoft sign-in process authenticates the user through an integration with UW-IT’s SSO infrastructure. Therefore, the initiative and its phased approach will apply 2FA to use of the Microsoft sign-in process on the web. Non-web sign-in is not impacted because the initiative applies only to UW NetID sign-in on the web; learn more about what it doesn’t cover in the Microsoft cloud. 

The initiative will add 2FA only to web browser interactions with the Google cloud, including UW Google and Google Cloud Platform (GCP). These services are in scope because they can be accessed via UW NetID accounts managed by the UW for use in the Google cloud. When users sign in to one of these accounts using a web browser, the Google sign-in process authenticates the user through an integration with UW-IT’s SSO infrastructure. Therefore, the initiative and its phased approach will apply 2FA to use of the Google sign-in process on the web. Non-web sign-in is not impacted because the initiative applies only to UW NetID sign-in on the web.

The initiative will add 2FA only to web browser interactions with the Amazon cloud, and only where customers have integrated it with UW-IT’s SSO infrastructure. By default, the Amazon cloud, including Amazon Web Services (AWS), doesn’t rely on UW-IT’s SSO infrastructure, and the only Amazon accounts linked to the UW are those managed by customers who have added integrations with UW-IT’s SSO infrastructure. Therefore, the initiative and its phrased approach will apply 2FA only to those integrations.