Do Macs and Windows Mean Two Management Planes for CMMC?

Quick answer: you get a second baseline and a second evidence pipeline, but you do not get a second set of policies. That distinction is worth money. The fear that adding Macs doubles your documentation is the most common reason small shops stay Windows-only, and it is mostly wrong. What genuinely doubles is narrower and more manageable than the fear suggests.

Do you need two MDMs for CMMC?

Nothing in 32 CFR 170 or NIST SP 800-171 says anything about how many management platforms you run. The rule is silent on tooling, as it is silent on operating systems.

In practice most mixed fleets end up with two, and the reason is capability rather than compliance. Microsoft Intune manages Macs and holds the stronger government-cloud position. Mac-first platforms manage Macs better and hold no FedRAMP authorization at all. That trade is a real engineering decision, and we work through it in Jamf vs Intune vs Iru for CMMC Mac fleets.

What matters for the assessment is that whatever you run is categorised, documented, and covered. One platform or two, the requirements are the same.

Does a second platform double your policies?

No, and this is the part worth being precise about because almost everyone in this market implies otherwise.

Across all 110 Level 2 requirements, exactly two documents are named as required artifacts: the System Security Plan at 3.12.4 and the plans of action at 3.12.2. Zero policies are named. Zero procedures are named. The convention of one policy per control family is a consulting norm, not a compliance floor, and no primary source imposes it.

Your access control policy states how your organisation controls access. It does not need a Windows edition and a macOS edition. What changes is the implementation detail underneath it, and implementation detail belongs in the SSP narrative and the baseline, not in the policy.

Anyone selling you a second policy set for a second platform is selling you something the rule does not ask for.

What does 3.4.1 require per system type?

Here is where the real duplication lives. NIST SP 800-171 Rev 2 requires you to "establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles." 3.4.2 then requires you to "establish and enforce security configuration settings for information technology products employed in organizational systems."

A baseline configuration is specific to what it configures. A Windows Group Policy baseline says nothing about a Mac, and a macOS configuration profile says nothing about a Windows machine. Two platforms mean two baselines, maintained in parallel, drifting independently, and re-validated separately every time either vendor ships a major release.

That is a genuine, requirement-anchored cost. It is also a much smaller cost than rewriting your policy library.

Where does the real extra work land?

Three places, all of them recurring rather than one-time:

• Baselines. Two hardening standards to select, apply, and keep current. For macOS the usual anchor is the macOS Security Compliance Project.
• Evidence collection. Vulnerability scanning under RA.L2-3.11.2, flaw remediation under SI.L1-3.14.1, and audit logging under the 3.3 family all have to produce dated output for both platforms. Most Windows-centric tooling does not cover Macs properly, so this is where a second pipeline appears.
• Continuous monitoring cadence. CA.L2-3.12.3 requires monitoring on an ongoing basis. Two fleets means proving the cadence held twice over. We covered that in continuous monitoring for a macOS fleet.

Notice what is absent from that list. No new requirements. No new policies. No second SSP. The requirement count is fixed at 110 regardless of how many platforms you run.

How do you write one SSP for both?

The SSP is where the two platforms converge, and 3.12.4 gives you room. It requires plans that "describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems." NIST adds that there is "no prescribed format or specified level of detail for system security plans," and that plans "need not be single documents."

The pattern that survives an assessment is one narrative per requirement with platform-specific implementation stated inside it. For 3.4.2 you describe your configuration management approach once, then state that Windows endpoints are enforced through one mechanism and macOS endpoints through another, naming both baselines.

The failure mode is a narrative written as though the fleet were homogeneous, with the Macs quietly absent. An assessor who finds Macs in the asset inventory and no Macs in the narrative has found a gap, and it is a gap of documentation rather than of security. That is a frustrating way to lose points.

If you are working out which Macs belong in scope at all, start with Mac asset classification for CMMC.

Sources

• NIST SP 800-171 Rev 2, requirements 3.4.1, 3.4.2, 3.12.2, 3.12.4 and the 3.12.4 discussion
• CMMC Assessment Guide Level 2, v2.13, titles for CA.L2-3.12.3, RA.L2-3.11.2, SI.L1-3.14.1
• 32 CFR 170.14(c)(3), 170.19

Verified against primary sources on August 1, 2026. This is not legal advice.