CMMC Compliance

CMMC Mobile Device Management: What’s Required, What Isn’t, and How to Prove It

By The Defense Compliance Report Editorial Team · Last reviewed July 2026 · Last verified: July 10, 2026

Editorial research — not formally reviewed by a CMMC Subject Matter Advisor. Verify scope and applicability with a Registered Practitioner (RP), a Registered Provider Organization (RPO), or a qualified federal-contracts attorney before acting.

CMMC does not require any contractor to buy mobile device management (MDM) software. What Level 2 requires is outcomes: mobile devices that process, store, or transmit CUI must be identified; their connections authorized, monitored, and logged (AC.L2-3.1.18); and the CUI on them encrypted (AC.L2-3.1.19) with FIPS-validated cryptography (SC.L2-3.13.11), per NIST SP 800-171 Rev. 2 and the CMMC Level 2 Assessment Guide. MDM is one way to deliver those outcomes. Blocking mobile CUI access entirely is another.

That distinction — outcome versus product — is where most CMMC mobile device management advice goes sideways, usually because the company writing it sells the product. This page takes the other route: the actual rule text, linked, plus the decision framework the rule text doesn’t give you. And there’s a clock on this one. The two mobile-labeled requirements carry a combined potential Level 2 score deduction of eight points, neither can ride the CMMC assessment POA&M as a NOT MET requirement, and FIPS 140-2 validations remain Active only through September 21, 2026before moving to the CMVP Historical list — a transition that lands seven weeks before Phase 2 begins on November 10, 2026. We’ll show you exactly what that does and doesn’t mean.

First, the answer for your situation:

CMMC mobile device management: the direct answer by situation

The right CMMC provider isn’t the same for every contractor — the category you need (a C3PAO, an RPO, an MSSP, a GRC platform, or a CUI enclave) depends on your required CMMC level, whether you handle FCI or CUI, your assessment type, your cloud and IT environment, and your contract timeline. Because a general answer can’t resolve those for you, use The Defense Compliance Report’s Find My CMMC Path tool to map your situation to the right provider category before you request quotes — and do not submit CUI, drawings, or sensitive contract details.

Does CMMC require mobile device management?

No CMMC requirement obligates a contractor to purchase a product called mobile device management. At Level 2, NIST SP 800-171 Rev. 2 requires that mobile devices handling CUI be identified, their connections authorized, monitored, and logged, and the CUI on them encrypted. The official CMMC Level 2 Assessment Guide presents an MDM solution as an example implementation — not as the requirement itself.

This matters because the market talks about “CMMC-compliant MDM” the way it once talked about “HIPAA-compliant email” — as if the product were the certification. It isn’t. There are three separate claims a vendor conversation tends to collapse into one:

1. The product has a capability. (Intune can enforce encryption. True.)
2. You enabled and correctly configured that capability. (Different question entirely.)
3. The configuration satisfies the assessment objective across your actual scope, and you can prove it with evidence. (This is the only claim an assessor cares about.)

Only the third one gets you through a Level 2 assessment. The first one is a datasheet.

So when does MDM become the practical answer anyway? When you genuinely need people working with CUI on phones or tablets and you have more than a handful of devices, MDM (or its cousin, enterprise mobility management) is how you inventory devices, gate access behind an approval, push encryption and configuration, revoke a lost phone at 11 p.m., and — critically — export the logs and configuration reports an assessor will ask for. NIST SP 800-124 Rev. 2, the government’s own mobile security guidance, treats centralized device management as the backbone technology for exactly these jobs, and it draws a distinction worth memorizing: MDM/EMM manages the device, MAM (mobile application management) manages individual apps, and MTD(mobile threat defense) detects attacks. Vendors blur those three constantly. NIST doesn’t, and neither should your System Security Plan (SSP).

And when is the better answer no mobile CUI at all? When mobile access isn’t operationally necessary, when only two or three people ever touch CUI, when your workforce would revolt at device management, or when a secure workstation already covers the job. Denying the path is a fully legitimate implementation — the Assessment Guide tests whether connections are controlled, and “controlled” includes “blocked.” You just have to prove the block works, which we’ll get to.

When is a phone, tablet, or laptop actually in CMMC scope?

A device enters CMMC scope based on what it can do with FCI or CUI — not who owns it or what it’s called. Under 32 CFR § 170.19 and the official CMMC Level 2 Scoping Guide, assets that process, store, or transmit CUI are CUI Assets assessed against all applicable Level 2 requirements — and “process” includes CUI being accessed, entered, edited, generated, manipulated, or printed.

Read that definition again, because it quietly ends the most popular mobile rationalization in the DIB: “they can only view it, they can’t download it.”Viewing is access. Access is processing. A phone that can open a CUI attachment is doing something the Scoping Guide calls processing, whether or not the file ever “saves.”

Behavior-to-scope mapping

Three consequences fall straight out of that table.

Ownership doesn’t decide scope — and neither does never displaying CUI.A company-owned phone may be an Out-of-Scope Asset only when it cannot process, store, or transmit CUI, does not provide security protections for CUI Assets, and is physically or logically separated from them. That second condition trips people: a phone that never shows CUI but runs your authenticator app or a device-management console may still be doing security-protection work, which is its own scoping category. Meanwhile, a personal phone with the corporate mailbox on it — where engineers occasionally email drawings — is in the CUI conversation no matter whose name is on the bill.

