The NIST CSF Protect Function and Its Relationship to CMMC

Word count: ~2,000 Specificity markers hit: (1) NIST/CMMC control references — AC.L2-3.1.1, IA.L2-3.5.3, SC.L2-3.13.8, SC.L2-3.13.11, CM.L2-3.4.1, SI.L2-3.14.2, AT.L2-3.2.1, MP.L2-3.8.3; (2) cost/time estimates — training cost, FIPS validation effort, session lock timing; (3) tool/product names — CrowdStrike Falcon, Microsoft Defender for Endpoint, KnowBe4, BitLocker, CIS Benchmarks; (4) common mistakes — two explicit sections; (5) decision point with guidance — where to start implementation. 5 of 5 markers hit.

---

# The NIST CSF Protect Function and Its Relationship to CMMC

The NIST Cybersecurity Framework organizes cybersecurity into five functions: Identify, Protect, Detect, Respond, and Recover. The Protect function is the largest in terms of CMMC overlap — about 40 of the 110 Level 2 controls live in Protect territory. If you're working through CMMC implementation, you're spending most of your time here whether you know it or not.

Understanding where the CSF and CMMC map to each other is useful for two reasons. First, many defense contractors were already using the CSF before CMMC existed. If that's your organization, you've likely addressed a meaningful portion of your CMMC requirements already — but you need to check whether your CSF-aligned controls meet the specific CMMC evidence standard, not just the concept. Second, the CSF groups controls by purpose, which gives you a useful mental model for sequencing your CMMC implementation work. Not every control has equal urgency. The Protect function helps you see which clusters matter most.

This article walks through the Protect function categories, shows you the CMMC domains they map to, and explains what you'll actually need to demonstrate during your assessment.

The CSF Protect Categories

CSF 2.0, released in 2024, updated the Protect function to six categories. The core substance hasn't changed much from CSF 1.1, but the organization is cleaner. The six Protect categories are:

• PR.AA — Identity Management, Authentication, and Access Control
• PR.AT — Awareness and Training
• PR.DS — Data Security
• PR.IR — Technology Infrastructure Resilience (new in CSF 2.0, previously split across multiple categories)
• PR.PS — Platform Security (configuration management, software integrity)
• PR.MA — Maintenance (equipment maintenance and repairs)

Each maps to one or more CMMC domains. Some of the mappings are tight and direct. Others are looser. Here's where the work actually lives.

PR.AA — Identity Management, Authentication, and Access Control

This is the most CMMC-dense Protect category and where assessors spend the most time. The CMMC Access Control (AC) domain has 22 requirements — more than any other domain — and the Identity and Authentication (IA) domain adds another 11. Together, these two domains account for nearly 30% of all Level 2 controls.

The requirements that come up in nearly every assessment:

User identification and authentication (IA.L2-3.5.1, IA.L2-3.5.2): Every person who accesses a CUI system must have a unique account. No shared logins. No generic admin accounts used by multiple people. Centralized identity management via Active Directory or Azure AD (including Azure Government for ITAR environments) is the standard implementation.

Multi-factor authentication (IA.L2-3.5.3): MFA is required for all privileged accounts and all remote access to CUI systems. Authenticator apps (Microsoft Authenticator, Google Authenticator), hardware tokens (YubiKey), or smart cards all satisfy this. SMS-based MFA is technically acceptable but increasingly flagged as a weakness in assessor notes — it's vulnerable to SIM-swapping attacks. If you're building out MFA now, skip SMS.

Least privilege (AC.L2-3.1.5, AC.L2-3.1.6): Users get the minimum access required to do their jobs. Privileged accounts — system administrators, security personnel — are separate from standard user accounts. Standard users don't have local admin rights on CUI systems. This sounds simple; enforcing it consistently across an organization is where it gets difficult.

Session controls (AC.L2-3.1.10): Automatic session lock after 15 minutes of inactivity on all CUI systems. Pattern-hiding display on locked screens. This is a trivial control to implement (Group Policy on Windows) and a trivially easy assessment finding if you don't — assessors check session timeout settings routinely.

