SECRET and above

When the data is classified, the rules change.

Everything below the classified threshold is a configuration problem. Above it, you are building a registered solution — two of every encryption layer, every component drawn from an approved list, and a compliance package NSA reviews. This is the harder path, and most of its cost is decided in the first month.

Governing document
Mobile Access CP v2.8.0, March 2026
Encryption layers required
Two — independent, different vendors
Eligible mobile platforms
Android only — as of August 2026
The Difference

Four things that only apply above the classified line.

If you have run a CUI mobility program, most of your instincts carry over. These four do not, and each one is a schedule risk if it surfaces late.

01

Every component must be on the Components List

Not "NIAP validated." Listed. Listing requires the vendor to hold an agreement with NSA on top of validation, and plenty of excellent products have the validation but not the agreement. This single rule eliminates entire platforms — see the gate below.

02

Two independent encryption layers, from different manufacturers

Inner and outer VPN for data in transit. If classified data rests on the device, two Data-at-Rest layers as well. Repeating a vendor collapses two layers into one shared failure mode, and the design will not register.

03

The solution is registered, not just accredited

You request a Compliance Checklist Workbook and work it against your design. Registration is where optimistic architectures meet the actual requirement text — and it is far cheaper to design against the checklist than to retrofit toward it.

04

The STIG is necessary but not sufficient

Published mobile STIGs are scoped to unclassified data up to CUI. You still apply one as your configuration baseline, but your authority to hold classified data comes from the registered solution, not the STIG. Teams conflate these constantly.

Build Your Solution

Assemble it from the Components List.

Every component in a registered CSfC solution must come off the Components List. Work through these and you will see very quickly how narrow the current field actually is — three of the categories a mobile solution needs contain only Samsung products.

01

Get the data classification in writing

From the authority that owns the data. If it is not actually classified, you are on the wrong page — and an entire component stack drops out of scope.

02

Pick your Android vendor

Apple is not an option — iOS and iPadOS appear in no category of the Components List. That leaves two realistic Android vendors, and they are not equally viable.

03

Choose your Data-at-Rest inner layer

Only needed if classified data actually rests on the device. The DAR Capability Package requires the inner layer to be a listed File Encryption or Software Full Drive Encryption product — there is no third option.

04

Choose your two encryption layers

These are the components that run on the device. They must come from different manufacturers — repeating a vendor collapses two layers into one shared failure mode. The gateways and servers they terminate against are separate infrastructure choices, made from their own Components List categories.

Why Cisco AnyConnect and Aruba VIA appear here Archived

Both were genuinely CSfC-listed IPsec VPN Clients — Aruba VIA 3 until 23 March 2021, Cisco AnyConnect 4.6/4.7 for Android and iOS until 31 August 2021. Neither vendor’s successor client has been re-listed, though both hold current NIAP validation.

They remain in live service because NSA permits it: archived components may continue in an already-registered solution until it is renewed, modified, or a security risk forces a change. That is why a practitioner will tell you these are used in CSfC while the current list shows only Samsung — both statements are true. See the Archived Components List.

05

Choose your UEM/MDM

The management plane sits inside the solution boundary, so it has to be listed too. This is the shortest category on the entire Components List — one row.

Every option below can be deployed on premises. That is not a preference, it is a structural requirement: the UEM lives inside the boundary, behind both encryption layers, in an enclave the vendor cannot reach. A SaaS-only platform has no deployment model that fits — which is why cloud-only products such as Microsoft Intune are not offered here at all.

Components and integrators are two different lists Easy to conflate

A component is a NIAP-validated product on the Components List. A Trusted Integrator is a company NSA has approved to design and build registered solutions out of those components. Being on one list says nothing about the other.

This is where most "isn’t X on the CSfC list?" questions come from. General Dynamics is a good example — both GDIT and General Dynamics Mission Systems are Trusted Integrators, and neither appears in any Components List category. Roughly 100 firms are on that list, including Booz Allen, CACI, Leidos, Lockheed Martin, ManTech, Northrop Grumman, SAIC and Motorola Solutions.

See the CSfC Trusted Integrator List

06

Apply the STIG

The registered solution grants your authority to hold classified data. The STIG is still how the device itself must be configured, and it is what an assessor checks you against.

Complete the steps above.

Component lists transcribed from the NSA CSfC Components List, August 2026, with layer rules per the Data-at-Rest Capability Package v5.1.0 and Mobile Access Capability Package v2.8.0. The list changes continuously — confirm every component against the source before designing around it.

Scoping Reality

What the two-layer rule actually costs.

Not a price list — a list of the line items that surprise people, because "two layers" sounds like one extra product and is closer to a doubled architecture.

  • Two VPN clients and two gateways, from different manufacturers, each listed, each licensed, each with its own support contract and patch cadence.
  • Two certificate authorities in most designs, because the layers must not share a trust root.
  • An inner Data-at-Rest layer if anything classified persists on the device. Samsung includes one; on other platforms it is a separate listed product.
  • Gray and Red management infrastructure — the management plane sits inside the solution boundary, not on the internet. That is real infrastructure, not a SaaS tenant.
  • Registration effort — the Compliance Checklist Workbook is substantial, and answering it requires the design to be settled.
  • Version discipline forever — your solution is registered against specific OS and component versions. Uncontrolled updates move you outside it.

The single largest cost reduction available to most programs is answering one question honestly at the start: does classified data actually need to rest on the device? If the answer is no, an entire Capability Package and its component stack drop out of scope.

The upside worth remembering

This is still dramatically faster than the alternative. CSfC exists so that agencies can field classified mobility on commercial hardware in months rather than waiting years for purpose-built equipment. The rules are demanding because the shortcut is enormous.