Something has shifted in our customer conversations over the past several months. ARM64 used to come up occasionally. Now it comes up constantly.
Why ARM64 Matters for FIPS 140-3 Deployments
The drivers aren’t mysterious. AWS Graviton and Ampere-based instances have made ARM64 an easy call for cloud cost optimization. Apple Silicon has made ARM64 the default developer environment, so it shows up naturally in build and test pipelines. And at the edge — network appliances, industrial systems, mobile devices — ARM has been the norm for years.
What’s changed isn’t that ARM64 is new. It’s that ARM64 has reached the part of the stack where FIPS validation matters. Most certificates in circulation were tested on x86 because that’s what the deployment landscape looked like when they were validated, and the landscape moved. Teams tend to reach the question at different points: sometimes during architecture planning, sometimes when a FedRAMP assessor, CMMC auditor, or federal customer asks about the deployment target.
FIPS 140-3 Operating Environments: Tested vs. Vendor-Affirmed
A FIPS 140-3 software module isn’t validated in the abstract. It’s validated on specific operating environments (OEs) — combinations of operating system and hardware platform — and every certificate lists them in two categories.
Tested operating environments are the OS and hardware pairs a CMVP-accredited laboratory actually exercised the module on. They appear in the certificate listing and in the module’s Security Policy.
Vendor-affirmed operating environments cover porting. Under Section 7.9 of the CMVP Management Manual, a vendor can affirm that the module maintains its FIPS validation compliance when the same unmodified source code is recompiled for an operating environment beyond the tested list. The constraints: no source code changes, and the OS must be compatible with one listed on the validation.
ARM64 Coverage on SafeLogic’s FIPS 140-3 Certificate
It’s easier to see with a real example, so here’s ours. SafeLogic’s CryptoComply 140-3 FIPS Provider holds CMVP certificate #5040.
On the tested side, the ARM64 coverage sits with the device platforms: Android 13 on Google Tensor G2, iOS 16 on Apple A15, iPadOS 16 on Apple M1, and macOS 13 on Apple M2. The server-class operating systems — Red Hat Enterprise Linux 9, Ubuntu 22.04, AlmaLinux 9, Rocky Linux 9, SUSE Linux Enterprise Server 15, Debian 11, FreeBSD 13, and Windows Server 2019 and 2022 — were laboratory-tested on Intel Xeon.
On the vendor-affirmed side, each of those operating systems is affirmed on any general-purpose platform that supports the OS. That’s what carries ARM64 server deployments: Ubuntu 22.04 on Graviton, RHEL 9 on Ampere, and similar configurations fall under the CMVP porting rules, because CryptoComply’s ARM64 builds compile from the same unmodified source that was validated.
So when someone asks whether our module supports ARM64, the answer has two parts — tested OEs on Apple Silicon and Android, vendor-affirmed coverage for ARM64 server Linux.
Planning an ARM64 FIPS 140-3 Deployment?
If ARM64 is part of your cloud, server, edge, or application roadmap, SafeLogic can help you evaluate your target operating environments and understand how they align with FIPS 140-3 validation requirements.
