What Goes in a CMMC SSP for a Mac Fleet, Section by Section

Quick answer: the eight sections of a CMMC System Security Plan do not change because your endpoints are Macs. What changes is the content of six of them. This page walks the standard SSP outline section by section and states what a Mac fleet has to put in each one, and where the Apple-specific answer differs from the Windows one an assessor has probably read fifty times.

Why can a CMMC SSP never be placed on a POA&M?

Because 32 CFR 170.21(a)(2)(iii) names it. Six requirements are barred from a POA&M outright: AC.L2-3.1.20, AC.L2-3.1.22, CA.L2-3.12.4, PE.L2-3.10.3, PE.L2-3.10.4 and PE.L2-3.10.5. CA.L2-3.12.4 is the system security plan.

Every other gap in your environment has a deferral path. This one does not. An SSP that is thin, stale or wrong on assessment day cannot be fixed with a milestone date, which makes it the single artifact with no second chance.

Two further constraints shape what goes in it. Evidence must be in final form and not draft: 32 CFR 170.24(b)(1) states that unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. And the SSP is the only place your scope is written down. SPRS captures the CAGE codes covered and the name, date and version of the SSP, per 32 CFR 170.17(a)(1)(i)(E) and (F). It does not capture a boundary description. A prime checking your SPRS entry sees a status against CAGE codes, not which enclave was certified. The SSP is the artifact that says what was actually assessed.

Section by section: what changes when the fleet is Macs

1. System Identification

Name the macOS releases in the fleet, not just "macOS". Apple's cryptographic module validation status differs by release and by silicon, and an assessor who knows that will ask which versions you run. Version spread is a finding waiting to happen if the SSP says only that endpoints are Apple.

Mac angle: state the release floor you enforce and the mechanism that enforces it. "macOS 15 or later, enforced by managed software update declaration" is a system identification statement. "We use Macs" is not. See FIPS validated encryption for CUI for why the release number matters here.

2. System Environment

This is where the Apple stack gets named: the MDM, the identity provider, the patch and update source, the endpoint security agent. Two things are worth stating precisely because most SSPs get them loose.

Identity. If you are relying on Apple Platform SSO, the supported identity providers are narrow. Jamf's technical documentation states that only Okta and Microsoft Entra ID support Platform SSO, and Google has published no first-party Platform SSO support for Workspace on macOS. Write what your IdP actually does, not what the category is capable of.

Hosting. Say where the management plane runs and who operates it. That determination drives section 3, and getting it wrong there is more expensive than getting it wrong here.

3. System Boundary

This is the section that decides the size of your assessment, and it is where Mac fleets most often go wrong.

Under 32 CFR 170.19(c), an SSO or MDM that does not process, store or transmit CUI is a Security Protection Asset, and Security Protection Assets are assessed only against the Level 2 requirements relevant to the capabilities provided, not all 110. That is a real reduction in scope. Two caveats have to ship with it.

• The ESP lane can be harsher. 32 CFR 170.16(c)(3)(ii) provides that where the OSA uses a non-CSP external service provider, the ESP services used to meet OSA requirements are assessed within the scope of the OSA's assessment against all Level 2 security requirements.
• Whether your MDM never holds CUI is a per-deployment finding, not a category. MDMs commonly hold configuration data, logs, and sometimes file payloads. There is no blanket answer, and asserting one in an SSP is asserting something you have not checked.

Scope can also be an enclave rather than the whole enterprise. The Level 2 Scoping Guide addresses the use of enclaves, and properly encrypted CUI transiting enterprise networking does not by itself extend scope. Note for precision: "enclave" is not a defined term in 32 CFR 170.4, though the Scoping Guide uses it.

For which Mac tools land in which category, see which Mac tools are ESPs, CSPs, or neither.

4. CUI Data Types and Handling

The trap here is platform-independent but it bites Mac shops that build tidy automation. Category markings are mandatory only for CUI Specified. 32 CFR 2002.20(b)(2)(ii) leaves category markings on CUI Basic to agency policy, and DoDI 5200.48 provides for banner and footer marked "CUI" with no required Basic-versus-Specified distinction.

The operational consequence: any handling workflow that reads the category marking to decide what to do will fail on the DoD documents you actually receive, which are frequently banner-marked only CUI. If your Mac fleet routes files by label, say in this section what happens when the label is absent.

