ANALYSIS — Can MAM be used for CUI on a BYOD device?

Framework 1 — DoD Policy: permits the architecture, with conditions

What the sources state.
The October 24, 2025 MFA memorandum names "either a Mobile Application Management (MAM) implementation or a Virtual Desktop Interface (VDI)" for CAC-holders using derived non-PKI MFA from a personal device; permits M365 data "up to (and including) CUI"; requires isolation "if technologically feasible" and management "to the extent possible"; and requires, "For MAM, limit access to applications that can be policy enforced."

• The August 10, 2022 AMD memorandum, incorporated by reference, requires CUI access to be "managed by an EMM system (e.g., mobile device management (MDM), mobile application management (MAM), mobile content management (MCM), or virtual mobile infrastructure (VMI))," requires that "The EMM system must be National Information Assurance Partnership (NIAP) validated and configured in accordance with applicable STIGs," and requires that on access termination, loss, or compromise, "All DoD data will be removed (e.g., wiped)" while "Users' personal information and applications on the device should not be impacted."

‍What this means. The policy anticipated MAM specifically and wrote conditions for it. Two of those conditions carry the weight of everything below: the EMM must be NIAP validated (Framework 2), and DoD data must be removable without touching personal data (Framework 3). Neither memorandum names a product or a configuration.

Framework 2 — NIAP: certificate scope, and a date

What the sources state.

• Microsoft Intune holds NIAP PCL entry VID 11298 (Certified 2024-12-31; assurance maintenance date 2026-12-31), evaluated against PP_MDM_V4.0 and the MDM Agent PP-Module; the TOE is Intune (2411) plus the Company Portal app for Android. The Validation Report states the evaluation "was limited to the functionality and assurances covered in PP_MDM_V4.0 and MOD_MDM_AGENT_V1.0" and that "Other functionality included in the product was not assessed." [C5, STATED — S-025 §§1, 6; S-008 screenshot 2026-09-10; Q-011]
• As of 2026-09-10 the entry's Maintenance Update column was blank and no Microsoft product was on the Products in Evaluation list. [C6, STATED / VERIFY LIVE — S-008; Q-011-C16, C19]
• The BYOD use-case separately requires the device-side "NIAP Mobile Device Fundamentals Protection Profile and DoD Annex." [C7, STATED — S-001 p. 26]

For a DoD AMD program, "EMM system must be NIAP validated" is a DIRECT requirement (Framework 1, C3). Intune satisfies it today as an MDM system. Two questions follow. First, whether an app-protection-only (MAM/MAM-WE) deployment is the "EMM system" that was validated: the certificate attests to an enrollment-based configuration, and the Validation Report places other functionality outside the evaluation. Whether an AO reads "NIAP validated" as attaching to the product or to the evaluated configuration is not answered by either memorandum. [C8, NOT ESTABLISHED] Second, if VID 11298 is archived after 2026-12-31 without maintenance, the requirement is unmet for any Intune-based AMD program until a successor certificate exists, regardless of MDM or MAM mode. [C9, DERIVED from C3, C5, C6]

Counter-reading. The MFA memorandum lists FIPS-140 or NIAP validation as a factor DoD CIO "may deem appropriate" in E2P review of unlisted MFAs; it does not itself require the MAM implementation to be NIAP-certified. The NIAP requirement comes from the 2022 memorandum, and that memorandum says "EMM system," not "EMM configuration." A reasonable AO could conclude that a validated product satisfies the text. [C10, ANALYSIS] C24

Framework 3 — CUI destruction and sanitization: a burden of evidence, not a prohibition

This framework is where the most overstatement occurs, in both directions. The chain below separates DoD's own programs from contractors' programs because their governing texts differ.

3a. What DoD's BYOD rule itself requires

The AMD memorandum's removal requirement is the operative DoD-specific text: all DoD data removed (e.g., wiped) on termination, loss, or compromise, and "Users' personal information and applications on the device should not be impacted." [C3, STATED — S-004 §3.b(5)]
‍
That is a requirement for selective removal. A whole-device Purge or factory reset would satisfy the first sentence and violate the second. Any argument that DoD BYOD policy demands whole-device sanitization runs against DoD's own text. The memorandum does not use the words Clear, Purge, or Destroy and does not cite SP 800-88 in its Attachment. [C11, DERIVED — Q-032-C14, C16]