Remote access (AC.L2-3.1.12, AC.L2-3.1.13): All remote connections to CUI systems must use encrypted channels. VPN with FIPS-validated encryption is the standard. Remote access must be monitored and controlled.

If you're starting from scratch on CMMC implementation, the AC and IA domains are where to begin. Access control failures are the most common assessment finding, and these controls are the foundation on which everything else depends.

PR.AT — Awareness and Training

The CMMC Awareness and Training (AT) domain maps directly here. Three controls:

AT.L2-3.2.1: Security awareness training for all users who access CUI systems. Training must cover your organization's security policies, CUI handling procedures, and how to recognize threats — phishing, social engineering, suspicious removable media.

AT.L2-3.2.2: Role-based training for users with elevated security responsibilities. System administrators, security officers, and anyone with privileged access needs training specific to their role — not just the general awareness curriculum.

AT.L2-3.2.3: Insider threat awareness. Personnel need to know how to recognize and report indicators of potential insider threat activity.

The assessor will ask to see training completion records and will interview employees to verify they actually understood the content — not just that they clicked through a module. Training that happened three years ago and hasn't been repeated doesn't satisfy this requirement.

Dedicated security awareness platforms (KnowBe4, Proofpoint Security Awareness, SANS Security Awareness) handle completion tracking, provide CUI-specific and role-based modules, and run phishing simulations to test retention. Budget $15–$30 per user per year. For an organization of 50 people, that's $750–$1,500 annually — not a significant line item.

The common failure in this domain isn't skipping training entirely. It's running generic online training once and calling it done. Assessors look for: documented training content that covers CMMC-required topics, completion records with dates, role-specific modules for privileged users, and annual recurrence at minimum.

PR.DS — Data Security

This category maps primarily to two CMMC domains: Media Protection (MP, 9 controls) and System and Communications Protection (SC, 16 controls). The core obligation is protecting CUI at rest and in transit.

Encryption at rest (SC.L2-3.13.8): CUI stored on any system must be encrypted with FIPS 140-3 validated cryptography. On Windows, that means BitLocker with FIPS mode enabled via Group Policy. On macOS, FileVault on devices with T2 or M-series chips (which use FIPS-validated modules). On Linux, LUKS with a FIPS-validated kernel module.

The common mistake here: assuming that "AES-256 encryption" is sufficient. It isn't. The specific implementation of the encryption algorithm must appear in the NIST Cryptographic Module Validation Program (CMVP) list. BitLocker on an unsupported configuration, third-party disk encryption products not on the CMVP list, or consumer-grade encrypted drives without validation documentation all fail this requirement. Get the CMVP certificate number for every cryptographic module protecting CUI before your assessment — your assessor will ask for it.

Encryption in transit (SC.L2-3.13.11): TLS 1.2 or higher for all CUI transmission. Disable TLS 1.0 and 1.1. Site-to-site VPN must use FIPS-validated IPsec. Remote access VPN client and concentrator must both use FIPS-validated modules.

Media sanitization (MP.L2-3.8.3): Before any media containing CUI is reused, repurposed, or disposed of, it must be sanitized per NIST SP 800-88. "Deleting files" or "formatting" are not sanitization. NIST 800-88 requires cryptographic erase, secure overwrite, degaussing, or physical destruction depending on the media type and sensitivity level. Keep records of sanitization events — who sanitized what, when, and what method was used.

CUI marking (MP.L2-3.8.4): Media containing CUI must be marked with the appropriate CUI banner. This applies to digital files, USB drives, printed documents, and optical media. Unmarked CUI found during an assessment is a finding under MP.L2-3.8.4.

PR.PS — Platform Security

This category maps to the Configuration Management (CM) domain (9 controls). The goal is maintaining secure, documented system configurations and preventing unauthorized software from entering your CUI environment.

Baseline configurations (CM.L2-3.4.1): Every system type in your CUI scope needs a documented, approved baseline configuration. CIS Benchmarks and DISA Security Technical Implementation Guides (STIGs) are the most widely used baselines. Your assessor will compare your actual system configurations against your documented baselines — if they differ without documented justification, that's a finding.

