HECVAT Category

Authentication, Authorization, and Account Management

Authentication, Authorization, and Account Management covers controls and questions related to that domain. It outlines expectations institutions typically require from vendors. The category helps assess risk posture and operational maturity. It provides structure for consistent evaluation during security reviews.

Assessment Questions

AAAI-01

Does your solution support single sign-on (SSO) protocols for user and administrator authentication?

Single sign-on capability is the subject here, specifically whether your solution supports SSO protocols for authenticating both regular users and administrators. SSO is an authentication method that allows users to access multiple applications with one set of credentials. It eliminates the need for users to maintain and remember multiple passwords.

AAAI-02

For customers not using SSO, does your solution support local authentication protocols for user and administrator authentication?

When SSO isn't in play, this comes down to whether your solution still offers local authentication for both users and administrators.

AAAI-03

For customers not using SSO, can you enforce password/passphrase complexity requirements (provided by the institution)?

For customers who skip SSO, the concern is whether your system can still enforce the password or passphrase complexity rules the institution defines.

AAAI-04

For customers not using SSO, does the system have password complexity or length limitations and/or restrictions?

For users who are not on Single Sign-On (SSO), the concern here is whether your system enforces any password complexity or length rules.

AAAI-05

For customers not using SSO, do you have documented password/passphrase reset procedures that are currently implemented in the system and/or customer support?

For users outside of SSO, this item looks for documented password and passphrase reset procedures that are actually implemented in the system or through customer support.

AAAI-06

Does your organization participate in InCommon or another eduGAIN-affiliated trust federation?

Trust federation in the academic world is the subject here: the question checks whether you participate in InCommon, eduGAIN, or a comparable identity federation built for education and research.

AAAI-07

Are there any passwords/passphrases hard-coded into your systems or solutions?

Hard-coded secrets are what this probes for: whether any passwords or passphrases are written directly into your source code, configuration files, or other system components.

AAAI-08

Are you storing any passwords in plaintext?

Password storage practices are under scrutiny here, specifically whether any user passwords are kept in plaintext rather than in a securely hashed or encrypted form.

AAAI-09

Are audit logs available that include AT LEAST all of the following: login, logout, actions performed, and source IP address?

Audit logging is what's being probed: reviewers want assurance that your system records user activity in detail, including logins, logouts, actions taken, and source IP addresses. Specifically, it's asking if your logs capture at least four critical elements:

AAAI-10

Describe or provide a reference to the (a) system capability to log security/authorization changes, as well as user and administrator security events (i.e., physical or electronic), such as login failures, access denied, changes accepted; and (b) all requirements necessary to implement logging and monitoring on the system. Include (c) information about SIEM/log collector usage.*

Assessors want a clear picture of your logging and monitoring capabilities, covering how security and authorization changes plus user and administrator events are captured and reviewed. It has three main parts:

AAAI-11

Can you provide the institution documentation regarding the retention period for those logs, how logs are protected, and whether they are accessible to the customer (and if so, how)?

Reviewers are probing how you handle authentication and account logs, including how long they are retained, how they are protected, and whether customers can access them. Specifically, it wants to know:

AAAI-12

For customers not using SSO, does your application support integration with other authentication and authorization systems?

For customers who don't rely on SSO, the concern is whether your application can plug into authentication and authorization systems beyond your own native login. Authentication systems verify user identity (who they are), while authorization systems determine what they can access.

AAAI-13

Do you allow the customer to specify attribute mappings for any needed information beyond a user identifier? (e.g., Reference eduPerson, ePPA/ePPN/ePE)

Attribute mapping flexibility is what's being probed: whether customers can configure how identity-provider attributes beyond a basic user identifier map into your service.

AAAI-14

For customers not using SSO, does your application support directory integration for user accounts?

When Single Sign-On is not in play, this asks whether your application can tie into directory services such as Active Directory or LDAP for managing user accounts.

AAAI-15

Does your solution support any of the following web SSO standards: SAML2 (with redirect flow), OIDC, CAS, or other?

Federated login support is the subject here: reviewers want to know which web SSO standards your solution speaks, such as SAML2 with redirect flow, OIDC, CAS, or others. SSO allows users to authenticate once and gain access to multiple systems without having to log in separately to each one.

AAAI-16

Do you support differentiation between email address and user identifier?

Identifier flexibility is what matters here, namely whether your system lets a user's login identifier exist independently from their email address.

AAAI-17

For customers not using SSO, does your application and/or user frontend/portal support multifactor authentication (e.g., Duo, Google Authenticator, OTP, etc.)?

For users who aren't authenticating through SSO, reviewers want confirmation that your application or portal still supports multi-factor authentication such as Duo, Google Authenticator, or OTP.

AAAI-18

Does your application automatically lock the session or log out an account after a period of inactivity?

Session protection is the concern: reviewers want to confirm that your application automatically locks or logs out an account once it has been idle for a set period.