3b. The CUI destruction standard

DoDI 5200.48 requires destroyed CUI, including electronic CUI, to be "unreadable, indecipherable, and irrecoverable," and identifies SP 800-88 methods as an example ("such as") of acceptable means. It sets an outcome standard, not a tier. [C12, STATED — S-032; Q-041]

3c. SP 800-171: which text applies

• Rev. 2, 3.8.3 (the text DoD contractors are assessed against under Class Deviation 2024-O0013 and 32 CFR 170.14): "Sanitize or destroy system media containing CUI before disposal or release for reuse." No "out of organizational control" trigger. [C13, STATED — S-027, S-030, S-031; Q-040]
• Rev. 3, 03.08.03 (not yet adopted for DFARS/CMMC; already the SP 800-53 MP-6 wording federal agencies follow): "Sanitize system media that contain CUI prior to disposal, release out of organizational control, or release for reuse," with mobile devices among the listed examples. [C14, STATED — S-028; Q-040]

‍What this means. For a contractor, the 800-171 hook for "a personal device leaving control" does not exist in the assessed text; the sanitization expectation has to come from DoDI 5200.48's outcome standard via the contract, from 32 CFR 2002.14, or from SP 800-88's own scope. For a DoD Component, the MP-6 "out of organizational control" trigger applies directly. [C15, DERIVED]

3d. SP 800-88 Rev. 2: what it actually says about this fact pattern

• Purge "should be used instead of the clear sanitization method" "when possible." [C16, STATED — S-019 §3.1.2]
• "For moderate sensitivity data, the ISM owner may choose to accept the risk of applying clear techniques." CUI is protected at no less than the moderate confidentiality impact level under 32 CFR 2002.14. [C17, STATED — S-019 §4.3; 32 CFR 2002.14 (confirm pinpoint)]
• Partial sanitization is recognized; it "comes with some risks" (spill-over, overprovisioning, device-level vendor interfaces); CE "provides a unique mechanism for supporting some types of partial ISM sanitization" where regions use distinct keys; "sanitization of the whole ISM is preferred ... whenever possible"; and "If the alternative to partial ISM sanitization is not performing sanitization at all, partial ISM sanitization provides benefits that should be considered." The footnoted example of selective sanitization is "sanitizing the contents of a single file that is encrypted with a unique key using CE." [C18, STATED — S-019 §4.2; Q-042]
• CE preconditions: no plaintext history, caution where keys are backed up or escrowed, all key copies sanitizable, FIPS 140-validated modules for federal agencies; ten traceability items including "which areas are encrypted and which are not." [C19, STATED — S-019 §3.2]
• Validation may reject an operation whose scope "was too narrowly focused." [C20, STATED — S-019 §4.5.2]
• The document's examples of media leaving organizational control are lease returns, resale, donation, recycling, warranty exchange. It does not address media the organization never owned. [C21, STATED / DERIVED — S-019 §4.3.4]

3e. What Microsoft's public documentation says about the mechanism

Microsoft's app-protection-policy documentation describes selective wipe as removal of organization data from the managed app when the app next checks in, distinguishes it from full-device wipe under enrollment, and documents cases where data copied outside the managed boundary (for example, contacts synced to a native app) is not removed by selective wipe. [C22, STATED — S-020; pinpoints to be confirmed against current Microsoft Learn pages]

On the public documentation reviewed, this site has not identified evidence that Intune MAM selective wipe: invokes a device sanitize command or an IEEE 2883 technique; performs a documented cryptographic erase with key zeroization traceable to SP 800-88 §3.2; addresses all storage locations where managed-app data may reside (caches, previews, notification stores, backups); or has been validated against SP 800-88 Purge by an independent party. [C23, NOT ESTABLISHED]

3f. Putting Framework 3 together

