FISMA, FIPS 140-3, and the Cryptographic Boundary Problem for AI Tools

FISMA, FIPS 140-3, and the Cryptographic Boundary Problem for AI Tools

If you are deploying AI tools anywhere near federal information systems, you have a cryptographic boundary problem. It is probably not the problem you think it is. The conversation in most agencies and their contractors tends to focus on "is the data encrypted?" which is necessary but insufficient. The real question under FISMA and NIST guidelines is whether every cryptographic module that touches federal data has been validated under FIPS 140-3, and whether the boundaries of those modules are clearly defined when AI inference workloads start moving data through pipelines that nobody architected with module validation in mind.

The Statutory and Regulatory Stack

FISMA (44 U.S.C. §§ 3551-3558), as amended by the Federal Information Security Modernization Act of 2014, requires federal agencies to implement information security programs that comply with NIST standards. NIST SP 800-53 Rev. 5 (published September 2020, updated December 2020) provides the security and privacy controls. Control SC-13 (Cryptographic Protection) mandates the use of cryptography in accordance with applicable laws, regulations, and policies. For federal systems, that means FIPS 140-3.

FIPS 140-3 became effective September 22, 2019, and the Cryptographic Module Validation Program (CMVP) began accepting FIPS 140-3 submissions on April 1, 2022. FIPS 140-2 certificates issued before that transition remain valid until their sunset dates, but new modules must validate against 140-3. The standard is based on ISO/IEC 19790:2012 and ISO/IEC 24759:2017, which is a meaningful shift from the purely domestic 140-2 framework.

The four security levels remain (Level 1 through Level 4), but 140-3 introduces more granular requirements around non-invasive attack mitigation, multi-factor authentication at higher levels, and lifecycle assurance. For most AI-adjacent use cases in defense and federal civilian agencies, Level 1 or Level 2 validation is the baseline. Level 3 shows up in environments handling classified-adjacent or high-impact data.

Where AI Tools Break the Cryptographic Boundary

A cryptographic boundary, under FIPS 140-3 Section 7.2, is the explicitly defined perimeter that establishes the physical and logical extent of a cryptographic module. Everything inside that boundary is subject to validation requirements. Everything outside is not. The boundary must be unambiguous.

Here is where AI tools create problems that traditional software did not.

• Inference pipelines cross module boundaries. When an AI model processes federal data, the data may traverse multiple services: a preprocessing layer, the model inference engine, a postprocessing layer, logging and telemetry, and a response delivery mechanism. Each of these may use different cryptographic implementations for data at rest and in transit. If any one of those implementations is not within a FIPS 140-3 validated module, you have a compliance gap.
• GPU and accelerator cryptography is often unvalidated. Many AI workloads run on NVIDIA GPUs or custom accelerators. The cryptographic operations happening on-device (memory encryption, secure enclaves, key management for multi-tenant isolation) may not be covered by a FIPS 140-3 validated module. NVIDIA's offerings have historically had limited FIPS validation coverage. The A100 and H100 have confidential computing features, but whether those features fall within a validated cryptographic boundary is a separate question from whether they exist.
• Model weights and embeddings are federal data. If you fine-tune a model on federal data, the resulting weights encode that data. The weights need the same cryptographic protections as the source data under FISMA. Most AI deployment architectures treat model artifacts as code, not data, which means they may be stored and transmitted outside validated cryptographic boundaries.
• Key management fragments across services. AI orchestration platforms (LangChain, custom RAG pipelines, agent frameworks) often manage API keys, encryption keys, and session tokens through their own abstractions. If those abstractions do not delegate to a FIPS 140-3 validated module for all cryptographic operations, including key generation, key storage, and key destruction, you have another gap.

The Audit Reality

OMB Memorandum M-22-09 (January 26, 2022) on zero trust architecture pushed agencies toward encrypted DNS, TLS 1.3, and FIPS-validated encryption across the board. Agency Inspector General FISMA audits have been increasingly specific about cryptographic module validation since then. The DHS FISMA metrics for FY2023 and FY2024 include explicit questions about whether agencies maintain inventories of cryptographic modules and their validation status.

For defense contractors, DFARS 252.204-7012 flows down the requirement to use FIPS 140-2 (and by extension 140-3) validated cryptography for all covered defense information. CMMC 2.0 Level 2, which maps to NIST SP 800-171 Rev. 2, includes control 3.13.11: "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." When your AI tool is processing CUI, every cryptographic operation in the pipeline needs to be validated. Not just the TLS termination point.

The Government Accountability Office's September 2023 report (GAO-23-106559) on federal cybersecurity found that 16 of 23 civilian agencies had not fully implemented FISMA requirements, with cryptographic protections cited as a recurring deficiency. Adding AI tools to environments that already struggle with basic cryptographic compliance compounds the problem significantly.

Practical Implications

If you are a contractor or agency deploying AI tools against federal data, you need to do a few things that most AI vendors will not do for you.

First, map every cryptographic operation in the AI pipeline. This includes TLS connections between services, encryption of data at rest in vector databases, encryption of model weights, key derivation for session management, and any cryptographic hashing used for integrity verification of model outputs. Each of those operations needs to be traceable to a specific CMVP-validated module with a certificate number.

Second, treat the cryptographic boundary as an architecture constraint, not a compliance checkbox. If your AI inference service uses OpenSSL, you need to confirm it is running the FIPS provider module (OpenSSL 3.0.x received FIPS 140-3 validation, certificate #4282, in early 2024). If it uses BoringSSL or a cloud provider's custom TLS implementation, you need the corresponding certificate. If there is no certificate, you have a problem that cannot be solved by policy language alone.

Third, document the boundary explicitly. NIST SP 800-53 control SA-4 (Acquisition Process) requires that security requirements, including cryptographic requirements, be documented in acquisition contracts. If you are procuring AI tools, the contract should specify FIPS 140-3 validation requirements and require the vendor to identify every cryptographic module by certificate number.

How FirmAdapt Addresses This

FirmAdapt's architecture was designed with the cryptographic boundary problem as a first-order constraint, not a retrofit. All cryptographic operations within the platform, including data encryption at rest and in transit, key management, hashing, and session token generation, are performed by FIPS 140-3 validated modules with documented certificate numbers. The platform's AI inference pipeline is architected so that federal data never passes through an unvalidated cryptographic operation, including in preprocessing, embedding generation, and response delivery.

For organizations subject to FISMA, DFARS 252.204-7012, or CMMC 2.0, FirmAdapt provides the cryptographic module inventory and boundary documentation that auditors expect. The platform maintains a traceable mapping between each data flow and the validated module protecting it, which simplifies the SC-13 control assessment and reduces the audit burden that typically accompanies AI tool deployment in federal environments.