Email is the vector that catches people.Not the exotic stuff — Outlook and Teams on personal phones, installed years ago, quietly syncing a mailbox that a prime’s program office occasionally drops CUI into. If your CUI environment includes email, every mail-enabled device is part of the scoping conversation. That includes the edge cases nobody documents: lock-screen notification previews that render message text, attachment previews that create temporary local copies, OS-level backups that sweep app data into a personal cloud account, and the clipboard. You don’t have to declare each of these compliant or fatal on day one — you have to tracethem, because your assessor’s questions will follow the data, not your org chart.

Laptops don’t escape on a technicality.People love to argue about whether a laptop meets the “mobile device” definition (the Rev. 2 discussion’s examples are smartphones, e-readers, and tablets). Skip the semantics: a laptop that processes, stores, or transmits CUI is a CUI Asset assessed against all applicable requirements regardless of the label — and the Assessment Guide’s own discussion of encrypting CUI on mobile computing platforms uses laptop full-disk encryption as its example. The category debate changes nothing about your obligations.

One useful nuance from the Scoping Guide before we move on: the rule also defines Contractor Risk Managed Assets — assets that can but are not intended tohandle CUI, managed through your risk-based policies rather than assessed against every requirement. Some contractors try to park BYOD phones there. Be careful. CRMAs still must be documented in the SSP, and if your documentation raises questions, the assessor can conduct a limited check. A phone where CUI-bearing email actually lands isn’t “not intended to” handle CUI — it’s handling it. The CRMA lane is for genuinely incidental capability, not for wishful thinking.

What do AC.L2-3.1.18 and AC.L2-3.1.19 require — and what are they worth?

AC.L2-3.1.18 (“Control connection of mobile devices”) requires that mobile devices processing, storing, or transmitting CUI are identified, their connections authorized, and their connections monitored and logged. AC.L2-3.1.19 (“Encrypt CUI on mobile devices and mobile computing platforms”) requires those devices and platforms to be identified and the CUI on them encrypted. Under the CMMC Scoring Methodology codified at 32 CFR § 170.24, 3.1.18 is a five-point requirement and 3.1.19 is a three-point requirement.

Objective-by-objective map — The Defense Compliance Report’s original synthesis of the requirement text, the NIST SP 800-171A objectives, the § 170.24 scoring values, and the operational evidence that answers each objective — verified July 10, 2026.

Now the arithmetic, stated precisely because it matters: AC.L2-3.1.18 carries a five-point deduction and AC.L2-3.1.19 carries a three-point deduction. SC.L2-3.13.11 is a separately assessed requirement worth five points where encryption is absent, three where encryption exists but isn’t FIPS-validated. If all three distinct requirements are independently assessed NOT MET, the combined deduction can reach 13 points — not because “mobile” is a scoring category, but because a mobile blind spot tends to leave several separately assessed requirements unsupported at once. The wireless requirements phones ride on (AC.L2-3.1.16 and 3.1.17) are five-pointers too, and configuration baselines (CM.L2-3.4.1/3.4.2), MFA (IA.L2-3.5.3), and media transport encryption (MP.L2-3.8.6) all reach into a mobile deployment depending on architecture. The two mobile-labeled controls are the tip, not the iceberg.

On reporting, two lanes that shouldn’t be blurred: for the separate NIST SP 800-171 DoD Assessment process, DFARS 252.204-7019 requires offerors to have current summary-level scores in the Supplier Performance Risk System (SPRS), with DFARS 252.204-7020 governing that assessment methodology. For CMMC itself, an organization enters Level 2 self-assessment results in SPRS directly, while C3PAO certification results flow through the CMMC instantiation of eMASS into SPRS. Same destination, different doors.

The part that surprises people: you can’t park these on the assessment POA&M.

Under 32 CFR § 170.21, a Level 2 assessment POA&M — the mechanism for a Conditional CMMC Status — is available only when the score is at least 0.8 of the total (88 of 110), only for requirements worth one point, and never for the six requirements prohibited outright under § 170.21(a)(2)(iii). At five and three points, AC.L2-3.1.18 and AC.L2-3.1.19 don’t qualify as NOT MET entries. One distinction keeps this honest: the Department’s CMMC FAQ (Revision 2.3, May 2026) separates the assessment POA&M from an Operational Plan of Action— the vehicle for temporary deficiencies that arise after initial implementation, which, when the conditions in 32 CFR § 170.24 are satisfied, can be assessed MET. Translation: a properly documented temporary deficiency in a working program is survivable; walking into an assessment with mobile never implemented is not.

Which mobile operating model should you choose?

Choose the least complex model that still supports the mission. Block mobile CUI access when employees don’t operationally need it; issue company-owned managed devices when they do; permit BYOD only when you can carry its evidence and privacy burden; and consider a KVM-only virtual desktop design when shrinking the endpoint boundary is worth the architecture work. Each path can support a conforming implementation when all applicable requirements are met and evidenced — none guarantees an assessment result.