5. Personnel and Roles

Name the Affirming Official. 32 CFR 170.22 requires an annual affirmation by a named person, and that person is accountable for the accuracy of what this document says.

Then be careful about delegation. The CMMC Assessment Guide for Level 2 provides that satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider, and that a requirement is considered MET if adequate evidence is provided that the enterprise or ESP implements the requirement objectives. Delegation of the work is permitted. Delegation of the evidence obligation is not. If your Macs are managed by an MSP, this section says who produces the artifact when an assessor asks.

6. Control Implementation Narratives

The largest section, and the one where the Mac fleet creates genuine extra work rather than different work.

NIST SP 800-171 Rev 2 requirements 3.4.1 and 3.4.2 require baseline configurations and enforced security configuration settings per system type. A second platform is therefore a second baseline, a second enforcement mechanism and a second evidence pipeline, under the same policy. That is the honest reason a mixed fleet costs more to document than a single-platform one, and it belongs in this section rather than being discovered during the assessment.

Write the statements in a fixed shape. What a Mac SSP narrative needs covers the pattern: owner, mechanism, present-tense action, defined scope, and the record that proves it.

7. Continuous Monitoring

The strongest single citation for an ongoing obligation is CA.L2-3.12.3, which requires monitoring security controls on an ongoing basis, including assessing control effectiveness. It is not a one-time activity and it is not satisfiable for macOS endpoints by a Windows-only toolchain.

Requirements that recur and therefore compound per fleet include RA.L2-3.11.2 vulnerability scanning, CA.L2-3.12.1 security control assessment, SI.L2-3.14.3 security alerts and advisories, SI.L2-3.14.6 monitoring communications for attacks, and SI.L2-3.14.7 identifying unauthorized use. State the cadence and the tool for the Mac half explicitly.

8. Attachments and References

Asset inventory, network diagram, data flow diagram, and the policies each narrative points at. Two rules govern what can go here.

First, final form only. A draft policy attached to an SSP is not evidence. Second, the assessment objectives are what get assessed: NIST SP 800-171A criteria are authoritative, and one NOT MET objective fails the entire requirement. Attach what the objectives call for, not everything you own.

Worth stating carefully: the disclaimer that the lists of potential assessment objects are not a required artifact checklist appears in 800-171A, not in the CMMC Assessment Guide. Attribute it correctly if you cite it.

What does mSCP give you, and what does it not?

The macOS Security Compliance Project is a joint project of NIST, NASA, DISA and Los Alamos National Laboratory, published as NIST SP 800-219 Rev. 1, "Automated Secure Configuration Guidance from the macOS Security Compliance Project (mSCP)". It publishes a CMMC baseline labelled 800-171r2, an 800-171r3 baseline, and baselines for 800-53, CIS Level 1 and 2, CIS Controls v8, CNSSI 1253 and DISA STIG.

It is the best free starting point for section 6, and it stops short of finishing it.

mSCP emits configuration profiles, declarative device management assets and compliance scripts. It does not emit SSP narrative. It will tell you and prove to you that a setting is enforced. It will not write the paragraph that says who owns the setting, why it satisfies a specific assessment objective, and which record an assessor should ask for. That paragraph is the deliverable, and it is the gap between having a hardened fleet and having a defensible SSP.

One terminology note that a knowledgeable reader will check: write "NIST, NASA, DISA and LANL". LANL is a Department of Energy laboratory. DoD participation is genuine and it comes through DISA.

What does an assessor actually do with this document?

Reads it before arriving, and uses it to decide what to examine, whom to interview and what to test. Assessors have explicit discretion: the CMMC Assessment Guide for Level 2 provides that assessors exercise judgment in determining when sufficient and adequate evidence has been presented.

Which is the argument for writing this document as though it will be read by someone deciding how hard to look. A precise SSP narrows the search. A vague one widens it.

One last piece of context that is worth knowing and is often stated wrongly: CMMC added no controls. 32 CFR 170.14(c)(3) states that the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2. What changed is verification and evidence burden: third-party certification instead of self-attestation, formalised scoping documented in inventory, SSP and network diagram, POA&M limits with a 180-day closeout, and the annual affirmation. Anyone telling you CMMC expanded the control set is wrong.