Is a Configuration Profile Evidence? What macOS MDM Actually Proves for CMMC Level 2

The short answer

A configuration profile is not evidence that a control is working. It is evidence that a setting was sent.

Those are different claims, and the gap between them is documented in Apple's own management schemas. The MDM command that lists profiles on a Mac returns the profile's identity and structure. It does not return the values inside the payload, and it does not report what the setting is actually doing on the device.

Apple does attest to real device state, but only for a specific, published, finite list of facts. Everything on that list is strong evidence. Everything off it needs an artifact you produce yourself. This article gives you both lists.

What is a configuration profile, precisely?

Apple defines it as follows:

A configuration profile is an XML file (ending in .mobileconfig) consisting of payloads that load settings and authorization information onto Apple devices.

Source: Apple Platform Deployment, Intro to device management profiles

A payload is the unit inside it that configures one area of the system. Apple characterizes each payload by which operating systems support it, which channel delivers it, whether the device must be supervised, and whether duplicates are allowed.

Source: Apple Platform Deployment, Intro to device management payloads

None of that is controversial. The problem starts when a profile gets handed to an assessor as proof that a control is operating.

What does the ProfileList command actually return?

Apple documents ProfileList as "Get a list of installed profiles on a device."

Apple's example response returns, for each profile: HasRemovalPasscode, IsEncrypted, IsManaged, PayloadContent, PayloadDescription, PayloadDisplayName, PayloadIdentifier, PayloadOrganization, PayloadRemovalDisallowed, PayloadUUID, and PayloadVersion.

Each entry inside PayloadContent returns only PayloadDescription, PayloadDisplayName, PayloadIdentifier, PayloadOrganization, PayloadType, and PayloadVersion.

Source: Apple Developer, Profile List command

Read that second list again. Every field describes the payload. Not one field carries a configured value, and not one field reports the device's current state.

A ProfileList response tells you a profile with a given identifier is installed. It cannot tell you what that profile sets, and it cannot tell you whether the system is honoring it.

What device state can an MDM genuinely attest to?

This is the part most write-ups get wrong, usually in one direction or the other. Apple attests to considerably more than "a profile is installed," and considerably less than "your fleet is compliant."

Two mechanisms report real state, and they are worth understanding separately.

SecurityInfo: a fixed list, on demand, going back to macOS 10.9

SecurityInfo is documented as "Get security-related information about a device."

A trap to avoid: the example response in Apple's developer documentation is an iOS example. Most of its fields, including the passcode ones, are marked not applicable on macOS. Reading that example and assuming it applies will lead you to claim passcode-compliance evidence for a Mac fleet that you do not have.

The macOS fields, from Apple's own command schema, with the macOS version each became available:

Field	Available from	What it attests
FDE_Enabled	macOS 10.9	FileVault is on
FDE_HasPersonalRecoveryKey	macOS 10.9	A personal recovery key exists
FDE_HasInstitutionalRecoveryKey	macOS 10.9	An institutional recovery key exists
SystemIntegrityProtectionEnabled	macOS 10.12	SIP is on
FirewallSettings	macOS 10.12	Firewall state
FirmwarePasswordStatus	macOS 10.13	EFI firmware password state
RemoteDesktopEnabled	macOS 10.14.4	Remote Desktop is on or off
SecureBoot	macOS 10.15	Secure boot settings
AuthenticatedRootVolumeEnabled	macOS 11	Signed system volume protection
IsRecoveryLockEnabled	macOS 11.5	Recovery lock state

Source: Apple's device management schema, information.security.yaml

That list is short and it is genuinely useful. Several entries map straight onto CMMC Level 2 requirements: FileVault to protecting CUI at rest, firewall settings to boundary protection, SIP and secure boot to configuration integrity.

Note the model. These are queried on demand. The MDM asks, and the device answers for that moment.

DDM status reports: subscription-based, and expanding

Declarative Device Management adds a different model. Apple describes it plainly:

Device status reports return information about a device's current state. When a device management service subscribes to status objects, it receives reports about any changes.

Source: Apple Platform Deployment, Declarative status reports

The difference from SecurityInfo is not that one is real state and the other is not. Both are. The difference is that DDM pushes changes as they happen rather than answering a poll, which is a materially better fit for a continuous monitoring obligation.

Status items available on macOS include device identity and OS version from macOS 13, account list items from macOS 13 on the user channel, and from macOS 14 background tasks, FileVault status, and software update. Battery health arrives at macOS 14.4, and OS supplemental build and extra version at macOS 26.2.

Source: Declarative status reports

The gaps matter more than the list:

• Passcode compliance and passcode presence status items are listed for iOS 16, iPadOS 16.1, and visionOS 1.1. Not macOS.
• Installed apps status is iOS, iPadOS, tvOS, and visionOS. Not macOS.
• There is no status item corresponding to com.apple.configuration.diskmanagement.settings. macOS 15 introduced a declarative configuration that restricts external and network storage. Nothing reports back that the restriction is in effect. Note that the disk management namespace does contain diskmanagement.filevault.enabled from macOS 14, so FileVault is covered there. The storage restriction is not.