Before the matrix, let’s put our own interest on the table. The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance, and we may earn referral compensation when we match readers with providers — so here’s our editorial judgment, stated against that interest: many small contractors don’t need to hire anyone or buy anything for mobile. If your people can live without CUI on their phones, an enforced conditional-access block — backed by the configuration export, the denied-access logs, and a dated negative test — is cheaper, cleaner to scope, and easier to defend than any platform or engagement on this page. When you take that path, there’s no referral for us to earn. Which is exactly why you can trust us on the rest of it: when mobile access genuinely is mission-necessary, the work below is real, half-measures cost more than doing it right, and the difference between a defensible deployment and an expensive mess is mostly decided before anyone buys a license.

CMMC Mobile Access Decision Matrix v1.0 — verified July 10, 2026

Method: mapped each operating model against the Level 2 asset categories in 32 CFR § 170.19, the AC.L2-3.1.18 and 3.1.19 assessment objectives, SC.L2-3.13.11, and the Department’s current VDI scoping FAQ. The “likely scope treatment” column is editorial application of those official definitions — not a formal scope determination. Confirm material scope decisions with an RP/RPO or qualified counsel.

If you’re X, start with Y:

• A 45-person machine shop, two or three CUI users, no real mobile need→ Model 1. Block it, retain the configuration and denied-access evidence, reconcile exceptions, update the SSP and data-flow diagram, and retest on a defined cadence.
• A field-service contractor whose technicians work CUI on tablets→ Model 2 is usually the cleanest starting point at that exposure level; a qualifying VDI or another fully evidenced architecture can also work.
• A distributed professional-services firm where BYOD is culturally non-negotiable→ Compare Models 4 and 5 seriously before conceding to Model 3.
• A contractor trying to shrink a sprawling Level 2 boundary → Model 5, or a CUI enclave architecture that concentrates CUI where phones can’t reach it.
• Anyone currently living in Model 6→ Block the path this week. Then decide like an adult with the pressure off.

On cost, honestly:what holds stable is the structure: Model 1 costs configuration and testing hours; Model 2 adds hardware, licensing, and ongoing management labor; Models 3–4 trade hardware dollars for policy engineering and legal/privacy review; Model 5 trades endpoint costs for infrastructure and user-experience costs. And one contract-reading rule that outperforms any price comparison: if the statement of work doesn’t assign the evidence production — logs, tests, SSP updates, data-flow updates — to either the provider or you, the engagement is underscoped, whatever the number says. Where mobile fits in your total budget picture, our CMMC Level 2 cost guide breaks down the full spend.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

Can BYOD meet CMMC requirements?

CMMC contains no categorical prohibition on bring-your-own-device. But when a personal device processes, stores, or transmits CUI, the organization must apply and prove the applicable NIST SP 800-171 Rev. 2 requirements on hardware it does not own — which makes BYOD substantially harder to evidence than a company-owned device or a qualifying KVM-only virtual desktop design.

The real BYOD question was never “is it allowed.” It’s whether you can honestly answer ten operational questions on somebody else’s phone:

Who approves the device before it connects? Who can see its compliance state? What identifies it in your inventory? What happens when an employee refuses management — or quietly unenrolls? What data may enter local storage? How do you demonstrate encryption on hardware you can’t image? Where do the connection logs live, and who reviews them? What happens at termination? What happens when it’s lost at an airport? And can you lawfully sustain all of that monitoring under your state’s employment and privacy landscape?

Answering all ten with documents and logs is necessary, not sufficient — BYOD is workable only when the complete set of applicable requirements is implemented and evidenced across your actual scope. But if three or four of those answers are shrugs today, you already know what the assessor will find.

Management model comparison: full-device MDM vs. work profile / container (MAM)

Will the assessor demand to inspect employees’ personal phones?We won’t promise you a universal assessment procedure — nobody honestly can. What we can tell you is how the methodology works: NIST SP 800-171A assessments run on examine, interview, and test. Your job is to design the environment so the objectives can be proven through your records, configurations, and demonstrations — sampled enrollments, policy exports, log pulls — without anyone improvising with an employee’s phone on assessment day. Contractors who plan the evidence approach during assessment scoping don’t end up in that room.

The privacy and employment-law edge case deserves its own callout:a technically sound BYOD design can still be a bad organizational decision if you can’t lawfully and consistently obtain consent, monitor required settings, revoke access, and handle departing employees. That’s a counsel conversation, not an IT ticket. Have it before enrollment, not after the first dispute.

An illustrative scenario (not a case study)

Labeled illustrative because it is — we constructed it from the official scoping rules, not from a client engagement.

A 45-person machine shop runs Microsoft 365 in a government cloud tenant. Three managers want Outlook on their personal iPhones. Engineering drawings live in a controlled SharePoint library. Four choices, four very different pages of the SSP:

• Unmanaged Outlookon those iPhones: if the phones process, store, or transmit CUI, they’re CUI Assets — and unless each device is separately identified, its connection authorized, and those connections monitored and logged, one or more AC.L2-3.1.18 objectives will be assessed NOT MET. (Model 6. Don’t.)
• MAM-restricted Outlook: data-transfer controls, conditional access, and container encryption to document — plus a written scope rationale, because the phones are still accessing CUI.
• Company phones for the three managers: three devices, a full evidence chain, a clean ownership story, roughly a hardware line-item plus licensing.
• KVM-only virtual desktop access: the iPhones may drop out of scope entirely — if, and only if, every condition in the VDI section below holds.

