The endpoint decides most of your architecture.

Capability Packages are written to be platform-neutral. Real deployments never are. What you can build, how long it takes, and what you have to buy separately all change depending on what is in the user's hand — and the differences are larger than most programs expect going in.

Mobile platforms CSfC-listed
Android only — Google and Samsung
MDM products CSfC-listed
One — see the MDM breakdown
Rule that governs all of it
EUDs must come from the Components List

The constraint that surprises people

The Mobile Access Capability Package requires that End User Devices be selected from the CSfC Components List, or built from sub-components that are. A device can hold excellent NIAP validation, current FIPS certificates and a published DISA STIG, and still be ineligible as a CSfC end user device — because listing additionally requires the vendor to enter an agreement with NSA, and not every vendor has.

As of August 2026 the End User Device / Mobile Platform category is entirely Android. That single fact reshapes more programs than any technical consideration on this page.

Common Ground

What is true regardless of platform.

Every platform page answers the same five questions. If you are evaluating something not covered here, these are the questions to ask of it.

01

Is it on the Components List — at the version you intend to field?

Listings name specific OS versions. Being listed at Android 15 says nothing about Android 16. This question has a yes-or-no answer and it gates everything else.

02

Where does the second encryption layer come from?

Two independent layers, in transit and — if data persists — at rest. Some platforms supply the inner layer; on others you buy it. This is the biggest hidden cost difference between platforms.

03

Can your management tooling actually enforce the configuration?

A control you cannot push from your UEM is a control you will be arguing about at assessment. Prove it in a lab, on your hardware, before the purchase order.

04

Is there a current STIG, and who applies it?

The STIG is the configuration baseline and the evidence. Confirm one exists for your exact OS version, and that someone owns applying and maintaining it.

05

What happens at the next OS release?

Certifications, listings and STIGs all lag shipping software. Plan for the gap between what your users want to install and what your solution is registered against — and control updates from day one.

Choosing a platform right now?

Tell us whether data rests on the device, who manages the fleet, and where it gets used. Those three answers usually settle the platform question on their own.