6 min read

Boundary Protection on a Mac Fleet: Applying "Control vs. Protect" to macOS for CMMC L2

Boundary Protection on a Mac Fleet: Applying "Control vs. Protect" to macOS for CMMC L2
Photo by Ramshid / Unsplash

If you spend any time reading Glenda R. Snodgrass' weekly CMMC updates over at The Net Effect, you start to notice a pattern. The hardest part of CMMC Level 2 isn't the technology. It's the discipline of separating the four little verbs that NIST keeps tucking into the controls: define, monitor, control, and protect. Glenda hammered on this in her April 2, 2025 update on SC.L2-3.13.1 (Boundary Protection), and the same lens applies just as cleanly when your endpoints happen to be Macs.

This post takes three of Glenda's recurring themes: boundary protection, external connections (AC.L2-3.1.20), and real multi-factor authentication (IA.L2-3.5.3), and walks through what each one looks like on a managed macOS fleet inside a NIST SP 800-171 Rev 2 scope.

Define, Monitor, Control, Protect on macOS

Glenda's framing of SC.L2-3.13.1 is that "define" means somebody in authority wrote it down, "monitor" means you're actually watching, "control" is the policy or rule, and "protect" is the technical enforcement. Translated to Mac:

Define. Your SSP and network diagram should call out which Macs are in scope (CUI Assets vs. Security Protection Assets vs. Contractor Risk Managed Assets), which MDM tenant manages them (Jamf Pro, Kandji, Mosyle, Intune for Mac, or Apple Business Manager + a profile server), and which Apple IDs/Managed Apple Accounts are permitted. If a Mac isn't enrolled in your MDM, it isn't defined, and an assessor will treat it as out-of-scope or shadow IT.