Notice what decided it in every branch: not the brand of software — the data flow and the evidence. That’s the whole game.

Is MAM enough without full-device MDM?

Mobile application management can enforce real, assessable restrictions — approved apps, conditional access, blocked copy/save/print, remote corporate-data wipe. What it cannot do is automatically move the endpoint out of CMMC scope: the Scoping Guide’s definition of processing includes CUI being accessed, so a phone displaying CUI inside a container is still an asset in your analysis.

Think of MAM as a strong answer to “how do we control the data,” and a weak answer to “is the device in scope.” Two different questions.

What MAM helps you prove:approved applications and versions; authentication and conditional access in front of them; data-transfer restrictions between managed and unmanaged apps; blocked copy/paste, save-as, and print; managed “open in” behavior; selective corporate-data revocation; user-and-device association; access logs.

What MAM alone typically can’t prove:the full device inventory and health; the absence of every local cache and notification-preview exposure; device-wide encryption posture; every screenshot and backup path; whether the endpoint should be categorized out of scope. Those gaps aren’t fatal — they’re the parts your SSP rationale and complementary controls have to carry explicitly.

The authorization trapis where MAM deployments can fail 3.1.18, and it’s subtle. Objective [b] requires mobile device connections to be authorized. Some MAM deployments authenticate the user, permit the app— and then let a brand-new device register the moment that user signs in, with no separately evidenced device-authorization decision. User authentication alone does not prove device authorization. Fix the gap with device-registration approval or compliant-device conditions, and keep the exception records.

Before you rely on a MAM architecture in an assessment, run this eight-step test and file the dated results:

1. Unapproved user attempts an approved app — blocked?
2. Approved user attempts an unapproved app — blocked?
3. Approved user, brand-new unregistered device — what happens, and who approved it?
4. Copy from a managed app to an unmanaged app — blocked?
5. Save an attachment to local storage — blocked?
6. Print or screen-capture from the container — blocked or logged?
7. Revoke one test device — do tokens and corporate data actually go?
8. Pull the connection and enforcement logs for steps 1–7 — can you find them in under ten minutes?

If all eight hold, you have dated evidence for those tested conditions — a real foundation, not yet a complete compliance determination. That’s still miles ahead of a license invoice.

Can VDI keep a phone or tablet out of CMMC scope?

Yes — conditionally, and the conditions are exact. Under the CMMC Level 2 Scoping Guide and the Department’s CMMC FAQ, Revision 2.3 (F-A1/F-A2), an endpoint hosting a VDI client is an Out-of-Scope Asset when it is configured — and verified — to allow no processing, storage, or transmission of CUI beyond the keyboard, video, and mouse data of the session. The VDI-hosted environment and its supporting assets remain in scope per their applicable asset categories.

The conditions, listed in full, straight from the FAQ — not summarized:

• Video renders to the endpoint; keyboard and pointer input return to the hosted session. The VDI transmits only video, keyboard, and mouse data — that’s the entire permitted exchange.
• The virtual desktop server blocks copy-paste, file transfers, and any other data exchange across the session.
• No copying — including screenshots — and no saving or printing CUI on the endpoint (except within a NIST SP 800-171-compliant system).
• No local drive mounting or other features that invoke system protocols beyond the basic VDI protocol; convenience features that cache data or connect the virtual desktop to the local file system or printers must be disabled on the server side, where the user can’t toggle them back.
• Users log into the virtual desktop and handle CUI entirely within the session.
• Multifactor authentication to the VDI server is separate from the unmanaged client — the FAQ’s examples are a hardware one-time-password token or a PKI token with a password or PIN.
• Only authorized users may access the virtual desktop environment, and access is restricted to allowable locations.

Then prove it the boring way: export the server-side configuration, attempt each prohibited action from a real endpoint, and file the dated failures. An architecture diagram plus negative tests is what turns “our vendor says the phone’s out of scope” into a rationale an assessor can accept.

Two honesty notes, because this section attracts the most optimistic vendor claims on the internet. First: the virtual desktops, the identity service, the cloud environment, the logs, and the administrative plane behind the VDI all remain in scope according to their applicable asset categories — you moved the boundary, you didn’t shrink the obligation. Second: some virtual-mobile vendors state that their architecture is officially equivalent to VDI for scoping purposes. Treat that as what it is — a provider statement. The Scoping Guide and FAQ language is what your assessor reads; verify the specific implementation against every condition above rather than adopting marketing as scope law. And note the FAQ’s separate-MFA condition does double duty: a KVM-only endpoint decision doesn’t relax authentication anywhere else — our CMMC MFA requirements guide has the full IA.L2-3.5.3 matrix.

The FIPS problem on phones — and what actually changes after September 21, 2026

SC.L2-3.13.11 requires FIPS-validated cryptography whenever cryptography is what protects the confidentiality of CUI — and “validated” means the specific cryptographic module holds a certificate from NIST’s Cryptographic Module Validation Program (CMVP), not that the product uses an approved algorithm. FIPS 140-2 validations remain Active through September 21, 2026; after that date, CMVP moves the remaining FIPS 140-2 validations to the Historical list.

