University of Idaho - I Banner
A student works at a computer


U of I's web-based retention and advising tool provides an efficient way to guide and support students on their road to graduation. Login to VandalStar.

Access Control


This updated standard is to help align existing IT practices around access controls to the requirements in NIST 800-171 (AC | 3.1.x) as well as industry best practices.

What is in this document:

  • Zero trust requirements for high-risk data
  • Application of principle of least privilege from APM 30.10
  • Requirements of external/public systems
  • Session and timeout requirements
  • Remote and wireless access

What is NOT in this document:

Policy Reference

APM 30.10 Identity and Access Management Policy

APM 30.11 University Data Classification and Standards

APM 30.12 Acceptable Use of Technology Resources

APM 30.14 Cyber Incident Reporting and Response

APM 30.16 Technology Hardware Lifecycle Management


This Access Control standard supports APM 30.11 University Data Classification and Standards and other relevant university policies.


These standards are the minimum baseline for all managed and unmanaged systems that access, store or process University of Idaho data (see APM 30.14 C-6) or using University of Idaho technology resources (see APM 30.12 C-1) at the Low, Moderate- or High risk levels (see APM 30.11) not otherwise covered by an approved systems security plan.


Non-public systems must identify users and/or devices prior to access.

  1. Authentication sources use identity types as defined by Identification and Authentication standard section D-1. (3.1.1[a-c])
    Applies to: Low / Moderate / High
  2. Any device used to access high-risk university resources must be identified as a healthy, managed technology device by one of the following approved methods: Duo device health, Azure Conditional access, signed device certificates or other OIT-approved inventory meeting conditions below:

    Applies to: High

    1. Currently supported operating system.
    2. Latest security patches are installed within 30 days to allow a grace period for patches to be installed as per patching requirements.
    3. Device has a password set.
    4. Device is encrypted.
    5. Device has the system firewall enabled.
    6. Identified as a unique managed technology device.
    7. University Managed endpoint security is installed where supported.
  3. Authorization is granted to resources based on identity types based on groups or affiliation within an OIT-managed identity source (3.1.2[e-f])

    Applies to: Low / Moderate / High

To ensure compliance with APM 30.10 B-1 the following standards ensure least privilege is implemented and is auditable:

  1. System/Application owners must document authorized account types or groups within documentation as well as any relevant system security plans or knowledge base articles. (3.1.2[a-b])

    Applies to: Low / Moderate / High

    1. If multiple levels of permissions are provided, such as privileged or administrator roles, each group must be documented.
    2. Moderate and high-risk applications must also provide role/permissions provided to account type or group.
  2. Limit access to only users and systems with a legitimate education interest or documented business requirement.

    Applies to: Low / Moderate / High

  3. Document and retain user access requests and approvals for at least 1-year.

    Applies to: Moderate / High

  4. Disable account access once there is no longer a requirement for access.

    Applies to: Low / Moderate / High

  5. Privileged functionality must be limited only to accounts intended to be privileged accounts as per APM 30.10 Section A-2. (3.1.7[c])

    Applies to: Moderate / High

    1. Privileged accounts are identified through the ‘su-‘, ‘ad-‘, ‘admin-‘ or ‘net-‘ prefixes. (3.1.5[a], 3.5.3[b])
  6. Privileged accounts not using these prefixes may exist that are specific to local systems or applications if recorded as privileged accounts within application documentation.
  7. Privileged accounts must not be used for non-privileged functions as per APM 30.10 Section B-1. (3.1.6[b])

To ensure data is not inappropriately being shared:

  1. External systems for storage:
    1. Must not be used in place of systems defined in ‘approved storage locations’3 or ‘What Microsoft 365 Applications are approved for use?‘4 knowledge base articles. (3.1.20[a-b])

      Applies to: Low / Moderate / High

      1. Unapproved systems or applications are subject to restrictions via network or other application controls if sufficient risk is identified by OIT Security and restriction is approved by CIO/VP of IT. (3.1.20[c-d])
    2. May only be used for university data after being reviewed and approved by OIT prior to use for university purposes. (3.1.20[e-f])

      Applies to: Low / Moderate / High

  2. For public systems:
    1. Application owners must create and maintain a list of users authorized to publish. (3.1.22[a])

      Applies to: Low / Moderate / High

    2. Application owners must define a procedure of review, including a data sensitivity review, prior to posting or enabling in cases of automated publishing systems. (3.1.22[b-c])

      Applies to: Low / Moderate / High

    3. Application owners must register systems with OIT as they are created and attest that postings do not and will not contain non-public information and are periodically reviewed at the system owner's or OIT’s discretion. (3.1.22[d])

      Applies to: Low / Moderate / High

    4. Application owners must define post/content removal or correction procedures. (3.1.22[e])

      Procedure must:

      1. Include who removals must be reported to.
      2. Be able to complete required remediation within a timely manner required by CSIRT as per APM 30.14.

        Applies to: Low / Moderate / High

