FIPS 140-3 Validated Cryptography in Microsoft 365 Endpoints

Microsoft ties a FIPS 140-3 or 140-2 validation to a cryptographic module, not to an entire cloud suite. That scope decision drives how you build and prove a compliant Microsoft 365 endpoint stack.

FIPS 140-3 module scope

NIST runs the CMVP and validates cryptographic modules to FIPS 140-3. CMVP listings record the vendor, module name, version, and level. A control owner does not point to a suite-level badge. You point to a module entry that matches the version you run.

Microsoft reinforces that scope. Microsoft Learn explains that FIPS validation applies to a cryptographic module or a product that embeds the module. That language sets the boundary for any Microsoft 365 discussion. You need the specific module that implements crypto, and you need the matching CMVP record.

Endpoint cryptography in Microsoft 365

Windows provides the endpoint crypto foundation that Microsoft 365 Apps use for transport. Microsoft documents that Office 365 cipher suites use algorithms acceptable under FIPS 140-2 and that Office 365 inherits FIPS validations from Windows through Schannel. In practice, the endpoint config controls which cipher suites the client offers, Schannel implements TLS, and the service negotiates a mutually supported suite.

You likely own several endpoint use cases that touch CUI:

TLS client to Microsoft 365 services.
Local key storage for app features or plugins.

Map each use case to the module that performs the crypto operation. For TLS, that module sits in Windows. For key storage, that module may sit in Windows or in an application component. Microsoft 365 Apps do not carry a suite-level FIPS 140-3 claim. The endpoint inherits validations through the operating system modules that the apps call.

Microsoft’s public documentation for endpoints and transport centers on FIPS 140-2 lineage today. Treat that as your floor for Microsoft 365 endpoint negotiations until Microsoft publishes module-level FIPS 140-3 claims for Windows client crypto in a way you can cite with version fidelity.

Service-side cryptography in Microsoft clouds

Microsoft separates endpoint crypto from service crypto. Microsoft documents TLS and IPsec for data in transit, and cites Exchange use of TLS 1.2 with 256-bit cipher strength under FIPS 140-2 validation. That addresses service-to-service and client-to-service transport. You still need the endpoint module story because the client participates in the TLS handshake.

Azure Key Vault Managed HSM represents a different class of service component. Microsoft states that Managed HSM uses FIPS 140-3 Level 3 validated HSMs. Microsoft also states that the HSM fleet for Managed HSM and for Azure Key Vault Premium runs firmware that carries a FIPS 140-3 Level 3 validation. That statement covers key protection inside those services. It does not change the module lineage on your Windows client.

Microsoft’s compliance offering pages list Office 365 commercial and government services with FIPS 140-2 validated components, including Office 365 U.S. Government and Office 365 U.S. Government Defense. Read that page as a component inventory. Do not read it as a blanket statement that every endpoint or every workload hits a FIPS 140-3 line.

CMMC verification on endpoints

Two CMMC Level 2 practices drive endpoint crypto design for CUI:

SC.L2-3.13.11, employ FIPS-validated cryptography when you protect the confidentiality of CUI.
SC.L2-3.13.10, employ cryptographic mechanisms to protect the confidentiality of CUI on internal and external networks.

Build a clear chain from data to module. Identify the CUI data flow on the endpoint. Name the protection mechanism that touches that data. Name the module that implements the mechanism. Point to the CMVP entry that matches the version you run. That chain gives an assessor a straight line from the practice text to objective evidence.

A few examples help teams frame the work:

Microsoft 365 Apps connect to Exchange Online or SharePoint Online over TLS. Windows Schannel implements the TLS client. You document the Schannel version, the cipher policy, and the CMVP listing that covers the module implementation you run.
You place tenant keys in Azure Key Vault Managed HSM. The service-side HSM carries a FIPS 140-3 Level 3 validation per Microsoft’s service page. You still document the endpoint crypto for client connections that request key operations.

Put that material in the SSP. State the module boundary, the mode you enforce, and the configuration that excludes non-approved algorithms. Add configuration references and screenshots that show the effective policy. Then track system updates that move module versions, and keep CMVP references aligned with those version changes. You can connect this work to your broader control mapping with our guidance in NIST 800-171 to CMMC Level 2 mapping, and you can anchor documentation patterns with our post on the System Security Plan.

Assessor evidence and documentation

Assessors read the DoD CIO Level 2 Assessment Guide and the CAP v2.0 when they define objective evidence needs. Build an evidence set that names the module and proves the config on real endpoints. Aim for two categories:

Configuration state. Provide TLS cipher policy exports, Schannel policy screenshots, and registry or MDM profiles that disable non-approved algorithms.
Version fidelity. Provide module version screenshots and OS build identifiers that you can match to CMVP listings, and provide Microsoft Learn pages that show the inheritance path for Office 365 transport.

Capture validation details for service components you call. For Azure Key Vault Managed HSM, include the Microsoft service page that states the FIPS 140-3 Level 3 validation and the SKU you use. For Office 365 transport, include Microsoft’s data-in-transit statement that names TLS and cipher strength, along with your endpoint policy that constrains the negotiation. That pairing shows that your client offers approved suites and the service meets the same bar.

DFARS 252.204-7012 sits in the background for many tenants. You can read our summary of reporting and cloud use obligations here: DFARS 252.204-7012 requirements. That clause points to FedRAMP authorization for external cloud services that process CUI. It does not replace the FIPS module verification work on endpoints.

Procurement and tenant nuances

Microsoft runs separate commercial, government, and DoD or Secret offerings. Microsoft’s public sector blog explains the differences and helps teams avoid conflating endpoint and tenant claims. A GCC High tenant does not change the Windows client module story by itself. The tenant choice does change which service statements you cite and which compliance offering pages apply to your scope.

Procurement teams should ask two direct questions. Which endpoint modules will handle CUI protection, and which service components will hold keys or process CUI? That split will steer you to the correct Microsoft Learn pages and to the CMVP database entries you need to cite. It will also prevent a contract from embedding an undefined promise about suite-level FIPS 140-3 coverage that no Microsoft page supports today.

Misstatements to avoid

Treat two patterns as red flags in policies and marketing copy:

Blanket claims such as “Microsoft 365 is FIPS 140-3 certified.” Microsoft documents module-level validations, not suite-level certifications.
One-click promises such as “enable a FIPS mode and call it done.” Assessors expect a module boundary, a configuration record, a CMVP reference, and a test result that proves the endpoint uses the intended module.

Teams also confuse FIPS 140-2 and FIPS 140-3 language. Cite the exact version Microsoft publishes for the component in scope. If you run controls that depend on Windows client crypto, show the module and version that the client uses. If you depend on Azure Key Vault Managed HSM, cite Microsoft’s 140-3 Level 3 statement for that service and align it with your SKU and region.