Mobile is where this requirement gets fumbled, for a specific reason: on a phone, you usually didn’t pick the cryptographic module. The OS vendor did. And here’s the rule that keeps you honest: mobile OS vendors and device manufacturers publish CMVP validations for specific modules, versions, and operational environments— so never infer fleet coverage from a brand name. An Apple logo, an Android version, or a device family proves nothing by itself; certificates attach to exact module versions, which means exact OS builds, and your fleet updates monthly. “The iPhone encrypts by default” is a true sentence and an empty evidence artifact. What an assessor can use is: module name, CMVP certificate number, the OS versions it covers, and a fleet report showing your devices sit inside that coverage — written into the SSP.

Three vocabulary distinctions that separate passing evidence from marketing copy:

• FIPS-validated— the module passed CMVP testing and holds a certificate. This is what 3.13.11 asks for.
• “FIPS-compliant” / “FIPS inside”— vendor language meaning “we used approved algorithms” or “we embed someone’s validated module.” Sometimes fine, never self-proving. Chase the certificate.
• FIPS mode enabled— a configuration switch. It restricts algorithm choice; it does not conjure a certificate for the module underneath.

The scoring consequence sits right in 32 CFR § 170.24: SC.L2-3.13.11 costs five points where encryption isn’t employed at all, three points where encryption exists but isn’t FIPS-validated. It’s one of the few requirements the rule scores in shades — which tells you how often the validation half goes missing.

The September 2026 transition — precisely, because most coverage of it is either silent or shrill:

• Historical is not revoked.NIST’s own guidance says CMVP supports continued purchase and use of Historical modules for existing systems. A phone fleet running on a 140-2-validated module on September 22 does not become non-compliant plaintext overnight.
• But NIST’s existing-systems allowance is written for federal agencies — the CMMC rule contains no blanket contractor pass.What holds up is specificity: record the exact module, certificate number, version, validation status, where it’s deployed, and the vendor’s 140-3 transition plan in your SSP. If continued use rests on a temporary deficiency, document it through the Operational Plan of Action treatment the rule and FAQ C-A9 recognize.
• For new architectures, prefer modules with an Active FIPS 140-3 validation.A submission, a “module in process” listing, a roadmap, or a vendor promise is not a completed CMVP validation — it’s a plan.
• The calendar is unkind.The Historical transition lands seven weeks before Phase 2 begins on November 10, 2026. Contractors entering C3PAO assessments that winter will be explaining their cryptographic module posture in the exact quarter the ground shifted. The ones with certificate numbers and a documented transition plan in the SSP will have a five-minute conversation. The ones with “AES-256” in a spreadsheet will not.

For the full treatment, see our CMMC FIPS 140-2 requirements guide and the broader CMMC encryption requirements guide. For this page’s purposes, the mobile takeaway fits in one sentence: identify the module, capture the certificate, match your OS versions, and date the file.

Which CMMC level applies — and does Level 1 need MDM?

Your required CMMC level and assessment type come from the solicitation and the resulting contract: the solicitation provision at DFARS 252.204-7025 identifies the required CMMC level before award, and the contract clause at DFARS 252.204-7021 (effective November 10, 2025) carries it into performance with maintenance, annual affirmation, and flowdown obligations. Level 1 covers FCI using the 15 basic safeguards of FAR 52.204-21, which never names MDM; Level 2 applies all 110 NIST SP 800-171 Rev. 2 requirements to CUI.

One versioning footnote: NIST has since superseded the February 2021 edition of SP 800-172, but the 2021 edition remains the one incorporated into 32 CFR Part 170 — it controls CMMC Level 3 until the Department amends the rule. Full breakdown of the levels and paths on our CMMC levels guide, and the self-assessment-versus-certification fork on Level 2 Self vs. C3PAO.

Why this section exists: overbuying. FCI-only suppliers can get quoted a full Level 2 mobile stack before anyone confirms applicability. Before any mobile purchase, confirm two facts from the paperwork: what status the provision and clause require, and what information your people actually touch. Phase 2 begins November 10, 2026 and expands Level 2 C3PAO requirements in applicable solicitations — but the solicitation tells you which status it demands. Anyone who says otherwise is selling the calendar, not reading it.

Do Intune, GCC High, or any platform make you compliant — and does your MDM need FedRAMP?

No platform makes an organization CMMC compliant by itself. Microsoft Intune, Omnissa Workspace ONE, Ivanti Neurons for MDM, and their peers can support the required outcomes, but the assessed result depends on configuration, scope, shared responsibilities, logs, and evidence. As for FedRAMP: per DFARS 252.204-7012 and the Department’s CMMC FAQ, a cloud service that stores, processes, or transmits CUI must meet the FedRAMP Moderate baseline or DoD’s equivalency requirements — and whether your MDM crosses that line depends on what it can actually touch.

Platform facts we checked (as of July 10, 2026)

Public-record checks, not sponsored placements.

Does your MDM itself need to be FedRAMP authorized?

The regulatory decision has three branches, straight from the clause, the Scoping Guide, and the Department’s FAQ:

