> ## Content Index > Fetch the complete content index at: https://www.cmmcoperator.com/llms.txt > Use this file to discover other available public pages before exploring further. # Mosyle and CMMC Level 2: What It Covers and What It Does Not - URL: https://www.cmmcoperator.com/mosyle-cmmc-level-2/ - Published: 2026-08-21T21:14:53.000Z - Updated: 2026-08-22T18:33:32.000Z - Author: HydratedSec - Tags: MDM & Management, macOS CMMC Vendor and CMMC Quick answer: Mosyle is a named contributor to the macOS Security Compliance Project, which publishes a CMMC baseline. That is a real and documented bridge from Mosyle to CMMC Level 2, and it is a bridge to *configuration*, not to a System Security Plan. Mosyle publishes no CMMC or NIST SP 800-171 material of its own, holds no FIPS 140 certificate, and claims no FedRAMP authorization. None of that disqualifies it. It does determine what you have to write down yourself. Everything below is graded by source. **Regulation** means 32 CFR Part 170 or a NIST publication. **Vendor** means Mosyle's own documentation about its own product. **Absence** means a search that returned nothing, which is weaker evidence than a published statement. Checked 2026-08-21\. Vendor posture changes; re-check before you rely on it. ## Is Mosyle connected to any CMMC standard at all? Yes, and more directly than most buyers realise. 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](https://csrc.nist.gov/pubs/sp/800/219/r1/final?ref=cmmcoperator.com). Among its published baselines is one labelled 800-171r2, which is the control set CMMC Level 2 uses. NIST's own mSCP vendor attribution page names eight contributors. Mosyle is one of them, credited for **Mosyle Business: standards-based security controls**, alongside Apple, CIS, Jamf, Tenable, NIWC Atlantic, Qmulos and Addigy. Mosyle's entry on that NIST page reads: "We rely on these resources to provide our customers with easy to implement, standards-based security controls for each entity's hardening and compliance needs." *Grade: regulation, for the NIST publication and the NIST-hosted attribution page.* So the connection is real and it is documented on a NIST domain rather than in marketing. What it establishes is that Mosyle builds against mSCP baselines. It does not establish a CMMC claim, and Mosyle does not make one. ## What does Mosyle actually claim about compliance? From Mosyle's own security page: | Item | Mosyle's position | | ------------- | ------------------------------------------------------------------------- | | SOC 2 Type II | Claimed, achieved 2020 | | GDPR | Claimed | | NIST and CIS | Described as standards the environment is evaluated against | | Data location | All customer data stored in the United States within Azure | | Encryption | Customer data encrypted at rest; client communications encrypted with TLS | | FedRAMP | **Not mentioned** | | FIPS 140 | **Not mentioned** | *Grade: vendor, for everything claimed. Absence, for the two negatives.* The absence of a FedRAMP claim is worth stating carefully. Mosyle's security page does not mention it and a search returned no marketplace listing, but the FedRAMP Marketplace is a JavaScript application whose data endpoint is not reliably readable, so **this is argument from absence rather than a confirmed negative**. The correct way to write it in your own SSP is that the vendor makes no FedRAMP claim. Do not write that the vendor is not authorized unless you have checked the Marketplace yourself on the day. ## Does Mosyle hold a FIPS 140 certificate? No. A CMVP validated-modules search for vendor **Mosyle**, run in advanced mode across all statuses including Historical and Revoked, returns "No certificates match the search criteria". The vendor filter is a case-insensitive substring match, so a zero-result search here is a genuine negative rather than a failure to find the right spelling. *Grade: regulation, verified against CMVP 2026-08-21.* This is unremarkable and it is not a mark against Mosyle. Jamf holds no CMVP certificate either. An Apple device management platform is not normally the thing performing CUI cryptography; on a managed Mac the cryptography is Apple's corecrypto, and the validation question belongs to the operating system and its release, not to the MDM. What matters is that you do not answer the two questions with each other. **A service authorization is not a cryptographic module certificate, and neither substitutes for the other.** If a vendor answers a FIPS question by pointing at SOC 2, or a FedRAMP question by pointing at encryption in transit, that is a non-answer. For the endpoint side of this, see [FIPS validated encryption for CUI](https://www.cmmcoperator.com/fips-validated-encryption-for-cui-why-enabled-is-not-enough/). ## Does using Mosyle put CUI in scope? It depends on your deployment, and this is the question that actually costs money. Under 32 CFR 170.19(c), an MDM that does not process, store or transmit CUI is a **Security Protection Asset**, and a Security Protection Asset is assessed only against the Level 2 requirements relevant to the capabilities provided, rather than all 110\. That is a meaningful reduction. Two caveats travel with it and both apply to Mosyle exactly as they apply to any competitor. - **The external service provider lane is harsher.** 32 CFR 170.16(c)(3)(ii) provides that where the OSA uses a non-CSP ESP, 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 the platform never holds CUI is a per-deployment factual finding.** Device management platforms commonly hold configuration data, logs and sometimes file payloads. There is no blanket answer for any MDM, and Mosyle is not an exception in either direction. The hosting detail is a live input here rather than trivia. Mosyle states customer data is stored in the United States within Azure. If you conclude the platform does handle covered defense information, DFARS 252.204-7012(b)(2)(ii)(D) requires the cloud service provider to meet security requirements equivalent to the FedRAMP Moderate baseline, and that is a different and much larger conversation. If you conclude it does not, write down how you reached that conclusion, because an assessor will ask. Our page on [which Mac tools are ESPs, CSPs, or neither](https://www.cmmcoperator.com/mac-tools-and-cmmc-which-are-esps-csps-or-neither/) works through the categories. ## What Mosyle gives you, and what you still have to write Mosyle's platform covers device management, automated hardening and compliance, endpoint security, patch and OS update management, DNS-level filtering, and identity through Mosyle Auth 2. Mapped against a CMMC Level 2 assessment, that is substantial coverage of the *mechanism* half of a control and none of the *narrative* half. mSCP itself has exactly the same shape, and saying so is not a criticism of either. **mSCP emits configuration profiles, declarative device management assets and compliance scripts. It does not emit SSP narrative.** A tool that inherits mSCP baselines inherits that boundary. It will enforce a setting and prove the setting is enforced. It will not write the paragraph naming who owns the control, which assessment objective it satisfies, and which record an assessor should ask to see. That paragraph is what CA.L2-3.12.4 requires, and CA.L2-3.12.4 is one of six requirements that **32 CFR 170.21(a)(2)(iii) bars from a POA&M entirely**. Enforcement can be remediated later. The system security plan cannot. If you run Mosyle and need the narrative half, [what goes in a CMMC SSP for a Mac fleet](https://www.cmmcoperator.com/cmmc-ssp-mac-fleet/) walks the eight sections, and [what a Mac SSP narrative needs](https://www.cmmcoperator.com/mac-based-ssp-narrative/) covers the sentence pattern. Both are MDM-neutral: the mechanism name changes, the structure does not. ## What to verify yourself before you rely on any of this 1. **Whether your Mosyle tenant holds CUI.** A factual finding about your deployment, not a category answer. It drives everything in the scope section above. 2. **Current FedRAMP Marketplace status.** Check it on the day, not from a blog. Vendor partnership and roadmap language is not certification evidence. 3. **Which mSCP baseline your configuration actually derives from.** mSCP publishes both an 800-171r2 baseline and an 800-171r3 baseline. CMMC currently runs on Rev 2\. A configuration built from the Rev 3 baseline is not wrong, but it is not a one-to-one match for what you will be assessed against, and the terminology will drift when you cross-reference. 4. **The macOS releases in your fleet.** Cryptographic module validation status differs by macOS release and by silicon, and that question belongs to Apple rather than to Mosyle. None of the above says Mosyle is a poor fit for a defense contractor running Macs. It says the platform answers the configuration question and leaves the documentation question open, which is true of every Apple management platform on the market today, including the ones that do publish CMMC marketing. Choosing or reviewing an Apple management platform sits inside a bigger question. [Can Macs be CMMC compliant?](https://www.cmmcoperator.com/cmmc-for-macos/) is the orientation piece for a Mac fleet.