> ## Content Index > Fetch the complete content index at: https://www.cmmcoperator.com/llms.txt > Use this file to discover other available public pages before exploring further. # What mSCP Gives You for CMMC, and What It Does Not - URL: https://www.cmmcoperator.com/what-mscp-gives-you-for-cmmc-and-what-it-does-not/ - Published: 2026-08-06T14:00:00.000Z - Updated: 2026-08-07T02:02:44.000Z - Description: mSCP generates configuration profiles, device management assets, and compliance scripts. It does not generate the SSP narrative an assessor reads. Here is exactly where the gap opens. - Author: HydratedSec - Tags: macOS + CMMC **Quick answer: mSCP gives you the settings, not the story.** The macOS Security Compliance Project generates configuration profiles, device management assets, and compliance scripts. It does not generate the System Security Plan narrative an assessor reads. That gap is where most Mac-first CMMC programmes stall. ## What is the macOS Security Compliance Project? mSCP is a joint project of NIST, NASA, DISA, and Los Alamos National Laboratory, formalized in NIST SP 800-219\. It is worth being precise about that partner list. DISA carries the DoD participation and LANL is a Department of Energy laboratory. Sources that render it as "NIST, NASA, DISA, and DoD" overstate the defence side and drop a national lab. The project lives in the usnistgov organisation on GitHub, which is NIST's official account. It is not a vendor product and nobody sells it to you. ## Does mSCP have a CMMC baseline? Yes, and more than one relevant baseline. mSCP publishes baselines for: - **CMMC**, mapped to NIST SP 800-171 Rev 2. - **NIST SP 800-171 Rev 3**, separately. - NIST SP 800-53, CNSSI 1253, and DISA STIG. - CIS Benchmarks Level 1 and Level 2, and CIS Controls v8. Use the Rev 2 one. 32 CFR 170.14(c)(3) states plainly that "the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2." The Rev 3 baseline exists because NIST moved on. CMMC has not. Building to Rev 3 today means hardening against a standard the rule does not incorporate. Current guidance covers macOS 26 Tahoe, macOS 15 Sequoia, and macOS 14 Sonoma. Check the repository for the current release rather than trusting any date you read in an article, including this one. ## What does mSCP actually output? Three kinds of artifact, all technical: - **Configuration profiles.** The mobileconfig payloads your MDM pushes to enforce a setting. - **Declarative device management assets.** Apple's newer enforcement model, for the settings that support it. - **Compliance scripts.** Scripts that check whether a rule is satisfied on a given machine and report a result. That is genuinely valuable. It is also the reason mSCP ranks first for almost every Mac and CMMC search. If you are choosing between mSCP, CIS, and DISA STIG as your hardening anchor, we compared them in [mSCP vs CIS vs STIG](https://www.cmmcoperator.com/mscp-vs-cis-stig-cmmc-mac-baseline/). ## Why is that not enough for an assessment? Because an assessment is not a configuration audit. 32 CFR 170.24 defines a requirement as MET when "all applicable objectives for the security requirement are satisfied based on evidence." A configuration profile is evidence for some objectives. It is not evidence for most of them. Consider what 3.12.4 asks for. The requirement is specific. Plans must "describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems." mSCP speaks to a slice of the third clause. It says nothing about your boundary, your environment, or your connections. The same gap opens across the audit family. 3.3.1 requires you to "create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity." A compliance script can confirm logging is on. It cannot state what "to the extent needed" means for your organisation. That judgement is yours, and it has to be written down. ## What do you still have to write yourself? Everything that carries an organisation-defined decision, plus everything narrative: - The SSP narrative for each requirement, describing how it is implemented in your environment. - Your boundary and asset categorisation, including which Macs are CUI Assets and which are Security Protection Assets. - Every org-defined value: review frequencies, retention periods, lockout thresholds, update cadence. - The reasoning for any requirement you mark not applicable. - Policies and procedures in final, approved form. The Assessment Guide excludes drafts and "unofficial or unapproved policies" as evidence. That last point deserves emphasis. mSCP output is machine-generated and always current. Your narrative is human-written and goes stale. The two failure modes are opposite, and only one of them is solved by tooling. If you want the shape of the narrative layer before you write it, see [the Mac-based SSP narrative](https://www.cmmcoperator.com/mac-based-ssp-narrative/) and [can Macs be CMMC compliant](https://www.cmmcoperator.com/cmmc-for-macos/). ## Sources - github.com/usnistgov/macos\_security; NIST SP 800-219 - 32 CFR 170.14(c)(3), 170.24 - NIST SP 800-171 Rev 2, requirements 3.3.1 and 3.12.4 - CMMC Assessment Guide Level 2, v2.13 *Verified against primary sources on August 1, 2026\. This is not legal advice.*