For a DoD AMD program: the governing texts require selective removal that spares personal data (3a) and an outcome of unreadable/indecipherable/irrecoverable (3b). SP 800-88 says selective sanitization is legitimate, is best achieved by per-file or per-region CE, carries assurance risks, and is acceptable where whole-media sanitization is not an option (3d). Whole-media sanitization is not an option here, by DoD's own rule. The question an AO must answer is therefore: does the EMM's selective removal achieve the 5200.48 outcome with the assurance the Component's sanitization policy requires, and can that be documented? On the public evidence, for Intune MAM, that has not been established (3e). It has not been refuted either. [C24, ANALYSIS]
‍
‍For a defense contractor: the assessed 800-171 text has no leaving-control trigger (3c). The sanitization expectation for a personal device is whatever the contractor's own media-protection policy, its System Security Plan, and its assessor accept, informed by 5200.48 through the contract and by SP 800-88 as guidance. SP 800-88 permits risk-based acceptance of Clear for moderate data (3d). A contractor that documents MAM selective wipe as its sanitization technique, states the residual risk, and has the assessor accept it is not out of compliance on the text. A contractor that asserts Purge-level assurance without evidence is. [C25, ANALYSIS]

‍Strongest counter-readings, and responses.

• "A MAM container is an independently encrypted region; deleting its key is CE, which SP 800-88 recognizes as Purge." Correct in principle: SP 800-88 §4.2 says exactly this. The implementer must then show the §3.2 conditions: the container key is the only key protecting the data, all copies of it are sanitizable, no plaintext copy of CUI existed outside the container, and the operation is traceable. That is a documentation burden, not an impossibility. The public Intune documentation reviewed does not carry it. [C26, ANALYSIS]
• "The device was never the organization's media; sanitization triggers written for disposal and release don't fit." This is the strongest textual objection and the marketing-style versions of this argument ignore it. Response: DoD's AMD rule imposes the removal obligation directly on the Component regardless of ownership (3a), and 5200.48's outcome standard attaches to the CUI, not to who owns the medium (3b). For contractors under Rev. 2, the objection has more force, and the site does not pretend otherwise. [C27, ANALYSIS]
• "This argument indicts MDM full-device wipe just as much." It does, unless the device platform's factory reset is a documented cryptographic erase, which Apple and Google document for current devices. For BYOD the point is moot in the DoD context because a full-device wipe is what §3.b(5)(i) tells Components not to do. [C28, ANALYSIS]

Framework 4 — FAR 52.204-27: an obligation MAM does not by itself discharge

What the sources state.

• The clause prohibits a covered application on IT "used or provided by the Contractor under this contract, including equipment provided by the Contractor's employees," with a Contracting Officer exception path under OMB M-23-13. [C29, STATED — S-013]
• The FAR Council preamble states the prohibition applies to employee-owned BYOD devices used in contract performance and not to a personal phone not so used. [C30, STATED — S-014]
• The 2022 AMD memorandum requires the EMM to prevent installation of blocked or prohibited applications "by or within the DoD-managed segment," and separately requires the user agreement to acknowledge that the device "remains subject to any prohibitions and restrictions applied to privately-owned ... devices." [C31, STATED — S-004 §3.a(3)(iii), §3.c(3)]

What this means. The contractor's obligation attaches to the device. MAM's documented scope is the managed container; it does not give visibility into or control over other applications. The obligation must be met some other way: attestation and policy, device-wide enrollment, an architecture under which the device is arguably not "used in performance," or a CO exception. Neither the clause nor the preamble prescribes a technical method. Notably, DoD's own AMD text scopes the EMM's application-blocking duty to the managed segment, which is consistent with a policy-plus-attestation approach for the rest of the device. [C32, ANALYSIS]

Counter-reading. The clause prohibits "having or using," not "failing to technically prevent." A signed attestation may satisfy it. Whether it does is a Contracting Officer and ultimately a legal question. [C33, ANALYSIS]

Framework 5 — CMMC (32 CFR Part 170): scoping consequence, currently in flux

