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

"FIPS validated" gets used like a single stamp of approval. It isn't. The same three words can describe a hardware module Apple and Google submit to NIST themselves, or a third-party library bolted onto an app's local data cache. Compliance officers who don't know the difference are trusting a label instead of an architecture.

Two vendors can both claim to leverage FIPS-validated components for mobile data protection. One of those claims points at something real and narrow. The other points at something borrowed and broad. 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 "what, specifically, is the validated module doing, and is that the thing actually protecting my 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, that's the Secure Enclave and the corecrypto User and Kernel modules performing the TLS handshake and key operations. Apple's own FIPS 140-3 security policy documentation identifies the Apple corecrypto Module as the tested boundary, and the Secure Enclave hardware module has carried FIPS 140-3 testing with Security Level 3 physical assurance since 2020, built into the silicon itself. 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 hardware. When Hypori says it leverages FIPS-validated components, it's pointing at a certificate the platform vendor holds for 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 the Boundary Decides the Outcome

This isn't a paperwork difference. It's the difference between validating the thing that's actually protecting your data and validating 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 words, FIPS-validated components, mean something different depending on which architecture is saying them. 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.