One MDM is CSfC-listed. Only one.
Several mobile device management products hold current NIAP validation. Exactly one appears on the CSfC Components List. If your program assumed its existing UEM would carry over into a classified deployment, this is the page that changes the plan.
The MDM is what makes the endpoint's configuration true.
In a CSfC Mobile Access solution the End User Device is a commercial phone. Its approved configuration — two independent encryption layers, provisioned certificates, disabled radios and services, restricted applications — is not self-enforcing. The MDM server issues that policy and the MDM agent enforces it on the device.
Which means the management channel is not adjacent to the security boundary. It is part of it. If the MDM can be subverted, the device's compliance with the Capability Package becomes a claim rather than a fact. That is why the MDM itself must be evaluated, not merely selected.
What the Protection Profile actually checks
The Protection Profile for Mobile Device Management, Version 4.0 puts the MDM server in scope — administration, policy configuration, device reporting — together with the MDM Agent on the device, and optionally a Mobile Application Store. The separate PP-Module for MDM Agents v1.0 exists precisely because the agent holds privileges over device policy and deserves its own evaluation.
Real evaluations claim the combined configuration — PP-Configuration for Mobile Device Management (MDM) and MDM Agents, Version 1.0, which pairs the MDM PP with the Agent module and the TLS Functional Package v1.1. Note what that last piece means: the evaluation checks that the policy channel between server and agent is itself cryptographically protected, not merely that the product has a policy feature.
Where the MDM sits in the architecture
In the Mobile Access Capability Package, the MDM server is treated as a TLS-Protected Server inside the solution boundary — reachable by the device only after both encryption tunnels are established. It sits behind the Gray firewall, not out on the black network. Programs that plan to manage classified-capable devices from an existing internet-facing UEM tenant are describing a different architecture than the one they think.
Unusually, there are no CSfC-specific extras
Most CSfC component categories layer additional selectable requirements on top of the Protection Profile. The CSfC MDM selections document states that the program "does not require any selectable requirements for Mobile Device Management." Validation against the current MDM Protection Profile is the entire bar — which makes the Components List the only question that remains.
The complete category.
Not an excerpt. This is every product in the MDM category of the CSfC Components List as of August 2026.
| Vendor | Product | Version | Listed |
|---|---|---|---|
| SamsungSDS | EMM and EMM Agent | Android v2.2.5 | 2025.12.05 |
NIAP validation is not CSfC listing
Ivanti EPMM, Microsoft Intune and BlackBerry UEM have all held NIAP MDM validation. None of them appears in the CSfC MDM category. Listing additionally requires the vendor to enter a Memorandum of Agreement with NSA — a commercial and legal step, not a technical one. A product can be fully validated and simply not be on the list.
Be especially careful with vendor marketing that mentions CSfC generally. BlackBerry, for instance, holds CSfC approval for SecuSUITE — a secure voice product, not the MDM. A CSfC claim in a vendor's materials is not a claim about the product you are evaluating unless it names that product and that category.
Products with current MDM Protection Profile validation.
Useful for unclassified enterprise programs, and as context for what could plausibly be listed later. Validations age off the Product Compliant List after a retention window, so dates matter as much as names.
| Vendor / Product | VID | Validated | Note |
|---|---|---|---|
| Samsung SDS EMMand EMM Agent for Android 2.2.5 | 11630 | 05 Dec 2025 | The one CSfC-listed product |
| IvantiEndpoint Manager Mobile (EPMM) System 12 | 11566 | 15 Oct 2025 | Current; not CSfC-listed |
| MicrosoftIntune (2411) + Company Portal | 11298 | 31 Dec 2024 | Retention window closes late 2026 |
| BlackBerryUEM Server and Android Client v12 | 11427 | 30 May 2024 | Likely aged off — verify before citing |
Verify before you cite
- Whether BlackBerry UEM (VID 11427) is on the active Product Compliant List or has moved to Archived — its retention window has likely expired.
- Microsoft Intune's assurance maintenance date — validated 31 Dec 2024, so it drops off around December 2026.
- The Samsung SDS product page ID: the CSfC list links to
/products/11631, but the certificate for VID 11631 covers a different vendor’s devices entirely, while VID 11630 matches Samsung SDS and the listed date exactly. Open both before hard-coding a link. - Workspace ONE is frequently assumed to be NIAP-validated for MDM. Omnissa has been pursuing German BSI EAL4+ evaluation instead — do not describe it as NIAP-validated without checking.
Sources: NIAP-issued certificates and validation reports for VIDs 11630, 11566, 11298 and 11427; NSA CSfC Components List; CSfC MDM selections document; Mobile Access Capability Package. Current as of August 2026.
Samsung STIG Implementation
Your UEM is also how the STIG baseline gets applied. The Samsung walkthrough shows what that looks like in practice — OEMConfig, Knox Service Plugin, and where the two divide.
Already committed to a UEM?
Most programs are, and it is rarely fatal — but it does change the architecture. Tell us what you run and we will tell you what it means for your options.