NIST 800-171 Explained: Requirements & Compliance

If your organization handles federal contract data and you work with the Department of Defense, NIST SP 800-171 is the cybersecurity standard you are required to meet. This article breaks down what NIST 800-171 actually requires, which version applies to you today, how it connects to CMMC, and what practical compliance looks like across your entire device fleet, including Apple devices that most compliance guides ignore entirely.

What Is NIST 800-171 and Who Must Comply?

NIST SP 800-171, published by the National Institute of Standards and Technology, defines security requirements for protecting Controlled Unclassified Information (CUI) in non-federal systems and organizations. In plain terms: if you are a defense contractor, subcontractor, or any company in the Defense Industrial Base (DIB) that stores, processes, or transmits CUI on your own systems, NIST 800-171 applies to you.

The obligation is contractual. The DFARS clause 252.204-7012 requires DoD contractors to implement NIST 800-171 and report cyber incidents within 72 hours. DFARS 252.204-7019 adds a self-assessment requirement, including submission of a score to the Supplier Performance Risk System (SPRS).

Three conditions trigger applicability:

1. You are a non-federal organization (a contractor, subcontractor, or commercial entity)

2. Your systems process, store, or transmit CUI

3. You operate under a DoD contract that includes the relevant DFARS clauses

CUI is broader than many teams assume. It includes technical data, export-controlled information, sensitive acquisition information, and other categories defined in the CUI Registry. If a contract deliverable involves any of this, your systems are in scope.

The 14 NIST 800-171 Control Families Explained

Revision 2, the version currently enforced by the DoD, organizes 110 security requirements across 14 control families. Each family addresses a distinct domain of security practice. Understanding what these NIST frameworks actually require at a technical level is the starting point for any realistic compliance program.

Here is a breakdown of all 14 families with their requirement counts:

The families with the highest technical complexity and the most direct device-level dependencies are Access Control, Configuration Management, Identification and Authentication, and System and Communications Protection. These four families account for 58 of the 110 requirements and are where endpoint configuration choices directly determine your compliance posture.

Access Control requires that you limit system access to authorized users and devices, control the flow of CUI, and enforce least privilege. These controls translate directly to MDM-enforced device policies.

Configuration Management requires baseline configurations, restrictions on unauthorized software, and documented change control. This is where device management best practices and configuration enforcement through MDM are not optional additions but core compliance mechanisms.

Identification and Authentication requires multi-factor authentication for privileged accounts and remote access, password complexity enforcement, and authenticator management.

System and Communications Protection covers encryption of CUI in transit and at rest, network segmentation, and secure remote sessions.

NIST 800-171 Rev 2 vs Rev 3: Which Version Applies?

NIST released Revision 3 of SP 800-171 in May 2024. Rev 3 restructures the framework significantly: it consolidates to 97 requirements across 17 control families, introduces outcome-based "determination statements" for assessors, and aligns more tightly with NIST SP 800-53 Rev 5.

However, the DoD has not yet updated DFARS to mandate Rev 3. As of 2026, Rev 2 remains the contractually enforced version for active DoD contracts. You should track Rev 3 developments closely because the DoD will transition eventually, but building your compliance program around Rev 2 today is the right call for contract performance.

Key differences between the two revisions:

• Requirement count: Rev 2 has 110 requirements; Rev 3 has 97 (consolidation, not reduction in scope)
• Control families: Rev 2 has 14; Rev 3 has 17 (some families were split for clarity)
• Assessment approach: Rev 3 uses determination statements that specify exactly what an assessor will look for
• Alignment: Rev 3 maps more precisely to NIST 800-53 Rev 5 and supports CMMC 2.0 Level 2 alignment
• Scoping guidance: Rev 3 provides more explicit guidance on defining the assessment boundary

For practical purposes: maintain your Rev 2 SSP and SPRS score now, and begin mapping Rev 3 gaps in parallel so you are not caught flat-footed when the DoD transition occurs.

NIST 800-171 vs CMMC: How They Connect

CMMC 2.0 (Cybersecurity Maturity Model Certification) is the DoD's third-party verification program built on top of NIST 800-171. The relationship is direct: CMMC Level 2 requires compliance with all 110 NIST 800-171 Rev 2 requirements. The difference is how compliance is verified.

