Mac Asset Classification for CMMC: CUI Asset, SPA, CRMA, or Out of Scope?
Every Mac in your environment lands in exactly one of five scoping categories before a CMMC Level 2 assessment: CUI Asset, Security Protection Asset (SPA), Contractor Risk Managed Asset (CRMA), Specialized Asset, or Out-of-Scope Asset. The categories come from the CMMC scoping rule (32 CFR 170.19), and the classification you can defend - not the one you would prefer - decides which machines face all 110 requirements, which need documentation only, and which the assessor never looks at.
Classification is also the biggest cost lever you control. Every Mac inside the boundary carries the full weight of the program: FileVault and FIPS questions, session lock, audit logging, MDM enforcement, evidence. Every Mac you can honestly place in CRMA or out of scope is cost that never lands. This guide walks the decision in order, with the Mac-specific judgment calls at each step. (Unsure what counts as CUI in the first place? Start with CUI vs. FCI; keep the acronym glossary open for the alphabet soup.)
The decision in one pass
Work each Mac through these questions in order and stop at the first yes.
| Question | If yes | Assessment impact |
|---|---|---|
| 1. Does it process, store, or transmit CUI - in practice, not just on paper? | CUI Asset | Assessed against all 110 requirements |
| 2. Does it provide security functions or capabilities to the CUI environment? | Security Protection Asset | Assessed against the requirements relevant to the capability it provides |
| 3. Could it reach CUI, but your policies and controls keep it from doing so? | Contractor Risk Managed Asset | Documented in inventory, SSP, and network diagram; not assessed if the documentation holds |
| 4. Is it government-furnished, IoT, OT, test equipment, or a restricted system? | Specialized Asset | Documented like a CRMA; not assessed against the other requirements |
| 5. None of the above? | Out-of-Scope Asset | No documentation requirements - but be ready to show the separation |
Step 1: Does the Mac actually touch CUI?
"Process, store, or transmit" is broader than most owners expect, and observed use beats stated intent. If CUI is opened, edited, rendered, cached, synced, or received on a Mac - even once, even against policy - that Mac is a CUI Asset.
The traps that reclassify Apple fleets:
- Browser-only access still counts. Viewing a CUI document in Safari renders it locally: browser cache, the Downloads folder, Quick Look previews. "We only view it in SharePoint" does not keep a Mac out of this category.
- AirDrop and Messages. One engineer AirDropping a controlled drawing to a colleague’s MacBook just moved that MacBook into scope.
- iCloud Desktop & Documents sync. If it is on and CUI lands in either folder, iCloud is now storing and transmitting CUI - a scoping problem much bigger than the endpoint.
- Mail.app. An account that receives CUI-bearing mail caches it locally by default.
A yes here is final: the Mac is assessed against all 110 requirements, and nothing later in the tree pulls it back out.
Mac angle: the working question is rarely "is CUI on this Mac?" but "can I prove CUI never lands here?" MDM restrictions on AirDrop and iCloud, managed browser download policies, and blocking consumer services on scoped segments are what make a "no" defensible.
Step 2: Does it protect the CUI environment?
Security Protection Assets provide security functions or capabilities to the assessment scope, whether or not CUI ever touches them. They are in scope and assessed - but only against the requirements relevant to the capability each one provides.
On a Mac-first fleet, the usual SPAs:
- The MDM. Jamf, Intune, Kandji - it enforces FileVault, session lock, and software restrictions on your CUI Assets, which is security capability by definition.
- The identity provider handling authentication into the enclave (Entra ID, Okta, Platform SSO configuration).
- Admin workstations. The Mac your admin uses to sign in to the MDM or IdP console provides security capability to the environment. This is the one that surprises people - and it is why admin consoles deserve dedicated, hardened machines.
- Anything holding security protection data: log collectors and SIEM, EDR consoles, backups of CUI-system configurations.
Mac angle: whether your cloud MDM sits inside the boundary, and what its FedRAMP posture needs to be, is its own contested question - the MDM comparison covers hosting model and boundary posture per vendor.
Step 3: Could it reach CUI, but doesn’t?
Contractor Risk Managed Assets are the workhorse category for mixed Mac fleets: machines that can, but are not intended to, process, store, or transmit CUI, because security policy, procedures, and practices keep them away from it. Think developer and creative Macs on the corporate network with no business inside the enclave. The rule does not force you to physically or logically separate CRMAs from CUI Assets - that is exactly what makes the category useful, and exactly why assessors read it skeptically.
CRMA is not a free pass. Four things keep the classification alive under assessment:
- The Mac appears in your asset inventory, categorized as CRMA.
- It appears in the SSP, with the risk-based policies that manage it described.
- It appears on the network diagram of the assessment scope.
- The "not intended to" story has real controls behind it: no enclave credentials, conditional access that excludes the device, blocked shares, DLP rules - something you can show, not just assert.
If the documentation holds up, CRMAs are not assessed against the 110 requirements. If it raises questions, the assessment team can run a limited check - and what turns up can become findings or pull the machine into scope as a CUI Asset. The honest test: if an assessor sat down at that Mac, could its user open the CUI library? If yes, your story needs to be about technical prevention, not trust in people.
Mac angle: conditional-access policies that shut non-enrolled or non-compliant Macs out of the CUI tenant are the cleanest CRMA evidence on Apple fleets - the machine cannot get in, and the policy screenshots prove it. BYOD Macs almost never survive this test; the BYOD guide covers why.
Step 4: Is it a Specialized Asset? (Rare for Macs)
Specialized Assets are type-based: government-furnished equipment, IoT, operational technology, restricted information systems, and test equipment. They are documented in the inventory, SSP, and network diagram and managed under your risk-based policies, but not assessed against the other requirements. One precedence caveat: the category is checked by type, not use - a government-furnished Mac that touches CUI is still a Specialized Asset. It sits this late in the tree only because it is so rare on Apple fleets.
The plausible Mac cases: a Mac Pro dedicated to driving lab or test instrumentation, a Mac embedded in an OT or manufacturing cell, or GFE issued under a specific contract. If you catch yourself wanting to call an ordinary MacBook "specialized" to keep it out of scope, that is the wrong tool - the category you are reaching for is CRMA, and it comes with the documentation duties above.
Step 5: Out of scope, and the VDI nuance
An Out-of-Scope Asset cannot process, store, or transmit CUI and provides no security protection to the assessment scope. In a mixed environment that means real separation - physical (separate networks) or logical (VLANs, firewall rules, separate identity tenants) - clean enough that the boundary is obvious on the network diagram. Out-of-scope assets carry no documentation requirements, but expect to explain the separation logic that puts them there.
The nuance Apple shops care about most: virtual desktops. Under the scoping rule, an endpoint that reaches CUI only through a VDI client - configured so nothing is processed, stored, or transmitted locally beyond keyboard, video, and mouse - is treated as out of scope. That makes the pattern of Macs reaching a Windows 365 or AVD enclave genuinely attractive: CUI stays in the virtual environment and the MacBook is a dumb terminal.
"Configured" is doing all the work in that sentence. Any one of these quietly breaks the KVM-only posture and turns the Mac into a CUI Asset:
- Clipboard redirection out of the session
- Drive mapping or file transfer in either direction
- Printing from the session to a local printer
- Local caching or offline mode in the client
- Screenshots of session content - permitted by default on every Mac unless you manage it
If the VDI carve-out is your scoping strategy, the enforcement - and the configuration evidence proving it - belongs in your evidence library before anyone asks.
Where the classification lives
A classification only counts when it is written down in the three artifacts assessors read side by side - and they have to agree:
- Asset inventory - every asset, its category, its owner. The master list.
- System Security Plan - the scope narrative, with CRMAs and Specialized Assets described alongside the risk-based policies that manage them.
- Network diagram - the boundary, the separation logic, and where each category sits.
Drift between the three is one of the most common documentation findings: the inventory says CRMA, the diagram shows the machine inside the enclave VLAN, and the SSP never mentions it. Reconcile all three every time an asset changes category - the SSP guide covers how the scope narrative should read.
Member discussion