Apple holds current NIAP validation against the same Protection Profile as Google and Samsung, one
of the strongest FIPS portfolios in the industry, and a DISA STIG published within months of each
iOS release. It is still not eligible as a CSfC end user device — and the reason has nothing to do
with the technology.
CSfC Components List
Absent — no Apple entry, any category
NIAP validation
iOS 18 — VID 11623, Dec 2025
FIPS posture
30 active CMVP certificates
Apple does not appear on the CSfC Components List
Not under End User Device / Mobile Platform. Not under MDM. Not under IPsec VPN Client. Not in any
category. As of August 2026 the End User Device / Mobile Platform category contains
only Android devices — from Google and Samsung.
This matters because the Mobile Access Capability Package requires that End User Devices be
selected from the Components List, or built from listed sub-components. An iPhone or iPad
cannot currently serve as the end user device in a registered CSfC solution, however well
certified it is elsewhere.
Listing requires a vendor to enter a Memorandum of Agreement with NSA on top of NIAP validation.
That is a commercial and legal step, not a technical bar. Apple's own security certifications
documentation makes no mention of CSfC, and there is no public commitment either way — so treat
the current state as the planning assumption and do not build a schedule around a change.
Background
What Apple does bring.
None of the above says Apple is weakly secured. It is worth being precise about that, because the
gap is bureaucratic rather than architectural, and conflating the two leads programs to the wrong
conclusions in both directions.
Secure Enclave
A dedicated secure subsystem integrated into the Apple SoC and isolated from the application
processor. An immutable Boot ROM verifies the signature of sepOS — a customized
L4 microkernel — before handing over control, and on newer silicon a Boot Monitor hashes the
loaded image to block unauthorized code. Secure Enclave memory is encrypted by a dedicated
Memory Protection Engine with authentication tags and anti-replay protection. A per-device UID
fused at manufacture is never exposed to software.
Devices shipped from late 2020 on A12 and later add a second-generation Secure Storage
Component with counter lockboxes that erase passcode-protected entropy past the attempt
limit — a hardware defeat for offline brute force.
Data Protection classes — and a default worth knowing
iOS assigns files to protection classes. Class A discards its key shortly after lock, making data
genuinely inaccessible until reauthentication. But Class C is the default for
third-party app data — its key stays resident after lock, which protects against a reboot attack
but not against a running, locked device.
For any sensitive deployment, requiring Class A for app data is a real configuration decision, not
a detail. This is exactly the kind of control the STIG exists to impose.
Supervision and Declarative Device Management
Organization-owned devices are supervised via Automated Device Enrollment through Apple Business
Manager, which unlocks restrictions unavailable on personally-owned devices. Newer
Declarative Device Management shifts policy from server-polled commands to
autonomous on-device enforcement with a proactive status channel — meaning configuration state is
continuously enforced and reported rather than inferred from the last successful check-in. For
accreditation, that is a meaningful improvement in evidence quality.
Apple Certifications
Six registries, honestly reported.
Strong on four, absent on one, and the one it is absent from is the one that decides CSfC eligibility.
NIAP
National Information Assurance Partnership
The US Common Criteria scheme. Apple maintains continuous validation across iOS releases.
Current
iOS 18 — VID 11623 and iPadOS 18 — VID 11624, both validated 15 December
2025 by atsec, on iOS/iPadOS 18.3.1. Both claim PP_MDF v3.3 plus modules for
biometrics, Bluetooth, MDM Agents, VPN Clients v2.5 and WLAN clients, with the TLS
package.
iOS 26 is pending, not certified. Programs required to run a validated configuration are
pinned to iOS 18.
NSA's program for protecting classified data with layered commercial products. Components List
membership is the gate.
Not listed
Apple appears in no category of the CSfC Components List. The End User Device / Mobile
Platform category holds Google Pixel on Android 15 and two Samsung Galaxy entries on
Android 14 and 15.
Verify this yourself rather than taking our word for it — it is the single most consequential
fact on this page, and the list is public.
The international standard. Apple's mobile certifications run through NIAP as the US scheme.
The iOS 18 and iPadOS 18 validations above are the Common Criteria certifications —
Protection Profile conformance rather than EAL-rated.
Worth noting for comparison: there is no standalone Common Criteria certification of
the Secure Enclave. Its assurance is carried by FIPS certificates and by inclusion in the
iOS evaluation boundary. That contrasts with Google's Titan M2, which holds a separate EAL4+
AVA_VAN.5 certification as a component.
DISA's list of products cleared to connect to DoD networks.
Program sunset
We were unable to verify Apple's listing status — the APL search is a session-based application
that does not expose results to external queries.
It matters less than it once did. DISA sunset the APL program effective 30 September
2025, maintaining the repository through FY2026, with cybersecurity assurance migrating to
the DISA Vendor STIG program — a track where Apple is well covered.
30 active CMVP certificates, with continuous validation since 2011. Apple validates
three modules per OS generation: User (software, Level 1), Kernel (software,
Level 1) and Secure Key Store (Secure Enclave hardware, Level 2 with Physical
Security Level 3).
For iOS 18: corecrypto certificates #5184, #5305 and #5306. Active
certificates carry sunset dates out to 2031.
DISA's configuration baseline — and the track that becomes primary as the APL closes.
Current
DISA maintains Apple iOS/iPadOS 26, 18, 17 and 16 STIGs, plus a BYOAD baseline.
The iOS/iPadOS 26 STIG arrived within roughly four months of the OS shipping — notably faster
than the NIAP cycle.
The iOS/iPadOS 26 baseline runs to roughly 88 requirements, weighted heavily toward
CAT II. Confirm exact counts by opening the benchmark in STIG Viewer.
The Components List gap rules iOS out of one specific role: the end user device in a registered
CSfC solution carrying classified data. It rules out nothing else.
Unclassified and CUI mobility — fully supported, with a current DISA STIG and NIAP validation. This is where most government iPhone fleets already live.
Mixed fleets — an organization can run iOS for general workforce mobility and a listed Android device for the classified mission. These are different programs that happen to share a help desk.
Future reconsideration — if Apple enters a Memorandum of Agreement with NSA, the technical foundation to build on is already there. There is no public indication of that happening, so plan for today's state.
The failure mode to avoid is the reverse of the obvious one. Teams rarely conclude iOS is
insecure. They conclude, from a genuinely impressive certification list, that it must therefore be
CSfC-eligible — and discover otherwise at the point where the architecture is already built.
Committed to iPhones and now facing a CSfC requirement?
It is a common position and it is workable — but it is a mixed-fleet architecture, not a single-platform one. We can help you scope what that actually costs.