Under the current DFARS self-assessment model, you calculate your SPRS score (ranging from -203 to 110) and submit it. Under CMMC Level 2, a Certified Third-Party Assessor Organization (C3PAO) independently verifies your implementation before you can bid on certain contracts.

The CMMC Level 2 assessment is built around the same 110 requirements. If you are building a genuine NIST 800-171 compliance program today, you are simultaneously preparing for CMMC Level 2 assessment. The two are not separate work streams.

CMMC Level 3, which applies to the most sensitive programs, adds 24 requirements from NIST SP 800-172 on top of the 110.

SPRS Scoring and DFARS Obligations

Your SPRS score is a numerical representation of how many of the 110 NIST 800-171 requirements you have fully implemented. The scoring methodology comes from NIST Handbook 162 and the DoD Assessment Methodology:

• Each requirement has a point value (1, 3, or 5 points) based on risk impact
• Full compliance with all 110 requirements yields a score of 110
• Each unimplemented requirement subtracts its point value from 110
• Partially implemented requirements get no credit under the basic methodology
• The minimum possible score is -203

You are required to submit your score to SPRS via the PIEE portal before being awarded certain DoD contracts. Submitting a score you cannot substantiate is a legal risk under the False Claims Act. If your score is not 110, you need a Plan of Action and Milestones (POA&M) that documents what is not yet implemented and your timeline to close the gaps.

System Security Plan and POA&M Documentation

Two documents anchor every NIST 800-171 compliance program:

System Security Plan (SSP): The SSP describes your system boundary, the CUI you handle, how each of the 110 requirements is implemented, and which systems, people, and processes are in scope. It is the primary evidence artifact. NIST provides an SSP template, but most organizations build their own that reflects their actual architecture.

Plan of Action and Milestones (POA&M): Every requirement that is not fully implemented goes into the POA&M with a description of the gap, the planned remediation, responsible owner, and target completion date. The POA&M is a living document. An auditor or C3PAO will scrutinize both documents closely.

Common SSP mistakes that create audit risk:

• Defining the system boundary too broadly, pulling in systems that do not touch CUI
• Claiming requirements are "implemented" based on purchased tools rather than verified configurations
• Failing to update the SSP when systems or processes change
• Describing controls at a policy level without documenting the specific technical implementation

Scoping your CUI environment carefully is the single most effective way to reduce compliance burden. If you can isolate CUI handling to a specific enclave (a set of systems with a defined boundary), only those systems are in scope. This is worth the architectural effort.

Endpoint Compliance: The Gap Every Windows-Focused Guide Misses

The overwhelming majority of NIST 800-171 guidance is written for Microsoft environments. That creates a real problem for organizations with Apple devices in their fleet, which is an increasingly common situation as Mac adoption in enterprises has grown steadily. Contractors with engineers, security analysts, or executives on macOS endpoints still need to demonstrate compliance across every device that touches CUI.

Endpoint-level controls directly map to multiple NIST 800-171 families:

• Access Control (AC.1.001, AC.1.002): MDM-enforced screen lock, device encryption, and session timeout policies
• Configuration Management (CM.2.061, CM.2.062): Baseline configurations deployed via MDM, software installation restrictions, and configuration drift detection
• Identification and Authentication (IA.3.083): MFA enforcement for device access and remote sessions
• System and Information Integrity (SI.1.210, SI.1.211): Malware protection, vulnerability scanning, and timely patching
• Audit and Accountability (AU.2.041, AU.2.042): System event logging and log integrity

For macOS endpoints, native capabilities like FileVault (disk encryption), Gatekeeper (application control), and the built-in firewall map directly to specific requirements. The question is whether those capabilities are consistently enforced and whether you can prove it. An endpoint hardening guide built around specific NIST 800-171 control mappings removes the guesswork.

For remote workers on Apple devices, remote device management becomes a compliance requirement, not just an operational convenience. You cannot claim AC or CM controls are implemented on remote endpoints without a management channel that can verify and enforce policy.

How Iru Approaches NIST 800-171 Compliance

NIST 800-171 compliance requires two things working together: you have to enforce the controls, and you have to prove you enforced them. Iru addresses both through Iru Endpoint and Iru Compliance as a unified platform or as separate products, depending on where your organization is today.

