Original Issuance Date: September 14, 2016
Last Revision Date: March 2, 2022
1. Purpose of Procedures
This document describes the minimum authentication standards that must be met by University of Wisconsin (UW) System institutions.
2. Responsible UW System Officer
Associate Vice President for Information Security
Please see SYS 1000, Information Security: General Terms and Definitions, for a list of general terms and definitions. Terms and definitions found within this policy include:
- Account Types
- Multi-Factor Authentication (MFA)
1. Minimum Password and Passphrase Requirements
For authentication systems that use passwords or passphrases as an authenticator type, the following password and passphrase length requirements represent a minimum standard for UW System accounts. System password and passphrase requirements must also meet or exceed all applicable federal statutes and administrative code, and other applicable industry standards, such as Payment Card Industry Data Security Standards, that apply to those systems.
|Account Type*||Length Requirements|
|All Accounts (Minimum Baseline)||12|
|Privileged Accounts and accounts with access to high risk data||14|
|Non-interactive/Connector Accounts (Service Accounts)||16|
* Note that whether an account is classified as a user account or a shared account does not affect password and passphrase length requirements.
Additionally, passwords and passphrases must:
- Not contain the accounts username or other account identifier;
- Be compared against a dictionary of weak or known passwords, if such functionality natively exists in the authentication system; and
- Enforce history requirements, such that secrets associated with accounts must not be the same as any of the last 24 secrets for that account
2. session reauthentication
Periodic reauthentication of sessions must be performed at various time intervals in additional to elapsed periods of user inactivity. Users accessing moderate or high risk data must reauthenticate to the application hosting the data at least one per 12 hours during an extended usage session, regardless of user activity. Reauthentication procedures must be commensurate with the initial authentication process used to access the application.
Users must also reauthenticate following any period of inactivity lasting 30 minutes or longer with accessing moderate or high-risk data.
The session must be terminated (i.e., logged out) when either of these time limits are reached.
3. Account Lockout Requirements
Public facing authentication systems, those of which allow for authentication from outside of institution networks, must include an account lockout mechanism to be triggered after a maximum of 14 invalid password entries. Administrators may choose to have a time-based lockout (minimum 5 minutes) or a hard lockout which requires the user to follow a process to reset their secret. Alternatively, risk-based or adaptive authentication techniques may be used to identify user behavior that falls within, or out of, typical norms, and enforce lockouts accordingly.
4. Multifactor Authentication
User accounts and shared accounts that are used to access high risk data must use MFA. This requirement does not apply when students are exclusively accessing their own information.
Privileged accounts, excluding service accounts, must also use MFA.
5. Frequency of Password and Passphrase Changes
When MFA is not incorporated into all internet-facing instances when an account is used, passwords and passphrases must be changed on a regular basis, in accordance with the following:
|Account Type||Password Change Frequency|
|Non-Interactive/Connector Account (Service Account)||5 Years|
|All Other Accounts*||Annually|
Passwords and passphrases must be changed immediately if a compromise of credentials has been independently discovered, publicly disclosed, suspected, or if a device has been lost or stolen. This includes discovery of plaintext and/or hashed secrets.
Initial secrets that are provisioned for new user accounts must be changed during first use or, if not technically feasible, within five business days of first use.
Default, non-unique passwords for accounts that are embedded in new devices or applications must be changed during the initial device or application configuration, or if not technically feasible, within five business days of device or application activation, unless those accounts are locked.
Service account secrets and shared account secrets must be changed within five business day s when an employee with knowledge of said secrets:
- changes roles where knowledge of the secret is no longer necessary; or
- discontinues employment with the UW System and/or its institutions. This requirement does not apply for systems that are inaccessible form outside the institution network.
6. Shared Accounts
Shared accounts should not be used to access high risk data and should be avoided when accessing moderate risk data. If, due to system limitations or problems, a shared account must be used, the institution must establish procedures for documenting, approving, and monitoring the use of shared accounts.
7. Requirements for Continued Account Access
Accounts must only remain active while there is a valid business justification for having the account. However, there may be times where accounts need to remain active past their normal defined periods:
- Individuals who leave employment in good standing and retain a documented affiliation with the university (emeriti, sponsorship, retiree/annuitant, adjunct faculty, instructional staff/faculty, etc) may retain account access provided the following conditions are met:
- An individual’s affiliation must be formally documented and verified at least once every 365 calendar days
- Individuals retain access to campus IT resources/services, limited to those commensurate with their role
- Individuals remain subject to Board of Regents rules
- Individuals are required to annually complete information security awareness training
- Access will be disabled after 1 year of inactivity based on last login date
- Access for individuals who leave employment in good standing and do not retain a documented affiliation with the University, will be disabled on the termination date set in the Human Resource System. Access for these individuals may be retained for a period of up to 90 days to facilitate grade appeal process, if applicable.
- Access for individuals who are discharged with no notice and/or terminated for cause must be revoked immediately. If a criminal offense is involved in the termination, the UW System Office of General Counsel or an institution’s legal affairs office must be consulted to ensure no legal hold on account information, files, etc. is required.
8. Storage of User Passwords and Passphrases
Chief Information Officers (CIO) or their designee may approve the use of password managers or software applications designed to manage user secrets securely. Password managers must meet the following minimum security requirements:
- Password managers shared between team members must utilize logging to uniquely identify employee access to the manager and access of passwords within the manager
- Password manager authentication procedures must be commensurate with the authentication requirements for the accounts the password stores. For example, if the password manager will store privileged account credentials or credentials for accounts that have access to high risk data, the password manager must require MFA and meet the associated secret requirements specified in this policy.
Secrets must be encrypted when stored electronically. Secrets must not be written down unless secured in a manner that restricts unauthorized individuals from accessing the secrets.
5. Related Documents
Regent Policy Document 25-5, Information Technology: Information Security
UW System Administrative Policy 1030, Information Security: Authentication
UW System Administrative Policy 1031, Information Security: Data Classification and Protection
NIST Special Publications 800-53 and 800-63
UW System Information Security Program
Revision 6: March 2, 2022
Revision 5: November 13, 2020
Revision 4: October 4, 2019
Revision 3: January 09, 2019
Revision 2: January 25, 2018
Revision 1: July 31, 2017
First Approved: September 14, 2016