1. If the cloud service processes, stores, or transmits CUI→ it must meet the FedRAMP Moderate baseline, either through a FedRAMP-Moderate-authorized offering or one meeting DoD’s December 2023 equivalency memo requirements. And note the FAQ’s blunt corollary: encrypting the CUI first does not exempt the cloud— a non-FedRAMP-Moderate offering may not store even encrypted CUI.
2. If it handles Security Protection Data but no CUI — the classic MDM posture: device inventories, compliance states, policy configurations — it’s in scope as a Security Protection Asset, assessed within yourassessment against the requirements relevant to what it does. Such ESPs don’t need their own CMMC certification, but they don’t escape your assessment either.
3. If it touches neither CUI nor Security Protection Data→ it doesn’t meet the CMMC definition of an External Service Provider at all.

The editorial layer, clearly labeled as our judgment: branch 2 holds only as long as the deployment matches it. Some MDM/MAM configurations can pull file inventories, capture screenshots for support sessions, proxy content, or route data in ways that arguably doprocess CUI — and then you’re in branch 1 whether you meant to be or not. Document, in the SSP, exactly what your management platform can see and touch; if the honest answer includes CUI, choose an offering that satisfies branch 1.

If the platform decision is tangled up with a bigger tenant question — commercial 365 versus GCC High, enclave versus whole-environment — compare the source-checked GCC High and enclave providers we’ve already profiled. Or, if you’d rather start from your situation than from a vendor list, get matched with source-checked provider options that fit your level, scope, and timeline.

What should a CMMC mobile device policy contain?

A defensible mobile device policy describes the operating model your organization actually enforces — not an aspirational template. It should define permitted devices, users, and information; the authorization workflow; encryption and configuration requirements; monitoring and log review; prohibited transfers; lost-device response; offboarding; exceptions; evidence owners; and review cadence. Policy language alone satisfies no assessment objective — the configuration and records behind it do.

The fastest way to write a policy that survives contact with an assessor is to keep four things separate and make each one point to the next: policy (what’s allowed and required), procedure (who does each step, when), configuration (how technology enforces it), and evidence (what proves it happened). Most failed mobile policies are aspirational documents describing controls nobody configured. Yours should read like a description of your environment that happens to have rules in it.

The sections a complete mobile device policy needs:

• Purpose, scope, and definitions — which levels, which information types, which device classes
• Permitted ownership models (corporate, BYOD, or blocked) and approved platforms with minimum OS versions
• Permitted and prohibited FCI/CUI use per model — including the blocked paths, named
• Device identification, inventory, and the authorization workflow (who approves, before what connects)
• Authentication and MFA requirements for mobile access
• Encryption requirements, including the module-and-certificate documentation obligation
• Copy, save, print, screenshot, backup, and sharing restrictions
• Rooted/jailbroken device handling and configuration-drift response
• Logging, log review ownership, and cadence
• Lost, stolen, replaced, and compromised device response; international travel handling
• User privacy boundaries and consent (BYOD models)
• Separation and revocation at offboarding
• Exceptions: who grants them, where they’re recorded, when they expire
• Evidence retention, named evidence owners, and the annual/change-triggered review

What will the assessor actually examine, interview, and test?

A CMMC assessment runs on the three methods defined in NIST SP 800-171A — examine, interview, and test. For mobile devices, that means documents and configurations get read, administrators and users get questioned, and controls get demonstrated live: an unapproved device denied, a connection event located in the logs, a lost device revoked. An MDM invoice satisfies none of the three.

The mobile evidence pack

One retention fact that surprises even prepared teams: for Level 2 certification assessments, 32 CFR § 170.17 requires assessment evidence artifacts to be retained (hashed) for six years from the CMMC Status Date. The evidence pack isn’t a sprint deliverable — it’s a filing system you’ll live with.

What a weak packet looks like— and yes, these get offered in earnest: an undated MDM dashboard screenshot; a policy asserting “all phones are encrypted”; a device count that doesn’t match the identity logs; an Intune invoice; a vendor brochure; a VDI diagram with zero negative tests; encryption “evidence” that never names a module. What a strong packet looks likeis a chain an assessor can walk without you narrating: user → approved role → approved device identifier → enforced access policy → logged connection event → encrypted data path with certificate number → dated test → the SSP paragraph that predicted all of it.

And the failure modes worth testing beforesomeone else does: native email still alive on unmanaged phones; user authorization mistaken for device authorization; a stale inventory; logs that generate but nobody reviews; a lost-device procedure that’s never been fired in anger; departed employees whose mobile tokens outlived them; a VDI clipboard someone enabled for convenience in March; CUI leaking through lock-screen notification previews; personal cloud backup quietly replicating work-app data.

Who should help with CMMC mobile device management?

Use a Registered Practitioner (RP) or Registered Provider Organization (RPO) for scoping, readiness, and control interpretation; a CMMC-focused MSP or MSSP for implementation and ongoing operation; a CUI enclave or VDI specialist for boundary architecture; a GRC platform as the evidence-workflow layer; and a C3PAO only for the independent certification assessment, when the contract requires it and the environment is ready.