Iru Endpoint for control enforcement on Apple devices:

Iru Endpoint is built for Apple-first environments. For NIST 800-171, this means direct enforcement of requirements that competitors assume will be handled by Microsoft tooling:

• Blueprint-based configuration management deploys and enforces baseline security configurations on every Mac and iPhone in scope. Configuration drift triggers automated remediation, which is what CM.2.061 actually requires.
• FileVault and device encryption policies are enforced at enrollment and verified continuously. This addresses SC.3.177 (encryption of CUI at rest) for Apple endpoints.
• Managed Gatekeeper policies restrict unauthorized software execution, addressing CM.2.062.
• Automated OS and application patching closes the SI.1.211 gap that most teams handle inconsistently.
• Real-time device compliance status gives you the documentation trail that an SSP narrative needs to be credible.

For teams managing mixed Mac and Windows fleets, Iru's integration capabilities allow you to maintain a unified compliance view without running separate toolchains. Understanding how device management works at a technical level is useful context for seeing how MDM enforcement translates directly to NIST control satisfaction.

Iru Compliance for control mapping and audit evidence:

Iru Compliance maps your controls to NIST 800-171 requirements and collects evidence continuously, rather than as a scramble before an assessment. Specific capabilities relevant to 800-171:

• Pre-built NIST 800-171 control framework with requirement-level mapping
• Automated evidence collection from Iru Endpoint and integrated third-party tools, so device compliance data flows directly into your audit evidence without manual export
• SSP and POA&M documentation support, with gap tracking that feeds directly into your SPRS score calculation
• Continuous controls monitoring so you know your compliance posture in real time, not just at assessment time

The enforcement data that Iru Endpoint generates becomes the evidence that Iru Compliance surfaces for auditors. That connection matters because a C3PAO will ask for proof of implementation, not just policy documentation. When device configuration data, patch status, and encryption state flow automatically into your compliance record, the SSP stops being a document you maintain manually and starts being a live reflection of your actual environment.

Practical Steps to Achieve NIST 800-171 Compliance

Here is a realistic implementation sequence for a team starting or improving their NIST 800-171 program:

1. Define your CUI boundary. Identify which systems store, process, or transmit CUI. Limit scope aggressively. Systems outside the boundary do not require NIST 800-171 controls.

2. Conduct a gap assessment. Evaluate your current implementation against all 110 requirements. Be honest about partial implementations, they count as zero in SPRS scoring.

3. Calculate your SPRS score. Use the DoD assessment methodology. Submit to PIEE. If your score is below 110, that is expected, document it accurately and create a credible POA&M.

4. Write or update your SSP. Document your system boundary, architecture, and how each requirement is implemented. Be specific about technical controls, not just policy intent.

5. Enforce endpoint controls through MDM. For every in-scope device, baseline configurations, encryption, and patch management must be enforced and verifiable, not self-reported by users.

6. Implement multi-factor authentication. MFA for privileged access and all remote access is a hard requirement under IA.3.083. This is one of the highest-weighted requirements in SPRS scoring.

7. Set up logging and monitoring. AU family requirements need centralized log collection and review. This is commonly under-implemented and creates significant SPRS score impact.

8. Address your POA&M systematically. Prioritize by point value impact on your SPRS score, starting with the highest-weighted gaps.

9. Prepare for a C3PAO assessment. If CMMC Level 2 applies to your contracts, engage a C3PAO early. They will look for evidence of implementation, not just documentation of intent.

Building a Sustainable NIST 800-171 Compliance Program

NIST 800-171 compliance is not a one-time certification. Your SPRS score reflects your posture at a point in time, but the requirement is continuous implementation. Systems change, employees join and leave, configurations drift, and new vulnerabilities emerge. Compliance automation is what separates teams that maintain compliance from teams that only demonstrate it during assessments.

For Apple device fleets specifically, the gap between policy documentation and actual enforcement is where most audits surface problems. An MDM solution with continuous compliance reporting closes that gap. When your SSP says "FileVault is enforced on all in-scope endpoints," you need a system that can prove it today, not reconstruct evidence after the fact.

NIST 800-171 gets more tractable when control enforcement and compliance evidence live in the same platform. Iru offers device management and compliance as separate products or together as one, whichever matches where your organization is today. Book a demo.