Note: The Identity and Authentication Rule is expected to be issued summer 2026 with an effective date at the end of December. See this webpage for more information about the rule.

This supplemental guidance is for IT audiences and provides detailed guidance in support of RUL 08.00.19 – Identity and Authentication Rule.

Account Risk Levels

As defined in the Account Requirements section of the Identity and Authentication Rule, identity and authentication requirements vary depending on account risk levels (low, medium or high).

Note: Some risk categories can include outliers. For example, if a Unity account has privileged access to a system that stores, accesses or processes highly sensitive information, it is considered a high-risk account.

For the purposes of identity and authentication, NC State University has the following account risk levels:

• Low risk
• Medium risk
• High risk

Low Risk

The following account types are low risk:

• Kiosks, no-password accounts, publicly posted accounts, special equipment, non-network unprivileged equipment
• Brickyard accounts for the delivery of training

Medium Risk

The following account types are medium risk:

• Most Unity accounts (Unity accounts are at minimum a medium risk)
• Brickyard accounts for parental access
• Third-party accounts belonging to the university
• Unmanaged (non-SSO) individual accounts
• Orchestration accounts acting with individual user permissions

High Risk

The following account types are high risk:

• Privileged accounts of any type — whether individual, shared, or orchestration.
  • Note: .admin accounts are considered privileged accounts.
• Accounts that are likely to be impersonated (for detection and classification)
• Accounts with access to ultra-sensitive (purple) data
• Accounts assigned to individuals employed in central offices that provide critical operational services. This includes, but is not limited to: Athletics, Enrollment Management and Services, Finance and Administration, Audit, Office of Information Technology (OIT), Office for Research and Innovation
• Accounts assigned to users bound by compliance obligations: HIPAA, NIST 800-171 (SURE, other regulated research) and GLBA

Account Controls

As specified throughout this section, the following account controls for identity and authentication vary based on account level (low, medium or high risk):

• Password History
• Password Managers
• Storage of Physical Credentials and Secrets
• Account Provisioning
• Account Risk Changes
• Account Deprovisioning
• Password Lifetime
• Password Strength
• Multifactor Authentication (MFA)
• Account Recovery Methods
• Account Lockout Periods

Password History

The password history account control specifies the minimum number of previously used passwords that must be remembered to prevent password reuse.

The higher the risk, the higher the minimum password history.

Table 1. Password History

Risk Level	Minimum	Description
Low	0	No need to remember previously used passwords.
Medium	10	Must remember at least 10 most recent passwords.
High	100	Must remember at least 100 most recent passwords.

Password Managers

• Approved password managers are strongly recommended for storing credentials for university accounts.
• Use of unapproved password managers may expose individuals, their units and the university to increased risk

Note: NC State Password Guidelines for more information

Storage of Physical Credentials and Secrets

• Printed backup codes must be physically secured. Examples include a locked office or cabinet. Alternatively, backup codes can be stored digitally in an approved password manager.
• Physical tokens (used to verify your identity during authentication) must be securely stored when not in use. For example, you can keep tokens with you at all times or store them in a locked drawer.
• Devices with screen-lock capability used as a second factor must have the screen-lock feature enabled.

Account Provisioning

This section refers to verifying a person’s identity.

Table 2. Account Provisioning

Risk Level	Identity Proofing	Provisioning
Low	No identity proofing required	Automatic access granting is allowed
Medium	Medium identify proofing: Employees, including most non-paid affiliates, must pass background checks Students must pass the matriculation process	Automatic access granting is allowed
High	Strong identity proofing: A university employee must confirm the identify of the account user with photo ID and the NC State photo database, which can be found in ServiceNow	Granting account access requires human interaction and validation

Account Risk Changes

When raising an account’s risk level, that account must meet the higher level of account requirements. For example, an account moving from medium to high risk must meet the high-risk requirements before access is provisioned.

Account Deprovisioning

An account must have access and authorization disabled after it is no longer required. Removal of accounts, while recommended, is subject to the technical requirements of each individual system. Programmatic/automatic deprovisioning of accounts is preferred.