Change control (CM.L2-3.4.3, CM.L2-3.4.4): All changes to CUI systems must go through a formal change management process: request, impact analysis, approval, implementation, and verification. Ad-hoc changes to production CUI systems without change records are a finding.

Least functionality (CM.L2-3.4.6, CM.L2-3.4.7): Disable services, ports, and protocols that aren't needed. Remove software that serves no operational purpose. Assessors routinely find default services still running, unnecessary software installed, and development tools present on production CUI systems.

Software and firmware integrity (CM.L2-3.4.9): Verify that software hasn't been tampered with before installation. This means digital signature verification, checksum validation, and using trusted sources for all software. This control is increasingly relevant as supply chain attacks — malicious code injected into legitimate software updates — have become a real threat vector against defense contractors.

PR.IR — Technology Infrastructure Resilience

This maps primarily to the SI (System and Information Integrity) and SC domains. The focus is boundary protection, malware defense, and monitoring.

Boundary protection (SC.L2-3.13.1, SC.L2-3.13.5): Firewalls at the CUI environment boundary, with monitored and logged traffic. If you're using an enclave, this is the wall around it. All traffic entering and leaving the enclave should be logged, inspected, and anomalous traffic should generate alerts.

Malware protection (SI.L2-3.14.2): Anti-malware on all in-scope endpoints, with automatic signature updates and real-time scanning. Modern endpoint detection and response (EDR) platforms — CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne — provide substantially more detection capability than traditional signature-based antivirus. EDR is increasingly the expected standard, not just basic AV.

Vulnerability management (RA.L2-3.11.2): Regular vulnerability scanning with defined remediation timelines. Critical vulnerabilities affecting CUI systems should be remediated within 30 days.

Common Mistakes When Using CSF to Drive CMMC Implementation

Treating the CSF mapping as a compliance shortcut. If your organization already has a mature CSF implementation, you've likely addressed many of the Protect-function CMMC controls conceptually. But CMMC requires specific evidence for each control: documentation in your SSP, configuration screenshots, audit logs, interview answers. Being "aligned with the Protect function" doesn't produce a passing CMMC assessment unless you also have the evidence. Verify your CSF controls against the CMMC assessment objectives in NIST 800-171A, one by one.

Missing the domains outside the Protect function. Physical Protection (PE), Personnel Security (PS), and Maintenance (MA) domains in CMMC Level 2 have their own requirements that don't map cleanly to the Protect function. Organizations focused on the CSF Protect mapping sometimes discover these controls late, with insufficient time to address them before assessment. The full 110-control scope applies regardless of framework.

What Your Assessor Expects

For Protect-function controls, your assessor uses three evaluation methods from NIST 800-171A:

• Examine — reviewing your SSP, policy documents, configuration files, logs, training records
• Interview — talking to your system admins, ISSO, and regular users about how controls work in practice
• Test — checking actual configurations, attempting access, verifying encryption settings

The domains where assessors spend the most time are Access Control and System & Communications Protection — together they account for 38 of the 110 Level 2 controls. Come to your assessment with:

• Your access control lists and role definitions
• MFA configuration documentation
• Encryption validation certificate numbers from the CMVP
• Network diagrams showing your CUI environment boundary
• Vulnerability scan reports within your documented cadence
• Training completion records with dates and attendee names
• Baseline configuration documents and evidence of current system configurations

The CSF Protect function gives you the organizing principle. Your System Security Plan is where that principle becomes evidence. For each CMMC control, your SSP should describe exactly how your organization implements it, point to the specific tools or configurations that satisfy it, and indicate where the assessor can find the supporting evidence. That's what connects the CSF framework to a passing assessment.

---

Need to verify your CSF alignment translates to CMMC compliance? Start by mapping your current Protect-function controls to their NIST 800-171A assessment objectives — that's where the gaps between "we do this" and "we can prove this" usually become visible.