One separation rule to hold onto as you evaluate anyone: under 32 CFR § 170.8, the Accreditation Body’s Code of Professional Conduct must prohibit CMMC Ecosystem members from participating in a Level 2 certification assessment when they served as a consultant preparing that organization for any CMMC assessment within the preceding three years. Keep readiness help and formal assessment in separate lanes, always — a provider offering to do both for the same engagement is describing a conflict, not a convenience. Our provider categories guide and who to hire first go deeper on sequencing.

Your next 30 days

A workable 30-day sequence: find every mobile path to FCI and CUI in week one; choose one operating model per use case in week two; enforce it, kill the unapproved paths, and document in week three; test everything and file dated evidence in week four. Don’t walk into an assessment with 3.1.18 or 3.1.19 unimplemented — as NOT MET requirements, neither is eligible for the CMMC assessment POA&M.

Week 1 — find every path.Mail clients, Teams, SharePoint, OneDrive, browser access, VPN, messaging, field apps. Pull identity sign-in logs and diff them against your known inventory; the devices in the logs that aren’t on your list are the project. Note ownership and what each path can actually reach.

Week 2 — decide.For each use case, pick from the matrix: block, company-managed, BYOD full-MDM, BYOD MAM, or KVM-only VDI. If a genuine temporary deficiency exists, document it through the Operational Plan of Action treatment 32 CFR § 170.24 and the Department’s FAQ recognize — an internal “exception” memo waives nothing and doesn’t make a multi-point NOT MET requirement POA&M-eligible. Write the one-paragraph rationale for each choice while the reasoning is fresh; that paragraph becomes SSP language.

Week 3 — enforce and document. Turn on the approved paths, shut every legacy one, build the device-approval workflow, configure logging with a named reviewer, validate encryption module coverage, and update the inventory, SSP, and data-flow diagrams so they describe reality rather than intent.

Week 4 — test and file. Approved access works; denied access fails; a prohibited transfer blocks; a revoked device dies; the lost-device drill runs end to end; the VDI restrictions hold; the logs surface each event. Date every artifact. Our CMMC readiness checklist slots these into the broader Level 2 sequence.

Done means you can answer one question without opening a browser tab: which mobile devices can reach CUI, why are they permitted, what stops every other path, what evidence proves it, and who reviews it? Answer that with records and dated tests, and you have a defensible mobile operating picture.

What we verified (and what we didn’t claim)

Material regulatory statements on this page are linked to the primary or authoritative sources listed below, reviewed during the July 10, 2026verification pass; editorial conclusions — scope-treatment judgments, model recommendations, category routing — are labeled as ours. Platform rows reflect public-record checks on that date.

Primary sources reviewed, July 10, 2026:

• 32 CFR Part 170 — CMMC Program Rule (effective December 16, 2024): asset categories (§ 170.19), POA&M limits (§ 170.21), scoring methodology (§ 170.24), artifact retention (§ 170.17), ecosystem conduct (§ 170.8), phased implementation (§ 170.3(e))
• DFARS 252.204-7025 (solicitation provision), DFARS 252.204-7021 (contract clause, effective November 10, 2025), DFARS 252.204-7012, and DFARS 252.204-7019/-7020 for the NIST SP 800-171 DoD Assessment lane
• FAR 52.204-21 — the 15 Level 1 safeguards
• NIST SP 800-171 Revision 2 and NIST SP 800-171A (June 2018, the incorporated assessment edition)
• NIST SP 800-172 (February 2021, the incorporated edition for Level 3)
• CMMC Assessment Guide – Level 2 and CMMC Scoping Guide – Level 2
• Department CMMC FAQ, Revision 2.3 (May 2026) — VDI conditions (F-A1/F-A2), OPA vs. POA&M (C-A9), CSP/FedRAMP branches (E-A1/E-A2/E-A4)
• DoD’s December 2023 FedRAMP Moderate equivalency memo
• NIST CMVP and the FIPS 140-3 transition page — the September 21, 2026 Active-through date and existing-systems language
• NIST SP 800-124 Rev. 2 — MDM/MAM/MTD distinctions
• Microsoft, Omnissa, and Ivanti public documentation and FedRAMP Marketplace records for the platform table (attributed where company-stated)

What we did not claim:no MDM product was certified, endorsed, or ranked; no platform was declared “CMMC compliant”; no vendor’s assessment-success story was adopted as fact; no virtual-mobile product was declared officially equivalent to VDI; no universal price was published; and nothing here determines your scope — that takes your contract, your data flows, and a qualified RP, RPO, or federal-contracts attorney.

Regulations move. If you find a newer primary source or an error, use our corrections process — our methodology and editorial standards explain how verification and compensation disclosure work here, and the “last verified” date above changes only when we’ve actually re-run this review. Scheduled re-verification: after September 21, 2026 (FIPS 140-2 Historical transition) and after November 10, 2026 (Phase 2 begins).

Frequently asked questions

Does CMMC require MDM software?

No CMMC text universally requires purchasing an MDM product. At Level 2, mobile devices handling CUI must be identified, their connections authorized, monitored, and logged (AC.L2-3.1.18), and the CUI on them encrypted (AC.L2-3.1.19). The Level 2 Assessment Guide offers MDM as an example implementation of those outcomes.

Is MDM required for CMMC Level 1?

FAR 52.204-21 never names MDM. But a phone that processes, stores, or transmits FCI is part of the covered contractor information system, so the applicable Level 1 safeguards — access limits, connection control, boundary protection — still reach it. Some technical control is usually unavoidable; a specific product is not.

