03.01.01 — Account Management

Official NIST requirement content

Security requirement

a.Define the types of system accounts allowed and prohibited.
b.Create, enable, modify, disable, and remove system accounts in accordance with policy, procedures, prerequisites, and criteria.
c.Specify:
1. 1.Authorized users of the system,
2. 2.Group and role membership, and
3. 3.Access authorizations (i.e., privileges) for each account.
d.Authorize access to the system based on:
1. 1.A valid access authorization and
2. 2.Intended system usage.
e.Monitor the use of system accounts.
f.Disable system accounts when:
1. 1.The accounts have expired,
2. 2.The accounts have been inactive for [Organization-defined: time period],
3. 3.The accounts are no longer associated with a user or individual,
4. 4.The accounts are in violation of organizational policy, or
5. 5.Significant risks associated with individuals are discovered.
g.Notify account managers and designated personnel or roles within:
1. 1.[Organization-defined: time period] when accounts are no longer required.
2. 2.[Organization-defined: time period] when users are terminated or transferred.
3. 3.[Organization-defined: time period] when system usage or the need-to-know changes for an individual.
h.Require that users log out of the system after [Organization-defined: time period] of expected inactivity or when [Organization-defined: circumstances].

Official NIST discussion

Discussion

This requirement focuses on account management for systems and applications. The definition and enforcement of access authorizations other than those determined by account type (e.g., privileged access, non-privileged access) are addressed in 03.01.02. System account types include individual, group, temporary, system, guest, anonymous, emergency, developer, and service. Users who require administrative privileges on system accounts receive additional scrutiny by personnel responsible for approving such accounts and privileged access. Types of accounts that organizations may prohibit due to increased risk include group, emergency, guest, anonymous, and temporary. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of both. Other attributes required for authorizing access include restrictions on the time of day, day of the week, and point of origin. When defining other system account attributes, organizations consider system requirements (e.g., system upgrades, scheduled maintenance) and mission and business requirements (e.g., time zone differences, remote access to facilitate travel requirements). Users who pose a significant security risk include individuals for whom reliable evidence indicates either the intention to use authorized access to the system to cause harm or that adversaries will cause harm through them. Close coordination among mission and business owners, system administrators, human resource managers, and legal staff is essential when disabling system accounts for high-risk individuals. Time periods for the notification of organizational personnel or roles may vary. Inactivity logout is behavior- or policy-based and requires users to take physical action to log out when they are expecting inactivity longer than the defined period. Automatic enforcement of inactivity logout is addressed by 03.01.10.

Official organization-defined parameters

Tailoring decisions required

Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.

time periodorganization-defined time periodthe time period for account inactivity before disabling is defined.

time periodorganization-defined time periodthe time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined.

time periodorganization-defined time periodthe time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined.

time periodorganization-defined time periodthe time period within which to notify account managers and designated personnel or roles when system usage or the need-to-know changes for an individual is defined.

time periodorganization-defined time periodthe time period of expected inactivity requiring users to log out of the system is defined.

circumstancesorganization-defined circumstancescircumstances requiring users to log out of the system are defined.

Bare Metal Cyber interpretation

Implementation perspective

Treat Account Management as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to approved identities, least privilege, remote access, information flow, and the full account lifecycle.

Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
Resolve every organization-defined parameter through an approved governance and tailoring process.
Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.

Questions to ask

Which CUI assets, data flows, users, and services are protected by this requirement?
Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
What change, incident, or threshold should trigger reassessment?

Evidence and validation

access authorization and approval records
account inventories and entitlement exports
access review results
authentication and authorization logs

Common failure patterns

CUI access that exceeds mission need
shared or orphaned accounts
remote access paths outside the approved boundary
access reviews that cannot be reconciled to deployed permissions

Official NIST SP 800-171A content

Assessment objectives and methods

Assessment objectives (22)

b.
system accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
b.
system accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
b.
system accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
b.
system accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
b.
system accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
a.
system account types allowed are defined.
a.
system account types prohibited are defined.
c.1.
authorized users of the system are specified.
c.2.
group and role memberships are specified.
c.3.
access authorizations (i.e., privileges) for each account are specified.
d.1.
access to the system is authorized based on a valid access authorization.
d.2.
access to the system is authorized based on intended system usage.
e.
the use of system accounts is monitored.
f.1.
system accounts are disabled when the accounts have expired.
f.2.
system accounts are disabled when the accounts have been inactive for [Organization-defined: time period].
f.3.
system accounts are disabled when the accounts are no longer associated with a user or individual.
f.4.
system accounts are disabled when the accounts violate organizational policy.
g.1.
account managers and designated personnel or roles are notified within [Organization-defined: time period] when accounts are no longer required.
g.2.
account managers and designated personnel or roles are notified within [Organization-defined: time period] when users are terminated or transferred.
g.3.
account managers and designated personnel or roles are notified within [Organization-defined: time period] when system usage or the need-to-know changes for an individual.
f.5.
system accounts are disabled when significant risks associated with individuals are discovered.
h.
users are required to log out of the system after [Organization-defined: time period] of expected inactivity or when the following circumstances occur: [Organization-defined: circumstances].

Examine

access control policy and procedures
personnel termination or transfer policies and procedures
procedures for account management
list of active system accounts and the name of the individual associated with each account
system design documentation
list of conditions for group and role membership
system configuration settings
notifications of recent transfers, separations, or terminations of employees
list of recently disabled system accounts and the name of the individual associated with each account
list of user activities that pose significant organizational risks
access authorization records
account management compliance reviews
system monitoring and audit records
system security plan
system-generated list of accounts removed
system-generated list of emergency accounts disabled
system-generated list of disabled accounts
other relevant documents and records

Interview

personnel with account management responsibilities
system administrators
personnel with information security responsibilities
system developers

Test

processes for account management on the system
mechanisms for implementing account management

Official source-control relationships

Source NIST SP 800-53 controls

These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.

Source controlAC-2Open SP 800-53 control →Source controlAC-2(3)Open SP 800-53 control →Source controlAC-2(5)Open SP 800-53 control →Source controlAC-2(13)Open SP 800-53 control →

Source record

Authoritative sources

Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.