Monitor. macOS has built-in telemetry that most shops never collect. Pipe Unified Log predicates and Endpoint Security framework events (via an EDR like Jamf Protect, SentinelOne, CrowdStrike Falcon, or Red Canary's Mac telemetry) into your SIEM. Watch for ES_EVENT_TYPE_NOTIFY_OPEN on /Volumes, Gatekeeper assessment failures, XProtect Remediator detections, and sudo events. "Monitoring" without ingestion into something an analyst reads is just logging.

Control. Write the policy: which Macs may reach which networks, which ports egress where, what's allowed to run. Then express it in configuration profiles. macOS gives you a Content Filter payload, a Firewall payload (com.apple.security.firewall and ALF), the PF packet filter under the hood, and per-app Network Extension entitlements you can allow or block via the System Extensions and Network Filter payloads.

Protect. Actually enforce it. Push the profile. Lock it so the user can't disable the firewall. Require a per-app VPN (Always On VPN via an MDM-deployed configuration) for any traffic that touches CUI. Turn on iCloud Private Relay = OFF, AirDrop = Contacts Only or disabled, and Universal Clipboard = disabled via the allowCloudDocumentSync, allowAirDrop, and related restriction keys. That's the "protect" half of SC.L2-3.13.1, done in MDM rather than in a binder.

AC.L2-3.1.20: External Connections, Mac Edition

Glenda calls AC.L2-3.1.20 "the second most important control," and her March 6, 2024 update lays out the six assessment objectives in pairs: connections and use of external systems must be identified, verified, and controlled/limited. On a Mac fleet, the external systems that bite people are almost never the firewall or the VPN. They're the consumer cloud surfaces that ship turned on out of the box.

Run through the AOs the way an assessor would:

Identified. Has someone in authority signed off on a list? iCloud Drive, iCloud Photos, iCloud Keychain, Handoff, Continuity Camera, AirDrop, AirPlay receiver, Find My, Messages in iCloud, Apple Mail with personal accounts, Game Center, Siri analytics, third-party browser sync (Chrome, Firefox, Edge profiles), and personal Apple IDs added to System Settings > Internet Accounts. Every one of those is an external system in 800-171 terms.

Verified. For anything that may touch CUI, the external system has to meet DFARS 252.204-7012 and FedRAMP Moderate (or equivalent). Consumer iCloud doesn't. Apple Business Manager + a GCC High-aligned collaboration suite is a different conversation. If you're tempted to keep iCloud Drive on "for convenience," remember Glenda's note that nearly every assessment she's done has surfaced shadow cloud usage discovered only in interviews.

Controlled/limited. macOS makes this very doable in a configuration profile. The com.apple.applicationaccess payload exposes restrictions like allowCloudDocumentSync, allowCloudKeychainSync, allowCloudPhotoLibrary, allowCloudPrivateRelay, allowAirDrop, allowAirPlayIncomingRequests, allowiPhoneMirroring, allowGameCenter, allowAutoUnlock, allowContinuityHandoff, and allowAddingGameCenterFriends. Set them to false on CUI Macs and supervise the device via Apple Business Manager + Automated Device Enrollment so the user can't strip the profile.

IA.L2-3.5.3: "Real" MFA on macOS

Glenda's March 22, 2021 update on MFA is the one I quote the most often, because she draws the line that auditors actually care about: two passwords is not MFA, and two-step is not two-factor. You need two of the three factors (something you know, have, or are), and IA.L2-3.5.3 requires it for local and network access to privileged accounts, network access to non-privileged accounts, and all remote access.

On macOS this is one of the easier wins, because Apple silicon hardware is genuinely good at the "something you are" and "something you have" factors.

Local privileged access. Touch ID at the login window and for sudo/authorizationdb prompts gives you password + biometric. Enable pam_tid.so in /etc/pam.d/sudo (and /etc/pam.d/sudo_local on Sonoma/Sequoia) and require it via MDM. That's two factors at the local console. For shared admin accounts (which you should be moving away from anyway), use a YubiKey 5C as a smart card with the built-in CryptoTokenKit PIV applet; macOS will treat it as a real smart card and you can pair it to the admin account.

Network access. Bind Macs to your IdP (Entra ID, Okta, Jamf Connect, Kerberos SSO Extension, or Platform SSO on Ventura+) and require phishing-resistant MFA at the IdP - FIDO2 security keys or Platform SSO with Secure Enclave-backed keys. Avoid SMS one-time codes; NIST 800-63B has deprecated them and assessors are increasingly skeptical.

Remote access. If your Macs connect to a CUI enclave (VDI, jump host, or a GCC High tenant), require certificate-based device authentication plus a user MFA challenge at the VPN or ZTNA gateway. The device certificate, enrolled via SCEP/ACME through MDM and stored in the Secure Enclave, is your "something you have." The user's FIDO2 key or Platform SSO assertion is your second factor. Two passwords on two different boxes still isn't MFA.

Enclaves and macOS: When Should You Even Bother Putting CUI on a Mac?

In her May 20, 2025 update, Glenda points back to her enclaves whitepaper and to the idea that scope reduction is the single highest-leverage move in CMMC. That logic cuts both ways for Mac shops. If your CUI workload is small with only a few engineers and a handful of documents, the most defensible architecture is usually a hardened enclave (a GCC High tenant, a CMMC-aligned VDI like V3 or Summit 7, or a dedicated air-gapped Mac mini cluster) accessed from your Macs as Security Protection Assets, not as CUI Assets.

The advantage is that the Macs themselves stop needing to meet every 800-171 control as a CUI Asset; they only need to meet the SPA controls relevant to the enclave they connect to. CUI never lands on local disk, AirDrop and iCloud risks evaporate, and FileVault becomes a hygiene control rather than the bet-the-farm encryption boundary.

If you do need CUI on the Mac itself, treat it like a full CUI Asset: APFS + FileVault with escrowed institutional recovery keys, Secure Token enabled for the admin, SIP and System Extensions locked down, signed/notarized binaries only via Gatekeeper, MDM-enforced screensaver lock at five minutes (3.1.10), and full Unified Log + Endpoint Security shipping to a central SIEM (3.3.1, 3.3.2).

The Net-Net

MacOS is not a barrier to CMMC L2; it's just a different toolchain. Configuration profiles via MDM are how you express "control," Endpoint Security and Unified Logging are how you do "monitor," Apple Business Manager + Automated Device Enrollment is how you "define" the fleet, and FileVault + Secure Enclave + Platform SSO are how you "protect" what you've controlled. The control families don't change when you swap Windows for Mac; only the levers do.

If you want the source material that informed this post, Glenda Snodgrass' archive is genuinely one of the best free CMMC resources on the internet. Read her March 6, 2024 piece on external connections and her April 2, 2025 piece on control vs. protect, then come back and audit your MDM baseline. You'll find at least one gap.

Attribution: Glenda R. Snodgrass' published work informed the framing of this post. Any errors in translating her CMMC guidance to macOS are mine, not hers.