What the sources state.‍

• 32 CFR § 170.19(c)(1) categorizes assets that process, store, or transmit CUI as CUI Assets, assessed against all Level 2 requirements; other categories carry lighter treatment. [C34, STATED — S-017; pinpoint to confirm]
• CMMC Level 2 requirements are "identical to" SP 800-171 Rev. 2 (32 CFR 170.14). [C35, STATED — S-031]
• CMMC Phase 2 (third-party assessment as a contract requirement) was paused by a DoD memorandum of July 13, 2026; a class deviation directs contracting officers to remove or revise CMMC requirements in solicitations and apply the baseline Rev. 2 requirement under DFARS 252.204-7012 in the meantime. DFARS 252.204-7012 itself is unchanged. [C36, STATED / VERIFY LIVE — S-033 (locate primary memo and deviation)]

What this means. A managed container on a personal device processes and stores CUI; on the text of §170.19 that points to CUI Asset treatment unless the boundary is documented otherwise. A VDI architecture that renders CUI without writing it to the device has a more direct argument for a lighter category. This is an inference from the regulation's categories, not a statement about MAM or VDI. With third-party assessment paused, the practical consequence today is a self-assessment and SPRS representation, which carries False Claims Act exposure rather than a C3PAO finding. [C37, ANALYSIS]

Counter-reading. Assessors evaluate the documented boundary, not a technology label. A well-documented MAM deployment may be accepted with a narrowed boundary; a poorly documented VDI deployment may not. [C38, ANALYSIS]

Summary

What would resolve the open items

For the implementer: documentation, in the authorization package or SSP, of (a) which NIAP certificate the EMM relies on, its scope, and its status on the date of authorization; (b) how the managed container stores and keys CUI, what selective wipe does to those keys, whether any plaintext or copies exist outside the container, and the SP 800-88 §3.2.5 traceability items; (c) how the FAR 52.204-27 obligation is met for the whole device; (d) the CMMC asset category and boundary rationale. None of these is a product question; all are deployment-documentation questions, and none is answered by a policy sentence saying "MAM is approved."

For the vendor: publishing the §3.2.5 traceability information for selective wipe would move C23 from NOT ESTABLISHED to STATED in one direction or the other.

Where this site's position changed

• July 2026: this page concluded "No — Exception to Policy required" and graded the sanitization and NIAP pillars as verified failures. Both were overstated. The memo permits MAM; E2P is for things not addressed in policy.
• September 2026 (first rebuild): conclusion changed to "policy permits; other frameworks impose conditions"; pillars regraded ANALYSIS/VERIFY LIVE.
• September 2026 (this revision): Framework 3 rebuilt on the primary texts. Three corrections to the prior reasoning: DoD's own BYOD rule requires selective removal, so whole-device Purge is not the standard to measure MAM against; SP 800-171 Rev. 2, which governs contractors, has no "leaving organizational control" trigger; and SP 800-88 Rev. 2 permits risk-based acceptance of Clear for moderate data and treats partial CE as legitimate. The "never under organizational control" counter-argument added. Framework 2 strengthened by the 2022 memo's "EMM system must be NIAP validated" requirement and the certificate's December date. Framework 5 updated for the CMMC Phase 2 pause.

• Re-run the NIAP filter. niap-ccevs.org/products → Vendor: Microsoft → Status: Certified. Confirm the result count and conformance claims match what's stated above. Recheck quarterly; NIAP listings change slowly but this fact is load-bearing.
• Read the DoW memo's Attachment 4, Table 2 directly — the BYOD use case is a half-page and is the single most cited source on this page.
• Read FAR 52.204-27(b) and the June 2023 Federal Register preamble for the BYOD-inclusion language verbatim.

Claims

Related entries

• Q-011 — Is Microsoft Intune NIAP-certified — and does that cover MAM?
• Glossary — MDM vs. MAM vs. VDI: what's actually different?
• Q-002 — Can I use a VDI on a personal device to access CUI?
• Q-020 — Does the No TikTok Act apply to personal (BYOD) devices - and does it still?