Table 3. Account Deprovisioning

Risk Level	Deadline
Low	After an appropriate grace/cleanup period
Medium	Next business day
High	Immediately upon termination of employment/duties

Password Lifetime

Table 4. Password Lifetime

Risk Level	Default Passwords	Password Change Frequency	Upon Security Breach
Low	Must be changed upon account creation	Not required	Immediately
Medium	Must be changed upon account creation	Not required, recommended annually	Immediately
High	Must be changed upon account creation	Required annually  (365 days)	Immediately

Password Strength

If your system supports entropy calculations, they are preferred over rule-based requirements. Any system using a PIN authentication mechanism must submit an IT exception.

Table 5. Password Strength

Risk Level	Rule-based	Entropy	Zxcvbn gl_10 score
Low	12 characters	60	8
Medium	16 characters	95	10
High	24 characters	160	Greater than 10

MFA

Table 6. MFA

Risk Level	MFA Requirement	MFA Method
Low	Optional	All MFA methods are allowed.
Medium	Required	SMS (text), voice call, and email-based verification are not allowed. All other MFA methods are allowed.
High	Required	Only phishing-resistant MFA methods are allowed such as FIDO2/WebAuthn Security Keys (YubiKeys)

Account Recovery Methods

Table 7. Account Recovery Methods

Risk Level	Account Recovery Method
Low	Both are required: A memorized secret. Examples could include: Security question and answer PIN A possession factor of authentication. Examples could include: Duo Credential reset link/OTP sent to a known email address
Medium	Same as above (medium and low are the same for this control).
High	An IT employee must verify the user’s identity before resetting the account password. Note: A government-issued ID with photo is required for user identification.

Account Lockout Periods

Table 8. Account Lockout Periods

Risk Level	After 10 Failed Attempts
Low	Must be locked out for a minimum of 30 minutes
Medium	Must be locked out for a minimum of 30 minutes
High	Must be locked out until an IT employee resets the password

Controls for Systems that Require Authentication Credentials

These systems are defined as those which are not using Single Sign On (SSO) and which are receiving user credentials. For example, a system doing LDAP authentication receiving the credentials may be storing them locally.

• All multi-user systems must use some form of web SSO (for example, Entra ID). Use of local authentication not listed below requires an IT exception.
  • List of common use cases that do not require a documented exception:
    • Local administrator accounts
    • Accounts used for automation
• Anti-brute force measures. Some limitations, such as attempt throttling or banning at the application level, must be implemented to prevent a large number of attempts to guess an account’s credentials. Any throttling or banning must be appropriately logged and sent to a centralized logging server.
• Secure authentication protocols. Systems must allow only the authentication protocols that have no known vulnerabilities.
• Hide passwords when entering them by default. Passwords must only be visible if an option is given and the user actively chooses to display it.
• Secure password hashing for local authentication. If a system stores a password after authentication, it must be hashed in a secure manner to prevent password cracking.
• For multi-user systems, log all authentication attempts into OIT’s centralized logging service. Whenever possible, log all individual system authentication attempts. In the case of a suspected attack or breach, this information is essential for forensic investigation and establishing timelines.

Single Sign-on/Centralized Authentication

In order of preference:

1. Entra ID (formerly Azure AD SSO)  (OIDC, SAML, OAuth, OpenID)
2. Shibboleth (SAML) (Through 2026)
3. Wolftech AD Kerberos
4. Wolftech AD LDAPS

Secure Password Hashing Methods for Local Authentication

• Modern hashing methods with high iteration counts:
  • PBKDF2, bcrypt, scrypt, Argon2

Glossary

• Entropy – Quantifies the amount of "randomness" contained in a password, which directly translates to how difficult it would be for a computer to guess it through brute force (guessing every possible combination).
• zxcvbn – This is an open-source implementation of an entropy calculation that also includes recognition for commonly used passwords, phrases, and patterns (for example, abcdefg).