NIST 800-171 R3 03.01.01 Account Management at a Glance
- Family: 03.01 Access Control (AC)
- Requirement ID: 03.01.01 Account Management
- Assessment Objectives (AOs): Twenty-eight (28) total, including the six (6) Organization-Defined Parameters (ODPs) below and twenty-two (22) determination statements
- Organization-Defined Parameters (ODPs): Six (6), specified by the Department of Defense (DoD) for the Defense Industrial Base (DIB)
- Source NIST 800-53 R5 Controls: AC-02, AC-02(03), AC-02(05), AC-02(13)
- NIST 800-171 R3 Kill Chain Phase: Phase 13, Identity & Access Management (IAM)
Account management is the part of an organization's existing Identity and Access Management (IAM) capability and is not a "cybersecurity requirement" - it is just part of good IT hygiene practices that is a reasonable expectation for any organization, regardless of its industry or size. Account Management (03.01.01) would be considered a "material control" since there are no compensating controls that can be implemented to reduce the risks associated with a missing or deficient account management capability. If user or service accounts are not managed, every other access control requirement is moot (e.g., security theater).
A common difficulty with this requirement is assumptions, since account management probably feels like a requirement you already meet: You have an identity provider, you create accounts and you disable them when someone leaves. In NIST 800-171 R3, that comfort is exactly where non-conformity lives. In R3 of NIST 800-171, requirement 03.01.01 was promoted into a dedicated, lifecycle-based requirement. Most of its Assessment Objectives (AOs) are completely new and were not part of NIST 800-171 R2.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
- The National Institute of Standards and Technology (NIST) withdrew R2 on May 14, 2024, the same day R3 was published. The withdrawal notice states that R2 "has been withdrawn (archived), and is provided solely for historical purposes," so it will never receive another correction or clarification from NIST.
- R2 remains the contractual standard for the Department of Defense (DoD) and the Defense Industrial Base (DIB). Cybersecurity Maturity Model Certification (CMMC) assessments reference it directly: per Title 32 of the Code of Federal Regulations (CFR), section 170.14(c)(3), "the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2."
- The rulemaking points the other direction. The proposed Controlled Unclassified Information (CUI) rule for the Federal Acquisition Regulation (FAR), published June 23, 2026 as part of the Revolutionary FAR Overhaul, would apply CUI safeguarding requirements government wide rather than only to DoD contracts, and it sets the baseline at R3. That rule is not final, and DoD has separately signaled an interim rule to move CMMC to R3.
What Does NIST 800-171 R3 03.01.01 Actually Require?
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.01.01 Account Management. Only the formatting has been adjusted for readability. This requirement has eight (8) lettered parts:
- 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. Authorized users of the system,
- 2. Group and role membership, and
- 3. Access authorizations (i.e., privileges) for each account.
- d. Authorize access to the system based on:
- 1. A valid access authorization and
- 2. Intended system usage.
- e. Monitor the use of system accounts.
- f. Disable system accounts when:
- 1. The accounts have expired,
- 2. The accounts have been inactive for [Assignment: organization-defined time period],
- 3. The accounts are no longer associated with a user or individual,
- 4. The accounts are in violation of organizational policy, or
- 5. Significant risks associated with individuals are discovered.
- g. Notify account managers and designated personnel or roles within:
- 1. [Assignment: organization-defined time period] when accounts are no longer required.
- 2. [Assignment: organization-defined time period] when users are terminated or transferred.
- 3. [Assignment: 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 [Assignment: organization-defined time period] of expected inactivity or when [Assignment: organization-defined circumstances].
The source controls are AC-02, AC-02(03), AC-02(05), and AC-02(13) from NIST 800-53. You can read the NIST 800-171 R3 03.01.01 requirement directly at NIST 800-171 R3, 03.01.01 (p. 6).
What Are the Organization-Defined Parameters (ODPs) Associated with NIST 800-171 R3 03.01.01?
Six (6) values sit inside this requirement. Depending on your contract, your organization may be permitted to define them. Organizations in the DIB subject to CMMC are not, because the DoD has defined them as policy.
The values below come from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
- ODP[01] (DoD memo identifier 03.01.01.f.02). the time period for account inactivity before disabling is defined. DoD Position: at most 90 days.
- ODP[02] (DoD memo identifier 03.01.01.g.01). the time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined. DoD Position: 24 hours.
- ODP[03] (DoD memo identifier 03.01.01.g.02). the time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined. DoD Position: 24 hours.
- ODP[04] (DoD memo identifier 03.01.01.g.03). the 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. DoD Position: 24 hours.
- ODP[05] (DoD memo identifier 03.01.01.h.01). the time period of expected inactivity requiring users to log out of the system is defined. DoD Position: at most 24 hours.
- ODP[06] (DoD memo identifier 03.01.01.h.02). circumstances requiring users to log out of the system are defined. DoD Position: the work period ends, for privileged users at a minimum.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
What Are the Assessment Objectives (AOs) For NIST 800-171 R3 03.01.01?
This is where 03.01.01 gets heavy. NIST 800-171A R3 decomposes the requirement into twenty-eight (28) determination statements that an assessor will check, including six (6) Organization-Defined Parameters (ODPs). These AOs are:
- A.03.01.01.ODP[01]: the time period for account inactivity before disabling is defined.
- A.03.01.01.ODP[02]: the time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined.
- A.03.01.01.ODP[03]: the time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined.
- A.03.01.01.ODP[04]: the 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.
- A.03.01.01.ODP[05]: the time period of expected inactivity requiring users to log out of the system is defined.
- A.03.01.01.ODP[06]: circumstances requiring users to log out of the system are defined.
- A.03.01.01.a[01]: system account types allowed are defined.
- A.03.01.01.a[02]: system account types prohibited are defined.
- A.03.01.01.b[01]: system accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
- A.03.01.01.b[02]: system accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
- A.03.01.01.b[03]: system accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
- A.03.01.01.b[04]: system accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
- A.03.01.01.b[05]: system accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
- A.03.01.01.c.01: authorized users of the system are specified.
- A.03.01.01.c.02: group and role memberships are specified.
- A.03.01.01.c.03: access authorizations (i.e., privileges) for each account are specified.
- A.03.01.01.d.01: access to the system is authorized based on a valid access authorization.
- A.03.01.01.d.02: access to the system is authorized based on intended system usage.
- A.03.01.01.e: the use of system accounts is monitored.
- A.03.01.01.f.01: system accounts are disabled when the accounts have expired.
- A.03.01.01.f.02: system accounts are disabled when the accounts have been inactive for <A.03.01.01.ODP[01]: time period>.
- A.03.01.01.f.03: system accounts are disabled when the accounts are no longer associated with a user or individual.
- A.03.01.01.f.04: system accounts are disabled when the accounts violate organizational policy.
- A.03.01.01.f.05: system accounts are disabled when significant risks associated with individuals are discovered.
- A.03.01.01.g.01: account managers and designated personnel or roles are notified within <A.03.01.01.ODP[02]: time period> when accounts are no longer required.
- A.03.01.01.g.02: account managers and designated personnel or roles are notified within <A.03.01.01.ODP[03]: time period> when users are terminated or transferred.
- A.03.01.01.g.03: account managers and designated personnel or roles are notified within <A.03.01.01.ODP[04]: time period> when system usage or the need-to-know changes for an individual.
- A.03.01.01.h: users are required to log out of the system after <A.03.01.01.ODP[05]: time period> of expected inactivity or when the following circumstances occur: <A.03.01.01.ODP[06]: circumstances>.
The practical takeaway is that "we manage accounts" is not an answer. An assessor is going to ask you to demonstrate each and every one of those AO statements with evidence. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.01.01 (p. 7).
Assessment Methods and Objects for NIST 800-171 R3 03.01.01
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; 8 NIST SP 800-171Ar3 Assessing CUI Security Requirements May 2024 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.
How Does NIST 800-171 R3 03.01.01 Map From NIST 800-171 R2?
03.01.01 is not entirely net new, so there is a transition path, but the overlap is small. Two R2 requirements feed into it:
- 3.1.1 (limit system access to authorized users, processes, and devices) supplies the "authorized users are specified" piece and elements of the access authorization statements.
- 3.5.6 (disable identifiers after a defined inactivity period) supplies the inactivity ODP and the "disable inactive accounts" objective.
Mapped against the twenty-eight (28) assessment objectives, the breakdown is roughly this: three (3) objectives map directly from R2 (minimal effort), two map indirectly and need analysis (moderate effort), five have no clear prior mapping, and the remaining 18 are net new for R3. In other words, the familiar parts of Account Management account for about five of twenty-eight (28) objectives. Everything else is either a reinterpretation or brand new work.
How Does NIST 800-171 R3 03.01.01 Map to NIST 800-53 R5 and the SCF?
Source Controls in NIST 800-53 R5:
- AC-02
- AC-02(03)
- AC-02(05)
- AC-02(13)
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.01.01 through the following SCF controls:
- CFG-04 Secure Baseline Configurations
- CFG-04.5 Session Termination
- MON-16 Anomalous Behavior
- DCH-02 Data Protection
- DCH-07 Sensitive / Regulated Data Protection
- HRS-02 Human Resources Security Management
- HRS-03 Position Categorization
- HRS-06 Terms of Employment
- HRS-06.3 Technology Use Restrictions
- HRS-10 Personnel Sanctions
- HRS-10.1 Workplace Investigations
- HRS-11 Personnel Transfer
- HRS-12 Personnel Termination
- HRS-12.1 Automated Employment Status Notifications
- IAC-02 Identity & Access Management (IAM)
- IAC-03 Authenticate, Authorize and Audit (AAA)
- IAC-04 User Provisioning & De-Provisioning
- IAC-04.1 Change of Roles & Duties
- IAC-06 Role-Based Access Control (RBAC)
- IAC-08 Account Management
- IAC-08.1 Automated System Account Management (Directory Services)
- IAC-08.2 Authorized Accounts
- IAC-08.4 Disable Inactive Accounts
- IAC-08.5 Account Disabling for High Risk Individuals
- IAC-09 Management Approval For New or Changed Accounts
- IAC-12 Periodic Review of Individual & Service Account Privileges
- IAC-12.1 System Account Reviews
- IAC-21 Restrictions on Shared Groups / Accounts
- IAC-25 Access Enforcement
- IAC-25.1 Access To Sensitive / Regulated Data
- IAC-30 Least Privilege
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
Common Pitfalls with NIST 800-171 R3 03.01.01
The net-new objectives are the pitfalls, because they ask for documentation and process that R2 never made you prove:
- Defining account types allowed and prohibited. Many organizations have never written down which account types (group, guest, anonymous, temporary, emergency, service) are permitted and which are banned. The assessor needs that defined, not assumed.
- The full account lifecycle. Create, enable, modify, disable, and remove are each separately assessed. A procedure that only covers onboarding and offboarding will leave gaps.
- Monitoring account use. "The use of system accounts is monitored" is its own objective. You need evidence of active monitoring, not just the ability to pull logs.
- Notification timelines. Items g.01 through g.03 require that the right people are notified within your defined time periods. If you are in the DIB, that window may be 24 hours, which is operationally demanding without automation.
- Forced logout. Item h requires logout after inactivity or under defined circumstances. Note that this is account-level logout behavior, which is distinct from session lock and from device timeout.
There is also a documentation dependency worth calling out. ComplianceForge's NIST 800-171 R3 Transition Guide flags that R3 quietly assumes documentation exists (policies, procedures, defined roles) without always making it an explicit objective. Account Management leans on that assumption. If your policies and procedures do not actually describe these account practices, you will struggle to produce evidence even where you are doing the work.
What Is Reasonable Evidence For NIST 800-171 R3 03.01.01?
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.01.01 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.01.01 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
- E-AST-12 Secure Baseline Configurations Reviews. A review process to ensure secure baseline configurations (sbc) are current and applicable (e.g., system configuration settings and associated documentation).
- E-AST-13 Secure Baseline Configurations - Cloud-Based Services. Secure baseline configurations for all deployed types of cloud-based services or applications.
- E-AST-14 Secure Baseline Configurations - Databases. Secure baseline configurations for all deployed types of databases.
- E-AST-15 Secure Baseline Configurations - Embedded Technologies. Secure baseline configurations for all deployed types of embedded technologies.
- E-AST-16 Secure Baseline Configurations - Major Applications. Secure baseline configurations for all deployed types of major applications.
- E-AST-17 Secure Baseline Configurations - Minor Applications. Secure baseline configurations for all deployed types of minor applications.
- E-AST-18 Secure Baseline Configurations - Mobile Devices. Secure baseline configurations for all deployed types of mobile devices.
- E-AST-19 Secure Baseline Configurations - Network Devices. Secure baseline configurations for all deployed types of network devices.
- E-AST-20 Secure Baseline Configurations - Server Class Systems. Secure baseline configurations for all deployed types of server-class operating systems.
- E-AST-21 Secure Baseline Configurations - Workstation Class Systems. Secure baseline configurations for all deployed types of workstation-class operating systems.
- E-DCH-02 Data Handling Practices. An organization-specific data handling practices (e.g., guidance specific the data classification scheme).
- E-DCH-08 Authorization Documentation. That identifies authorized users and processes acting on behalf of authorized users.
- E-HRS-01 Position Categorization. A discrete roles for cybersecurity & data privacy functions (e.g., position categorization).
- E-HRS-12 Role Review. A formal review process to ensure personnel roles currently reflect business needs.
- E-HRS-16 Access Agreements. Personnel management practices protecting sensitive/regulated data through formal access agreements.
- E-HRS-18 Provisioning Checklist (Onboarding). Personnel management practices to formally onboard personnel into their assigned roles.
- E-HRS-19 Deprovisioning Checklist (Offboarding). Personnel management practices to formally offboard personnel from their assigned roles due to employment termination or role change.
- E-HRS-22 Rules of Behavior. Personnel management practices to define "acceptable use" or "rules of behavior" criteria that specify acceptable and unacceptable user behaviors.
- E-HRS-27 Personnel Sanctions. Personnel management practices to formally sanction unacceptable behavior(s).
- E-HRS-29 Personnel Actions Documentation. Notifications or records of recently transferred, separated, or terminated employees.
- E-IAC-01 Access Permission Review. Periodic access permission reviews.
- E-IAC-02 Defined Roles & Authorizations (RBAC). Defined access control-specific roles (e.g., role based access control (rbac)) that affect both logical and physical access authorizations.
- E-IAC-05 Identity & Access Management (IAM) Function. An identity & access management (iam), or similar function, that facilitates the implementation of identification and access management controls.
- E-IAC-06 Authenticate, Authorize and Audit (AAA) Solution. An authenticate, authorize and audit (aaa) solution (on-premises and hosted by external service providers (esp)).
- E-IAC-07 Account Management Compliance Reviews. Account management compliance reviews.
- E-IAC-08 Conditions for Group / Role Membership. Conditions for group and role membership.
- E-IAC-09 Access Authorization Records. Access authorization records.
- E-IAC-10 Active Accounts. Active system accounts and the name of the individual associated with each account.
- E-IAC-11 Recently Disabled Accounts. List of recently disabled system accounts along with the name of the individual associated with each account.
- E-IAC-12 Account Management Documentation. List of account management practices.
- E-MON-07 Situational Awareness. The organization leveraging knowledge of event log generation to gain situational awareness of cross-domain activities (e.g., technology issues, security events, policy violations, service provider activities, remote workforce activities, physical security events, etc.).
Alongside these, keep the System Security Plan (SSP) narrative for 03.01.01 recording the ODP values you adopted.
Timeline Considerations for NIST 800-171 R3 03.01.01
With roughly 23 of the twenty-eight (28) objectives net new or lacking a clean mapping, do not treat 03.01.01 as a quick win during transition planning. A realistic sequence:
- Define your six (6) ODPs first, since the disabling, notification, and logout objectives all depend on them.
- Write or update the account management policy and procedure to cover the full lifecycle and the allowed and prohibited account types.
- Build or configure the automation for monitoring, inactivity disabling, and notifications, because the DIB timelines are hard to hit manually.
- Collect evidence for each of the twenty-eight (28) determination statements and store it where an assessor can find it efficiently.
Frequently Asked Questions About NIST 800-171 R3 03.01.01
What value does the DoD require for the first parameter in NIST 800-171 R3 03.01.01? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.01.01.f.02: at most 90 days.
How many assessment objectives does NIST 800-171 R3 03.01.01 have? NIST 800-171A R3 breaks 03.01.01 into twenty-eight (28) assessment objectives: six (6) Organization-Defined Parameters (ODPs) and twenty-two (22) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 controls does NIST 800-171 R3 03.01.01 come from? AC-02, AC-02(03), AC-02(05), AC-02(13).
Where does NIST 800-171 R3 03.01.01 sit in the NIST 800-171 R3 Kill Chain? Phase 13, Identity & Access Management (IAM). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
Bottom Line on NIST 800-171 R3 03.01.01
03.01.01 Account Management looks like a requirement you already satisfy, which is why it is frequently underestimated. It carries a real transition path from R2 requirements 3.1.1 and 3.5.6, but only about five of its twenty-eight (28) assessment objectives come along for free. The rest, especially defining account types, proving lifecycle management, monitoring account use, and meeting notification timelines, are net new and depend on documentation you may not have written yet. Start with your ODPs, fix the documentation, then prove each objective.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