To ensure trust in the login mechanism, systems must adhere to the following standards:

  1. Automatically lock accounts after at most 20 bad attempts within 10 minutes. (3.1.8[a-b])

    Applies to: Low / Moderate / High

  2. Managed technology device must include the approved system use notification defined in the system use notification knowledge base article5.

    Applies to: Low / Moderate / High

  1. Enforce a session lockout and timeout for user access to systems after a period of inactivity (idle) (3.1.10[a-b], 3.1.11[a-b]):

    Applies to: Low / Moderate / High

    Device/Access type Lockout Timeout
    Default 15 mins N/A
    High-risk systems 5 mins N/A
    Shared workstations 15 mins 20 mins
    Shared high-risk workstations 5 mins 20 mins
    SSH Access 3 min keep alive 90 mins
    1. Requests for extended timeouts must be approved by OIT Security.
  2. Enforce a web session limit for user access and a lockout/timeout for user access after a period of inactivity (idle) consistent with NIST 800-63b.
    1. Applications must have either a 30-day session limit or a lockout/timeout after 14 days of inactivity (idle).

      Applies to: Low

    2. Application must have a 12-hour session limit and timeout after 30 minutes of inactivity (idle).

      Applies to: Moderate

      1. Reauthentication must use at least one (1) authentication factor as defined by IT Account Creation, Retention and Expiration Standards.
      2. Sessions with managed devices or applications can utilize the device lockout period rather than enforcement via the web app.
    3. Applications must have a 12-hour session limit and a lockout after 15 minutes of inactivity (idle).

      Applies to: High

      1. Reauthentication must use at least two (2) authentication factors as defined by IT Account Creation, Retention and Expiration Standards.
  3. Lockout for operating systems must show a pattern-hiding display such as a lock screen, static images, a clock or even a blank screen. (3.1.10[c])

    Applies to: Low / Moderate / High

  4. Terminate user sessions fully and automatically when requested by user or administrator.

    Applies to: Low / Moderate / High

  5. Automatically terminate sessions when sessions are no longer required or valid.

    Applies to: Low / Moderate / High

Remote access is granted through the U of I VPN,, or an approved path that will adhere to these standards: (3.1.12[a-b], 3.1.14[a-b])

  1. Authentication events are recorded with user, timestamp, authentication outcome, remote and assigned IP. (3.1.12[d])
  2. Remote access must use university credentials and OIT-managed MFA. (3.1.12[c])
  3. Authentication and session will use strong, modern TLS encryption that is kept up to date. (3.1.13[a-b])
    1. Regulated data will be required to use approved and validated algorithms such as FIPS.
  4. Remote access to high-risk networks requires device authentication as listed in Section C-1b of this document.

To ensure data and systems can be safely accessed and utilized by in-person individuals, they must utilize the appropriate U of I wireless networks while using wireless on campus which will adhere to these standards:

  1. Wireless Access Points used are recorded within NMS and are managed by OIT. (3.1.16[a-b])
  2. Wireless access requires authentication over an encrypted channel. (3.1.17[a])
    1. U of I internal networks such as AirVandalGold — WPA2 Enterprise using PEAP and MSCHAPv2 or EAP-TLS (3.1.17[b])
    2. U of I Public, Guest or event networks — WPA2 Pre Shared Key (PSK)

Other References

1. NIST SP800-171r2 (February 2020) 

2. NIST SP800-53r5 (September 2020)

3. Approved storage locations

4. What Microsoft 365 Applications are approved for use?

5. System Use Notification

6. NIST SP800-63-3 summary table

7. IT Account Creation, Retention and Expiration Standards


1. Authorized User

Any appropriately cleared individual with a requirement to access an information system.

2. Processes

An application, program, script or other software. The sensitivity of which is determined by the data it can access, including API calls to other applications and local data it brings into memory.

3. Authorized publishers

An individual person who has permissions to publish information on a system.

4. External system

“A system or component of a system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.” NIST SP800-171r2

5. Public system

A system or application that can be accessed in any form from the general public or the internet.

6. Privileged functionality

Functionality that can impact the confidentiality, integrity or availability of data including but not limited to changes to access permissions, roles, security configuration, changes directly to high-risk or non-public data of other users or that impact the security of high-risk or non-public data of other users.

7. Non-privileged functionality

Standard user activity including but not limited to email, web browsing and general-class tasks.

8. Non-privileged User

A user that is unable to perform privileged functionality. May also be referred to as a standard user or account.

9. Remote Access

“Access to an organizational system by a user (or a process acting on behalf of a user) communicating through an external network (e.g., the Internet).” NIST SP800-171r2

10. Session lockout

A method of removing access to a system that retains the user session information and does not interrupt running processes, but still requires re-authentication prior to regaining access to the system.

11. Session timeout

A Method of removing access to a system that removes the user session information completely and requires re-authentication.

12. Session limit

The length of time a session is valid regardless of activity.

13. System

“A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information.” NIST SP800-171r2

14. Operating system

“A collection of software that manages computer hardware resources and provides common services for computer programs.” NIST SP 800-152. Includes but is not limited to:

  1. Windows
  2. MacOS
  3. Linux distributions (Ubuntu, RedHat, etc.)
  4. Android
  5. iPhone/iPad iOS
  6. Vendor provided appliance OS

15. University of Idaho Network Management System (NMS)

University of Idaho proprietary system for managing networks, devices on networks and connections between networks.

16. Managed Technology Device

Standard technology hardware that is managed by OIT-defined security and management software. See APM 30.16 Section C-2.

Standard Owner

U of I Office of Information Technology (OIT) is responsible for the content and management of these standards.

To request an exception to this standard.


Revision History

3/1/2024 — Minor updates

  • Added allowance for specific networks to be used in place of device health checks.
  • Added allowance for vendor accounts to be privileged when documented.
  • Other minor formatting/wording/reference changes.

6/23/2023 — Original standard

  • Full re-write to align with NIST 800-171r2

Physical Address:

Teaching Learning Center Room 128

Office Hours:

Monday - Friday
8 a.m. to 5 p.m.

Summer Hours:

Monday - Friday
7:30 a.m. to 4:30p.m.

Phone: 208-885-4357 (HELP)