Many integrations for 2FA support remembering 2FA sessions and this feature can be enabled by a request to help@uw.edu. We will work with you to evaluate if your integration supports 2FA, discuss the ramifications of supporting remembered devices, and determine what settings should be enabled.

By default, remembered sessions applies across applications that share the same duration. This means if application A and application B both use the standard 30 day session, a remembered session created while signing in to application A can meet the 2FA authentication on application B. There are limitations to this function. The requirements that factor into the remembered sessions (per device, per browser) applies and as such a remembered session to application A will not transfer to application B if it is a new environment. This function may not apply to integrations that experience further customization, including a different length of remembered sessions. Please reach out to help@uw.edu if you would like to except your application from this standard principal, or if you would like to take advantage of this (which would require also enabling remembered sessions).

The duration of a remembered session can be set to last hours or days, but we recommend the following "profiles" based on the security concerns of the system.

Standard security concerns

The majority of systems at the UW fall into this category. For most systems that require authentication, this is the assumed profile. A 30 day session is provided for remembering devices, but sessions are specific to the browser they were created on. If your application would like to enable "Remember Me", this is where we suggest starting the conversation when you reach out to help@uw.edu for a larger discussion about the requirements for authentication.

Extreme security concerns

For systems of this nature, supporting a remembered session is a non-starter. These systems should use a "Forced Authentication" model requiring that username, passwords, and all available methods of authentication. These systems may look to enable further restrictions to authentication or further steps to ensure authentication. If your application falls into this category, please reach out to help@uw.edu for a larger discussion about the requirements for authentication.

High security concerns

Systems that have significant security concerns can balance the added security of 2FA with the convenience of a remembered session. A one day session allows users to do a one time 2FA authentication at the start of the workday, and maintain the 2FA authentication as long as they continue to use that browser. If your application falls into this category, please reach out to help@uw.edu for a larger discussion about the requirements for authentication.

Moderate security concerns

Systems that have a higher sensitivity to security concerns than the standard but do not face significant concerns fall into this category. A 7 day session allows users to do 2FA authentication at the start of the work week, and maintain the 2FA authentication as long as they continue to use that browser. If your application falls into this category, please reach out to help@uw.edu for a larger discussion about the requirements for authentication.

Low security concerns

For some applications, the security concerns are simply that a user is in the UW ecosystem (has a UW NetID). We do not suggest requiring login with a personal UW NetID and password without also requesting 2FA the account. As such, a 60 day or greater remembered session may be appropriate. If your application falls into this category, please reach out to help@uw.edu for a larger discussion about the requirements for authentication.

No security concerns

Systems of this nature are generally considered "open" to the internet. Systems of this nature include public facing webpages and applications designed to be used by the general public. No 2FA is needed as no login occurs.

In the UW environment, there will be times that a user is asked to provide a "verified push" in place of anormal "push" authentication. More details about verified push can be found on duo.com. By default the UW uses a "3 digit" verified push. Verified push is a more secure form of push based authentication, and may be a good fit for applications looking to require only the high security methods. For applications that would like to require verified pushes in place of the standard push based authentication, please reach out to help@uw.edu to evaluate if the application can support this alteration.

Applications may wish to not support "less secure" authentication methods or otherwise limit what devices can be used for 2FA, which the UW may be able to support. Depending on your integration with the UW, you may be able to review and select from the authentication methods that are currently supported. To determine if your application is able to support this alteration, please reach out to help@uw.edu.

The UW does not plan on enabling support for "less secure" authentication methods. If your application would like to support an authentication method not currently provided, please reach out to help@uw.edu to start a conversation.

The UW has in place requirements to use 2FA on every sign, referred to as "2FA on the web". For the majority of users, they are automatically opted in as documented on Opt-in. In cases with a clear hardships for an individual, this opted in status can be removed. It is important to note that this type of exception only removes the 2FA requirement on every sign in, but does not address applications that require 2FA on sign in (and as a result will still request 2FA). This is not an option for those who wish to not be opted in, instead a user must fall into one of the following categories or share with UW-IT an undue hardship. Please email help@uw.edu if you have questions or believe an opt-out exception is needed.

Accessibility concerns

The UW uses Duo as it's 2FA vendor, which offers many features to ensure 2FA is as accessible as possible. For many users facing an accessibility challenge, there may be offerings for 2FA that will allow for the added security while reducing the added friction on login. UW-IT is happy to assist in determining what 2FA method will work best for you, and Duo's accessibility team has documented their support at https://duo.com/docs/accessibility. If an accessibility concern cannot be addressed by the current 2FA offerings, users may qualify for an opt-out exception.

Travel concerns

For those travelling outside of the united states 2FA may present a source of friction for logins. In most cases, preparing for your trip can be as simple as ensuring you have a device with you that has the Duo app installed successfully (as it can provide 2FA authentication even when you are out of cell service off wifi). More information can be found on the IT Connect page offering 2FA resources for travel. For these cases, opt-out exceptions are not granted. However, 2FA is not available in OFAC restricted regions as noted on Duo and UW's 2FA resources for travel. If your travel plans will take you to such a region and will need to log in to UW resources, please reach out to help@uw.edu before your travel for a potential out-out exception.

Test Users and Automation

2FA can present a barrier to "not real" UW NetIDs like those used in testing or automation. We strongly suggest wherever possible utilizing a shared UW NetID in place of a personal UW NetID as shared UW NetIDs are not required to do 2FA on a standard login. This also has the added benefit of allowing your test cases and automation "live longer" as they can be used by another personal UW NetID in case you pass the responsibility on to someone else. However, some systems require 2FA from all logins including a shared UW NetID. Other times a test account must be a personal UW NetID and needs to appear as a real user (including the need to do 2FA). In those cases, bypassing 2FA requirements or enabling bypass options can be reviewed and if applicable offered. Please reach out ot help@uw.edu to start a conversation if you need this exception.

In some cases specific devices can have external factors that make 2FA a block for use of the device. Users of the device should not face hardship outside of the specific device, and the device is critical to UW business. If this is the case, a network based exception may be appropriate. Network based exceptions allows for specific network traffic to bypass the 2FA step for any user on that device, while still requiring that those users do 2FA generally on all logins. This is especially beneficial in highly controlled environments such as clean rooms or sensitive laboratories. Because of the nature of a network based exception removing the 2FA requirement for any and all users who access this device, network based exceptions are only issued in extremely specific circumstances. In order to meet the policy requirements for this exception, a use case needs to be shared with UW-IT via help@uw.edu that captures:

• A strong, documented business justification that has already explored other alternative solutions
• A secure, well understood environment in which the device is to be located and accessed
• A secure, well managed device that is regularly maintained and audited
• Agreement to a high standard of notification and involvement with UW-IT to issue and maintain this exception