Source for the status catalog: Apple's declarative status schemas

The rule that follows

If a control maps to a field in the SecurityInfo table above, or to a published DDM status item, your management platform can produce effectiveness evidence for it, and that evidence is Apple-attested.

If it does not, no MDM report proves the control is operating, however the console labels it. That covers most of CMMC Level 2.

Can the user just override the setting?

Not on a properly enrolled Mac, and this is where profiles are genuinely strong.

Apple documents PayloadRemovalDisallowed as "Optional. Supervised only," and its macOS behavior is specific:

OSX versions 10.10 and later honor a true value of the PayloadRemovalDisallowed key to prevent manual removal of profiles installed through an MDM server. Such profiles cannot be removed using the Profiles preference pane, nor the profiles command line tool even when run as root. Only the MDM server can remove such profiles. Profiles installed manually, with PayloadRemovalDisallowed set to true, can be removed manually, but only by using administrative authority.

Source: Apple, Configuration Profile Reference (PDF). This is Apple's legacy reference rather than the maintained DeviceManagement documentation. The key is confirmed current by its presence in Apple's live ProfileList example response, linked above.

Two conditions gate that behavior:

1. Supervision. Devices enrolled through Automated Device Enrollment are automatically supervised, on macOS 10.14.4 and later. Source: About Apple device supervision
2. Enrollment path. For unsupervised devices, Apple states that users on Mac "can do the same thing only if the user knows a local administrator's user name and password." Source: Intro to device management profiles

So the honest claim is narrower than the one usually made. On an ADE-enrolled, supervised Mac with PayloadRemovalDisallowed set, not even root can remove the profile locally. On a manually enrolled Mac, an administrator can. If your fleet mixes both, your evidence has to distinguish them, and most inventory exports do not.

One more caution: Apple says that when a profile is removed, "all of its settings and information are deleted." It does not say the underlying system reverts to a particular prior value. Do not write "the setting reverts to default" in an SSP unless you have tested it for that specific payload.

Source: Use configuration profiles to standardize settings on Mac

What about the profiles command on the Mac itself?

The profiles command-line tool has list, show, and status verbs, and profiles status -type enrollment is the standard way to confirm enrollment and supervision state.

It can output more than the ProfileList MDM command does, including installed payload contents. What it does not do is read back the system's effective setting values, which is a different question from reading back what a profile declares.

A practical caveat: Apple does not publish the profiles man page on the web, and the reachable copies are mirrors of macOS 10.9 and 10.12.6. If you put its output in an assessment package, run man profiles on the macOS version you actually operate, confirm the behavior yourself, and record which version you tested.

What should you actually hand an assessor?

Three artifacts, not one. Each proves a different claim, and the third is the one most organizations are missing.

1. The declaration. Your policy or procedure states the required configuration and who approved it. This proves intent and authority. A profile alone does not establish that anyone decided anything.

2. The delivery record. The MDM report showing the profile or declaration installed on the named asset, with a date. This is what ProfileList gives you. It is legitimate evidence, and it should be labeled as delivery evidence rather than offered as proof the control works.

3. The effective-state record. Something showing the setting is actually in force. Where a SecurityInfo field or a DDM status item covers the control, that query result is your artifact and it is Apple-attested. Where neither covers it, this has to come from an on-device audit.

The macOS Security Compliance Project is the standard route for that third artifact when Apple does not provide it. Its compliance script writes results to a plist at /Library/Preferences/org.BASELINE_NAME.audit.plist and a log at /Library/Logs/BASELINE_NAME_baseline.log, which are file-level artifacts you can collect, hash, and retain.

Source: mSCP, How to generate compliance scripts

Apple itself points to mSCP for CMMC work, describing its outputs as "customized documentation, scripts (logging and remediation), configuration profiles, and an audit checklist based on the baseline used."

Source: Apple, macOS Security Compliance Project

One caution before leaning on it too hard. The mSCP CMMC Level 2 baseline says of itself:

This list is a catalog, not a checklist or benchmark, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios.

Source: usnistgov/macos_security, baselines/cmmc_lvl2.yaml

mSCP is a collaborative open-source project maintained by federal IT security staff from NIST, NASA, DISA, and Los Alamos National Laboratory, published under NIST's GitHub organization and described in NIST SP 800-219 Rev. 1. It generates evidence. It does not confer compliance, and its output is not an assessment determination.

The four sentences to take away

1. A profile in an MDM inventory proves delivery. It does not prove enforcement.
2. ProfileList returns payload metadata only. There is no MDM command that reads back the current value of an arbitrary managed preference.
3. Apple does attest to real device state, through a fixed set of SecurityInfo fields going back to macOS 10.9 and a published catalog of DDM status items. Check your control against both lists before claiming your MDM proves it.
4. For everything outside both lists, you need an artifact from the endpoint itself, plus a written standard saying what that artifact is, who collects it, and how long you keep it.

That last part is documentation, not tooling. No MDM produces it for you.

---