Most organisations that fail a CUI assessment have implemented the control but cannot prove each assessment objective behind it. NIST SP 800-171A Rev. 3 is the companion publication that turns each SP 800-171 Rev. 3 security requirement into determination statements an assessor marks one by one, with suggested methods and objects for gathering evidence. This guide explains how the procedures are built, how to read the labels, how to plan evidence at objective level, where service accounts and other non-human identities change the picture, and how Rev. 3 relates to CMMC, which still uses the 2018 edition. It is written for compliance leads, internal assessors and engineers in defence contractors, universities and other nonfederal organisations that hold controlled unclassified information. For the requirements themselves and the CMMC programme, read the NIST SP 800-171 and CMMC 2.0 Guide first; this page goes deeper on assessment.
Key takeaways
- Assessors score objectives, not requirements. Each requirement breaks into determination statements, and one unsatisfied statement means the requirement is not met.
- Defined parameters come first. Rev. 3 adds organisation-defined parameters (ODPs), and the first determination statement for such a requirement asks whether you defined the value at all.
- Three methods, four object types. Plan evidence as examine, interview and test against specifications, mechanisms, activities and individuals, and do not rely on documents alone.
- Machine identities are inside the objectives. Account management, device authentication and authenticator management explicitly cover services and devices, so service accounts, API keys and certificates need the same evidence as people.
- Know which edition your contract uses. 32 CFR Part 170 incorporates SP 800-171 Rev. 2 and SP 800-171A (June 2018), so CMMC Level 2 still runs on the 110 Rev. 2 requirements while Rev. 3 is the current NIST baseline.
What it is and who it applies to
NIST published SP 800-171A Rev. 3, Assessing Security Requirements for Controlled Unclassified Information, as a final publication in May 2024, alongside SP 800-171 Rev. 3. It supersedes the June 2018 SP 800-171A. NIST describes the procedures as flexible: they can be customised to the needs of organisations and assessors, and used for self-assessments, independent third-party assessments or government-sponsored assessments, with rigour set by depth and coverage.
- Nonfederal organisations holding CUI: contractors, subcontractors, research institutions and service providers whose agreements require SP 800-171. The requirements apply to components that process, store or transmit CUI, or that protect those components.
- Federal agencies and their assessors: agencies that write SP 800-171 into contracts use 800-171A to define what they will check.
- Internal audit and readiness teams: the procedures are the most precise test script available for a CUI environment, whatever the external scheme.
- Not covered: the enhanced requirements in SP 800-172 Rev. 3 have their own companion, SP 800-172A Rev. 3. See the NIST SP 800-172 Rev 3 Guide.
Rev. 3 versus the edition CMMC uses
The CMMC rule at 32 CFR 170.2 incorporates by reference SP 800-171 Revision 2 (February 2020, updated January 2021) and SP 800-171A dated June 2018, and defines Level 2 as the 110 Rev. 2 requirements. Rev. 3 contains 97 active requirements in 17 families (the NIST OSCAL catalogue marks the remaining identifiers as withdrawn, mostly folded into other requirements). A defence contractor preparing for CMMC therefore assesses against the 2018 objectives, while an organisation whose agency contract cites the current NIST publication, or that wants to be ready for a future change, works to Rev. 3. Many teams keep one evidence library tagged to both.
| Aspect | SP 800-171A (June 2018), used by CMMC | SP 800-171A Rev. 3 (May 2024) |
|---|---|---|
| Requirement numbering | 3.1.1 to 3.14.7 (CMMC adds labels such as AC.L2-3.1.1) | 03.01.01 to 03.17.03 |
| Requirement count | 110 | 97 active, others withdrawn |
| Families | 14 | 17 (adds Planning, System and Services Acquisition, Supply Chain Risk Management) |
| Organisation-defined parameters | Implicit ("defined" frequencies inside objectives) | Explicit ODPs with their own determination statements |
| Objective labels | 3.1.1[a], 3.1.1[b] | A.03.01.01.a[01], A.03.01.01.ODP[01] |
| Machine-readable form | Spreadsheet and PDF | PDF, HTML and the NIST Cybersecurity and Privacy Reference Tool (CPRT) dataset, plus OSCAL catalogue content |
Structure and key requirements
Every assessment procedure in Rev. 3 has the same parts. Knowing them lets you build an evidence plan that mirrors what the assessor will write down.
- Assessment objective: introduced by "Determine if:", followed by a list of determination statements. Each statement begins with the letter A, which marks it as part of an assessment procedure rather than the requirement text.
- Determination statements: labelled by requirement number and item, with square brackets for further decomposition. For example, Remote Access 03.01.12 item a is split into A.03.01.12.a[01], a[02] and a[03].
- ODP statements: where a requirement contains a parameter, the first statement asks whether it is defined, for example A.03.01.01.ODP[01], "the time period for account inactivity before disabling is defined". Some ODPs are selections from a list of values.
- Potential assessment methods and objects: a list of what to examine, who to interview and what to test. These are suggestions, not a mandatory checklist.
- References: each procedure ends with the source SP 800-53A procedures, which is useful when your organisation already assesses against SP 800-53.
Methods and objects
| Method | NIST definition (summarised) | Typical evidence |
|---|---|---|
| Examine | Reviewing, studying, inspecting or analysing assessment objects | Policy, procedure, SSP section, configuration export, audit records, account list, network diagram |
| Interview | Holding discussions with individuals or groups about assessment objects | System administrators, account managers, developers, security staff explaining how the control operates |
| Test | Exercising assessment objects under specified conditions to compare actual with expected behaviour | Attempting sign-in after the inactivity period, triggering MFA, checking that an unauthorised device is refused |
The objects fall into four types: specifications (documented artefacts such as policies, plans and designs), mechanisms (hardware, software and firmware safeguards), activities (protection actions carried out by people, such as reviews and backups) and individuals (the people applying them). The methods carry depth and coverage attributes, described in SP 800-53A Appendix C, which define the rigour and scope of the assessment.
Findings
Each determination statement receives a finding. "Satisfied" means the objective has been met with a fully acceptable result. "Other than satisfied" means there are potential anomalies that the organisation may need to address, or that the assessor could not obtain enough information to decide. A requirement is only satisfied when all of its determination statements are.
Identity and NHI requirements
The identification and authentication and access control families are where non-human identities most often break an assessment, because the determination statements name services, processes and devices explicitly. The table shows the statements to plan for and the machine identity evidence an assessor can reasonably expect.
| Requirement | What the objectives test | NHI evidence to prepare |
|---|---|---|
| 03.01.01 Account Management | Account types defined, created, enabled, modified, disabled and removed per policy; ODP for inactivity period; notification on changes | Service account inventory with owner and purpose, disabled-on-inactivity setting, ticket trail for creation and removal |
| 03.01.05 Least Privilege and 03.01.06 Privileged Accounts | Only authorised access; privileged accounts restricted to defined personnel or roles | Role mapping for automation accounts, evidence that CI/CD and integration accounts hold no standing domain admin rights |
| 03.05.01 User Identification, Authentication and Re-Authentication | Users uniquely identified and authenticated; processes acting on behalf of users associated with them; re-authentication under the defined circumstances | Mapping of scheduled tasks, agents and bots to an accountable user; no shared generic logins |
| 03.05.02 Device Identification and Authentication | Defined devices or device types are uniquely identified and authenticated before a connection is established | 802.1X or certificate-based device authentication records, device certificate inventory |
| 03.05.03 Multi-Factor Authentication | MFA for access to system accounts as the requirement specifies | Conditional access or IdP policy exports, the documented treatment of non-interactive accounts that cannot use MFA |
| 03.05.05 Identifier Management | Authorisation before assigning identifiers, no reuse within the defined period | Naming standard for service principals and workload identities, reuse rule |
| 03.05.12 Authenticator Management | Identity of the individual, group, role, service or device verified at initial distribution; default authenticators changed at first use; procedures for lost, compromised or revoked authenticators; refresh per ODP | Rotation records for keys, tokens and certificates, vault policies, revocation runbook, proof that vendor default credentials were changed |
| 03.13.10 Cryptographic Key Establishment and Management | Keys established and managed per defined requirements | Key management procedure, KMS or HSM configuration, key ownership |
- Interview the people who run automation: the 03.05.01 procedure lists developers and administrators as interviewees. They are the ones who know which scripts use which accounts.
- Test, do not just describe: showing an assessor that a revoked API key is refused is far stronger than a rotation policy. See the Service Account Security Guide and the Secrets Management Guide.
- Inventory feeds several objectives: the same service account register supports 03.01.01, 03.05.05 and 03.05.12. See the Service Account Inventory Template.
Implementation steps
- Confirm the baseline: read the contract clause and decide whether you are assessed against the 2018 objectives (CMMC, DFARS 252.204-7012 as applied by DoD) or Rev. 3. Record the decision in the SSP.
- Fix the scope: list the components that process, store or transmit CUI and the ones that protect them. An objective-level plan on the wrong scope wastes months. For DoD work see the CMMC Scoping Guide.
- Define every ODP: extract all ODPs from the CPRT dataset or the OSCAL catalogue, assign each an owner and a value (or adopt values your customer has issued), and publish them in one table referenced from policy. Unanswered ODPs fail the first determination statement of the requirement.
- Build an objective register: one row per determination statement, with the method, object, evidence location, owner and last-verified date. Spreadsheets work for small organisations; larger ones import the OSCAL content into a GRC tool.
- Collect evidence by object type: specifications first (policy and SSP text that addresses each statement), then mechanisms (configuration exports, screenshots with timestamps), then activities (records that a review or rotation happened) and individuals (who to interview).
- Run a mock assessment: have someone who did not build the control mark each statement satisfied or other than satisfied, using tests rather than walkthroughs where possible. Treat any statement without a test as a risk.
- Remediate and record: open plan of action entries for anything other than satisfied, with milestones, and update the SSP. See the System Security Plan Template and Guide.
- Keep it current: refresh evidence on a schedule tied to the ODP frequencies (for example log review or account review periods), not just before an assessment.
Evidence and assessment
Assessors look for evidence that is final, dated and attributable. The CMMC scoring rule at 32 CFR 170.24, for example, requires evidence to be final rather than drafts or working papers, and scores a requirement MET only when all applicable objectives are satisfied. The same standard is a sensible default for any SP 800-171A assessment.
| Evidence quality | Weak | Strong |
|---|---|---|
| Account inactivity (03.01.01) | Policy says accounts are disabled after 90 days | ODP table value, directory setting export, report of accounts disabled by the job last quarter |
| Authenticator refresh (03.05.12) | Statement that keys rotate | Vault rotation policy plus the audit log of the last rotation for a sampled key |
| Event logging (03.03.01) | List of logged event types in the SSP | SIEM query showing those event types arriving from sampled in-scope hosts |
| Boundary protection (03.13.01) | Network diagram | Diagram, firewall rule export matched to it, and a test showing a blocked flow |
- Sampling: coverage decides how many objects are checked. Prepare evidence for every in-scope system type, not one perfect example.
- Traceability: label evidence files with the determination statement ID (A.03.05.12.d, for example) so the assessor and your own team can find them.
- Metrics that show readiness: percentage of determination statements with current evidence; percentage of ODPs defined and approved; number of statements supported only by examine (no test or interview); median age of evidence; service accounts in scope with a named owner and a rotation record.
- Continuous monitoring: automate the evidence that changes most often (account lists, MFA coverage, patch state). See the Audit Evidence and Continuous Controls Monitoring Guide.
Mapping to other frameworks
Because each Rev. 3 procedure cites its SP 800-53A sources, the mapping to SP 800-53 is direct. The other mappings below are thematic and confirmed against the framework texts, not official crosswalks.
| SP 800-171 Rev. 3 area | SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| 03.12.01 Security Assessment | CA-02 Control Assessments | ID.IM-01, ID.IM-02 |
| 03.12.02 Plan of Action and Milestones | CA-05 | ID.IM-01 |
| 03.12.03 Continuous Monitoring | CA-07 | DE.CM-01 |
| 03.15.02 System Security Plan | PL-02 | GV.PO-01 |
| 03.05.01 and 03.05.12 identification and authenticators | IA-02, IA-05, IA-11 | PR.AA-01 |
| 03.01.01 and 03.01.05 accounts and least privilege | AC-02, AC-06 | PR.AA-05 |
| 03.04.10 System Component Inventory | CM-08 | ID.AM-01 |
If you also hold ISO/IEC 27001, the objective register can sit beside the Statement of Applicability. See the ISO 27001 Statement of Applicability Template and the NIST SP 800-53A Guide.
Common pitfalls
- Undefined parameters: policies that say "periodically" or "as required" leave the ODP statement unanswered, and the whole requirement fails on its first line.
- Documents without operation: an SSP that describes a control is a specification; assessors also want mechanism and activity evidence, and will test where they can.
- Human-only account evidence: account reviews that export only user accounts miss service principals, scheduled task accounts and API keys that 03.01.01 and 03.05.12 also cover. Unrotated credentials are a recurring cause of real incidents, as the Cloudflare Thanksgiving Breach 2023 showed when credentials left unrotated after an earlier supplier breach let an attacker in.
- Mixing editions: evidence labelled with Rev. 3 numbers in a CMMC assessment, or Rev. 2 numbers in a Rev. 3 contract, slows the assessor and can hide gaps where requirements were merged or split.
- Single-sample evidence: one compliant server does not show coverage across Windows, Linux, cloud and network devices in scope.
- MFA gaps for non-interactive access: service accounts excluded from MFA without a documented, compensating design (certificate or workload identity, network restriction, monitoring) are a common finding. See the MFA Guide.
Practitioner checklist
- Record in the SSP which SP 800-171 and 800-171A edition each contract requires.
- Download the Rev. 3 procedures from CPRT or the OSCAL catalogue and build a register with one row per determination statement.
- Define, approve and publish a value for every ODP, or adopt customer-issued values.
- For each statement, list at least one examine object and, wherever possible, one test.
- Include service accounts, API keys, certificates and devices in account, identifier and authenticator evidence.
- Name the interviewees for each family and brief them on what they will be asked.
- Label every evidence file with its determination statement ID and capture date.
- Run an independent mock assessment and open plan of action items for anything other than satisfied.
- Track evidence age and ODP coverage as standing metrics, reviewed monthly.
Standards and references
- NIST: SP 800-171A Rev. 3, Assessing Security Requirements for Controlled Unclassified Information
- NIST: SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
- NIST: SP 800-171A Rev. 3 (PDF)
- NIST: SP 800-53 Rev. 5
- eCFR: 32 CFR Part 170, Cybersecurity Maturity Model Certification Program
- eCFR: 32 CFR 170.24, CMMC Scoring Methodology
- DoD CIO: About CMMC
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: NIST SP 800-171 and CMMC 2.0 Guide · CMMC 2.0 Level 2 Assessment Guide · CUI Guide · System Security Plan Template and Guide · Audit Readiness for AI Agents and NHIs