UNIVERSITY STANDARD STATEMENT
This standard establishes expectations for identification, authentication, and access control for university accounts.
REASON FOR STANDARD
The Identity and Access Management (IAM) Standard is critical to ensuring that the right people and job roles can access the tools needed to do their jobs while preventing unauthorized access to university systems and data. It helps provide greater control of user access by identifying, authenticating, and authorizing users, as well as prohibiting unauthorized users.听
In certain circumstances, laws and regulations may apply and call out specific IAM requirements that are more restrictive than what is defined here. In those cases, the requirements listed in the laws and regulations will supersede those in this standard.
The Office of Cybersecurity will review this standard biennially with feedback collected from representatives across VU to understand new concerns and dynamic requirements to best serve the VU community and adhere to VU Information Security Principles listed in the Information Security Policy.
SCOPE AND AUDIENCE
This standard applies to the entire 国产原创 community including, but not limited to, faculty, staff, students, contractors, post-doctoral fellows, temporary employees, and volunteers (collectively called 鈥淰U Community Members鈥�). In instances where institutional data is shared with other parties, this standard extends to the custodians of the shared data. (e.g. Oracle Cloud, VUMC).
听
DEFINITIONS
STANDARD
A. IDENTIFICATION
All accounts must be in a VUIT central directory (e.g., Active Directory or Lightweight Directory Access Protocol) by default, where technically feasible. Account identifiers (e.g., VUNet ID) must be individually unique and cannot be recycled or reused.
The primary types of accounts at the university are:
- Standard User Account - An individual user account that identifies a specific person. This account is federated and allows a user to logon to multiple IT assets with the same account and password. A common example is a VUnet ID.
- Alumni Account - An individual faculty member that has retired or student that has graduated from 国产原创.
- Privileged User Account - An account that has elevated privileges beyond that of a standard user to provide administrative or specialized levels of access. Typically, it allows IT administrators to manage software or hardware. An example is a Three Letter Account (TLA).
- Temporary/Affiliate User Account - An individual user account for guests, contractors, or other individuals that have a business or academic relationship with the university but are not employees. It could also include an emergency account created on a temporary basis for testing purposes or to remediate an imminent threat to the university. These accounts require sponsorship from a 国产原创 paid employee.
- Resource/Service Account - An account that is not associated to a person but is used by a process to allow a system or application to run services unattended. These accounts must only be used by one system or application. Client credentials stored within cloud or vendor systems (e.g. Entra ID, Oracle Cloud) used to access APIs or other provided services are classified as resource/service accounts. These accounts require a sponsor.
- Local Account - An account that is specific to a single IT asset or account created and managed via a 3rd party application. This account is stored locally on the asset鈥檚 hard drive, is not federated, and allows an individual user to logon to a computer, application, or service.
- Shared Account - A single account and password that multiple individuals co-use. These accounts cannot be linked to an individual person or process and lack accountability. These accounts require an exception from Cybersecurity.
If an account matches the description for multiple account types, it should follow the most restrictive criteria for both.
Account lifecycle requirements are listed in the table below:
Table 1. Account Lifecycle Requirements
| Type | Example | Create | Review | Disable | Delete |
| Standard | Staff | Upon hire | Annual | 24 hours after separation | 30 days after disable |
| Faculty | Upon hire or invite | Annual | 4 months after separation | 30 days after disable | |
| Undergraduate student | Upon invite or matriculation | Annual | 4 months after graduation | 30 days after disable1 | |
| Graduate student | Upon invite or matriculation | Annual | 12 months after separation or graduation | 30 days after disable1 | |
| Professional student | Upon invite or matriculation | Annual | 12 months after separation or graduation | 30 days after disable1 | |
| Alumni | Emeritus faculty | Upon disablement of standard account | N/A | N/A2 | N/A2 |
| Temporary/Affiliate | Guest | After VU sponsor approval | 6 months | Immediately upon pre-defined date | 30 days after disable |
| Contractor | After VU sponsor approval | 6 months | Immediately upon pre-defined date | 30 days after disable | |
| VUMC Faculty | Upon appointment and request via invite | Annual | Immediately upon end of appointment | 30 days after disable | |
| Privileged | TLA | After written supervisor approval | 6 months | Immediately after standard account disablement or within 48 hours of role change | 30 days after disable |
| Tier 0 | After written supervisor approval | 6 months | Immediately after standard account disablement or within 48 hours of role change | 30 days after disable | |
| Resource/Service | API automation | After administrator approval | Annual | 24 hours after notification | 30 days after disable |
| System to system | After administrator approval | Annual | 24 hours after notification | 30 days after disable | |
| Local | Default | After IT asset owner approval | Annual | 24 hours after notification | 30 days after disable |
| Vendor-specific | After IT asset owner approval | Annual | 24 hours after notification | 30 days after disable | |
| Shared | Not allowed without an exception and with the password stored in a secure password vault (e.g., PAM). If an exception is granted, lifecycle requirements shall follow the appropriate account type above. | ||||
[1] Account deletion does not necessarily eliminate an individual鈥檚 record. See FAQs below.听
[2] University alumni, such as emeritus and postgraduates, may retain perpetual limited application access as defined by the business (e.g., email, Library, YES, AlumnIQ).
In support of security investigations and/or legal proceedings (e.g., litigation hold), an account may be retained beyond the timeframes outlined above.
B. AUTHENTICATION
- University passwords must maintain a minimum complexity:
- 3 of 4 characters must be used:
- Upper Case (ABCD...)
- Lower Case (abcd...)
- Number (1234...)
- Special Character (!@#$鈥�)
- Length and expiration/renewal must align with the following:
- 3 of 4 characters must be used:
| Account Type | Minimum Length | Expiration |
| Standard | 12 | Annual |
| Privileged | 12 | 6 months (Unless managed by PAM,3) |
| Temporary/Affiliate | 12 | Annual |
| Resource/Service | 32 | 2 years or upon departure of an individual with knowledge of it |
| Local | 16 | 6 months (Unless managed by PAM or LAPS) |
| Shared | N/A | |
[3] Privileged Account Management (PAM)
- Passwords must never be shared and cannot be reused with other non-affiliated accounts (e.g., personal accounts).
- Passwords must be encrypted when stored and when transmitted over any network according to the Encryption Standard.
- Passwords must be obscured during the logon process and are never permitted to be coded into programs or queries in clear text.
- If an IT Asset has a vendor supplied, default password, the IT Asset Owner must change it immediately.听
- Accounts cannot reuse any of the past 10 passwords and cannot include 3 consecutive characters from a username.听
- Accounts will be granted no more than 5 failed login attempts, with a lockout of at least 5 minutes.
- Passwords for Resource/Service accounts should be randomly generated and stored in a password manager.
- Authentication methods must utilize modern protocols by default. Legacy or Basic authentication is not allowed.
- Where available and technically feasible, Multi-Factor Authentication (MFA) must utilize secure, second verification methods.
C. ACCESS CONTROL
- A computer monitor screensaver must initiate after 15 minutes of idleness, forcing the user to log back in to wake it up.
- A session must terminate after a defined period of idleness (e.g., 60 minutes for applications, 12 hours for Single Sign-On), where applicable and technically feasible, to prevent exploitation if the user forgot to log out.
- The 鈥渞emember me鈥� functionality for an application or program that allows a user to stay authenticated for long periods without asking for credentials again, should not be more than 7 days, where technically feasible.
- Virtual Private Network (VPN) and other remote connections must time out at least once per 18 hours. Enterprise secure remote access that extends security protection to university IT Assets when not on the campus network may have extended session times when it is secured by MFA. For complete remote access requirements, see the Network Security Standard.
- Privileged account owners must use their standard user account for day-to-day activities, and only elevate to their privileged account when needed. Privileged access should leverage just-in-time access such that elevated permissions are revoked after no more than 8 hours.
- Privileged access to applications should not allow users to stay authenticated for more than 24 hours.
- Privileged local accounts should be used strictly in emergency situations, with access tightly controlled, monitored, and audited to prevent unauthorized use. Prioritizing least privilege minimizes potential vulnerabilities while ensuring break-glass accounts remain a last-resort measure.
The Office of Cybersecurity shall maintain authority to restrict requirements further than what is defined above based on risk exposure (e.g., shorten timeout periods when user location is abroad). They are authorized to take mitigating actions such as disabling an account without warning if it is in violation of university policy, state, or federal regulations, or in response to a security incident that poses an imminent threat to the university.
EXCEPTIONS
On a rare occasion, a security policy exception may be considered depending on the impact to the university mission and security risk(s) introduced. Those seeking an exception must submit a request to the Office of Cybersecurity for evaluation and risk assessment. Based on the level of risk, requests will be granted or denied by the CISO and Chief Information Officer (CIO).
ENFORCEMENT
The Chief Information Security Officer will refer violations to university units (e.g., Student Accountability Office, Human Resources, and Deans) as appropriate. Violations may also constitute a violation of state or federal law and individuals shall be accountable as applicable.
FORMS AND TOOLS
- Identity Services:
FREQUENTLY ASKED QUESTIONS
HISTORY
| Review Date | Summary of Changes |
| N/A | 听 |