Is BYOD allowed under CMMC?

Yes — no rule categorically bans it. Personal ownership just doesn’t excuse anything: if the device handles CUI, the requirements and the evidence burden apply to it, which is why many contractors find company-owned devices or a KVM-only VDI design easier to defend.

Can employees view CUI on a phone if they can’t download it?

Viewing is access, and the Level 2 Scoping Guide’s definition of “process” includes CUI being accessed. Download restrictions reduce risk; they do not, by themselves, take the phone out of the analysis.

Does a phone used only for MFA codes become in scope?

Not automatically as a CUI Asset — it may never process, store, or transmit CUI. But don’t assume it’s out of scope just because it never displays CUI: determine whether it handles Security Protection Data or performs a security-protection function, and classify it under the 32 CFR § 170.19 categories. Note also that for the KVM-only VDI out-of-scope path, the Department’s FAQ requires MFA to the VDI server to be separate from the unmanaged client.

Are laptops “mobile devices” under CMMC?

The definitional debate doesn’t matter in practice. A laptop that processes, stores, or transmits CUI is a CUI Asset assessed against all applicable Level 2 requirements regardless of the label — and the Assessment Guide’s own 3.1.19 discussion uses laptop full-disk encryption as an example.

Is Microsoft Intune CMMC compliant?

No product is “CMMC compliant” on its own — CMMC assesses your implementation and evidence, not a license. Intune can support inventory, conditional access, configuration, and encryption enforcement; whether the objectives are met depends on your configuration and scope. Note that Intune’s government-cloud instances are GCC High and DoD; a “GCC” tenant’s Intune is the commercial service.

Is MAM enough without enrolling the whole device?

It can anchor a defensible design, but it is not an automatic scope exemption, and user authentication alone doesn’t prove the device-authorization objective in 3.1.18. Define how device connections get authorized, enforce it technically, run the eight-step test in the MAM section, and keep the dated results.

Does encrypting a phone take it out of scope?

No. Encryption protects the CUI; it doesn’t change the fact that the device processes, stores, or transmits it. The Department’s FAQ makes the same point about clouds — encrypted CUI is still CUI, and a non-FedRAMP-Moderate cloud can’t store it. Scope and protection are separate questions.

Does mobile encryption have to be FIPS-validated?

When cryptography is what protects the confidentiality of CUI, SC.L2-3.13.11 requires FIPS-validated modules — a CMVP certificate for the specific module and version, not just an approved algorithm. Document the certificate numbers and matching OS versions in your SSP.

What happens to FIPS 140-2 after September 21, 2026?

FIPS 140-2 validations remain Active through September 21, 2026 and then move to the CMVP Historical list. NIST permits continued use of Historical modules in existing systems, but the CMMC rule creates no blanket contractor exception — document the exact module, version, certificate status, and deployment, and handle any genuine temporary deficiency through the Operational Plan of Action treatment 32 CFR § 170.24 recognizes. For new architectures, prefer modules with an Active FIPS 140-3 validation.

Can AC.L2-3.1.18 or AC.L2-3.1.19 go on a POA&M?

Not as NOT MET requirements on the CMMC assessment POA&M used to obtain a Conditional Level 2 Status — at five and three points, both exceed the one-point limit in 32 CFR § 170.21, which also requires a minimum score of 88 of 110. A properly documented enduring exception or a temporary deficiency addressed through an Operational Plan of Action is a different treatment and may be assessed MET when the conditions in § 170.24 are satisfied.

Can VDI keep a personal phone out of scope?

Potentially — when the endpoint receives only video and returns only keyboard and mouse input; copying (including screenshots), saving, and printing CUI on the endpoint are prevented server-side; MFA to the VDI server is separate from the unmanaged client; only authorized users can access the virtual desktop; access is restricted to allowable locations; and the configuration is verified. The VDI-hosted environment and supporting assets remain in scope per their asset categories.

Will a CMMC assessor inspect employees’ personal phones?

There’s no universal procedure to promise. Assessments run on examine, interview, and test — so build the enrollment records, policy exports, logs, and demonstrations that prove the objectives, and agree on the evidence approach during assessment planning rather than improvising with someone’s phone.

Does GCC High solve mobile compliance by itself?

No. GCC High can host your in-scope services on FedRAMP High infrastructure, which helps — but the endpoint, identity, configuration, encryption, logging, and data-transfer questions on this page still need your answers and your evidence.

Does NIST SP 800-171 Rev. 3 change any of this?

Not for CMMC today. CMMC Level 2 assessments run against Revision 2, and the Department has issued a class deviation to DFARS 252.204-7012 maintaining Revision 2 as the assessed standard until Revision 3 is incorporated through rulemaking. Contractors may implement Revision 3 using DoD’s April 2025 organization-defined parameters, but must ensure any Rev. 2 gaps are still addressed.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

The Defense Compliance Report — the independent CMMC decision layer for defense contractors. Choose the right CMMC path before you hire.

Article last verified: July 10, 2026. Scheduled re-verification: after September 21, 2026 (FIPS 140-2 Historical transition) and after November 10, 2026 (Phase 2 begins).