Understanding How FIPS-Validated Cryptography Protects Your Data: One Good, One Not So Good

FIPS validation is a stamp of approval. NIST tests a cryptographic module against a defined standard, and the modules that pass are the building blocks a mobile security architecture gets assembled from. The validation is sound. What varies is the accuracy of the claims vendors make about it. A vendor doesn't need to hold a certificate to cite one. It can point at modules Apple and Google submit to NIST under their own names, or at a third-party library bolted onto an app's local data cache, and use the same two words for both. Compliance officers who take the claim at face value are trusting a vendor's accuracy, not a validated control.

Two vendors can both say they use FIPS-validated components for mobile data protection. One of those claims is accurate and narrow. The other is borrowed and uneven. I'll walk through both, using two products every DIB compliance officer is currently evaluating: Hypori's virtual mobile infrastructure, and Microsoft Intune's mobile application management (MAM).

What the Label Actually Certifies

FIPS 140-2 and FIPS 140-3 validate a specific cryptographic module. Not a product, not a platform, not a vendor's marketing page. NIST's Cryptographic Module Validation Program tests a defined boundary, the algorithm implementation, key handling, and self-tests inside that boundary, and issues a certificate for that boundary alone. Everything outside it is someone else's claim to defend.

So the question that matters isn't "does this product use FIPS-validated crypto." It's whether the vendor's claim about it is accurate: which module is validated, whose certificate it is, and whether that module is the thing actually protecting your data.

The Good Example: A Narrow, Direct Claim

Hypori's architecture asks FIPS-validated components to do one job: authenticate and encrypt the mTLS tunnel between the device and the session, and protect the private key material used to establish it. Both of those functions map directly onto modules Apple and Google validate themselves, under their own names, for the exact operation being performed.

On iOS, the handshake runs through the corecrypto User and Kernel modules, which Apple validates as software modules at Security Level 1, and the private key sits in the Secure Enclave, which Apple validates separately as the SEP Secure Key Store hardware module. Apple has tested that hardware module against FIPS 140-3 with Security Level 3 physical assurance since 2020, built into the silicon itself. Two certificates, both Apple's, each covering the function it actually performs. On Android, the equivalent is the hardware-backed Android Keystore and StrongBox performing the same handshake and key-storage functions.

The claim is narrow because the job is narrow. There is no intermediate encryption scheme sitting between the data in transit and the validated module. The tunnel is the validated TLS stack. The key never leaves the validated key store. When Hypori says it uses FIPS-validated components, the claim is accurate to the certificate: the platform vendor holds it, and it covers the precise function in use.

The Not-So-Good Example: A Borrowed, Uneven Claim

Intune MAM asks its crypto to do a different, larger job: encrypt a persistent local data store, cached files, attachments, offline copies, inside individual app sandboxes. That's a harder problem than a session, and Microsoft's own documentation shows the compliance story fracturing under the weight of it.

On Android, Microsoft's current app protection documentation states that Intune "uses a wolfSSL, 256-bit AES encryption scheme along with the Android Keystore system" to encrypt app data, and adds a note that "the encryption method is FIPS 140-2 validated," linking out to wolfSSL's own certification. Read that carefully. It's FIPS 140-2, not 140-3. And the validated module is wolfCrypt, a third-party embedded library, not a certificate Microsoft or the OS vendor holds for the construction as built.

On iOS, Microsoft makes no FIPS claim at all for the same function. The current documentation only points to Apple's Data Protection Classes guidance and leaves the validation question to the reader. Same product, same policy setting, two platforms, one FIPS assertion, and it's for the older standard, borrowed from someone else's certificate.

Why One Claim Holds and the Other Doesn't

This isn't a paperwork difference. It's the difference between a claim that describes the module protecting your data and a claim that describes something adjacent to it.

MAM has to build a custom encryption layer because its model requires CUI to live on the device, cached and synced for offline use. That local data store is exactly the kind of complex, evolving, app-by-app surface that's hard to hold still long enough for a clean CMVP boundary, which is why the claim is inconsistent between platforms and lags a full standard generation behind.

Hypori doesn't have that problem to solve, because there's no local data store to encrypt in the first place. The device only ever renders an encoded pixel stream. Hypori moves the user to the data not the data to the user.

That's why the same claim carries different weight depending on which architecture is making it. One vendor is asking validated crypto to protect a session and a key, a job the platform vendors already validated for that exact purpose. The other is asking validated crypto to backstop a local data store the architecture required in the first place, and covering the gap with someone else's certificate, for an older standard, on one platform out of two.

The Question Every CISO Should Be Asking

Not "does this vendor use FIPS-validated components." Ask which cryptographic function is validated, whose certificate it is, which standard it was tested against, and whether that function is the one actually holding your sensitive data or intellectual property. If a vendor can't answer all four without pointing at somebody else's paperwork, you don't have a validated control. You have a marketing claim wearing a compliance label.