Compliance & Accreditation. The ATO stack.

FedRAMP is the Federal Risk and Authorization Management Program. It standardizes how the government assesses cloud services. No FedRAMP authorization, no federal sale (with narrow exceptions).

AI services are not special here. A hosted LLM is a cloud service. A vector database is a cloud service. They need the same paperwork as any other SaaS.

Low

Public data. Loss of confidentiality, integrity, or availability would cause limited harm.

• Approximate control count: 156 controls
• Typical use: public-facing websites, open data portals, low-risk citizen services
• AI implications: rarely the right tier for production AI. Model weights are often sensitive (IP, training data leakage risk). Prompt logs frequently contain CUI even when the app is "public."

Moderate

The workhorse tier. Covers CUI and most internal agency systems.

• Approximate control count: 323 controls
• Typical use: most federal SaaS, internal productivity tools, CUI-handling systems
• AI implications: this is where most agency AI lives. Copilots over agency documents, RAG systems over CUI, fine-tuned models trained on agency data all sit here. Prompt and response logs at Moderate are treated as CUI.

High

Law enforcement, emergency services, financial systems, healthcare. Loss could cause severe or catastrophic harm.

• Approximate control count: 410 controls
• Typical use: IRS, healthcare claims, certain DOJ workloads
• AI implications: stricter encryption-in-use expectations, tighter incident response timelines, more aggressive continuous monitoring. Model serving at High often pushes teams toward dedicated tenants instead of multi-tenant SaaS.

FedRAMP Tailored / Low-Impact SaaS (Li-SaaS)

A lighter path for SaaS that handles low-impact data with limited functionality.

• Smaller control set, faster timeline
• Typical use: collaboration tools, simple form intake, internal-use-only SaaS with no public data exposure
• AI implications: most generative AI services don't fit Li-SaaS because the data sensitivity is hard to bound. If your service stores prompts, treat it as Moderate.

Tier	Approx. controls	Audit timeline (typical)	Continuous monitoring cadence
Low	~156	6-9 months	Annual assessment, monthly POA&M
Moderate	~323	12-18 months	Annual assessment, monthly POA&M, monthly vuln scans
High	~410	18-24 months	Annual assessment, monthly POA&M, weekly vuln scans
Li-SaaS	~125	3-6 months	Annual self-attestation

Control counts are approximate and based on 800-53 Rev 5 baselines as of 2026-06; verify before citing in proposals.

FedRAMP 20x

FedRAMP 20x is the program's effort to modernize authorization. The goal: machine-readable packages, continuous authorization, less PDF-shuffling.

As of 2026-06, the 20x pilot phase is active. The PMO is using OSCAL (Open Security Controls Assessment Language) for the package itself. Key changes:

• Authorization packages delivered as OSCAL JSON, not Word documents
• Continuous monitoring data flows machine-to-machine
• Reuse of common controls across cloud providers without re-attestation

FedRAMP 20x program status as of 2026-06; verify before citing in proposals. The program has shifted scope multiple times since 2024.

If you are building new, author your SSP in OSCAL from day one. The retrofit is painful.

Continuous monitoring (ConMon)

Authorization is not a one-time event. After ATO, you owe the agency:

• Monthly POA&M updates (Plan of Action and Milestones)
• Monthly vulnerability scans (weekly at High)
• Annual assessment by a 3PAO
• Incident reporting per agency-defined timelines
• Significant change requests before major architecture shifts

A model swap (GPT-4 to Claude, Llama 3 to Llama 4) is often a significant change. Plan for the paperwork.

How AI changes the FedRAMP picture

The framework was written before generative AI was operational. Three places the seams show:

1. Model weights are data. A fine-tuned model contains training data residue. Treat weight files as the highest sensitivity of any input that touched them.
2. Training data is data. If you train on CUI, the model is a CUI artifact. Export controls and access controls apply.
3. Prompt and response logs are data. Users paste sensitive content into prompts. Your logging pipeline inherits that sensitivity. Plan retention, encryption, and access accordingly.

FedRAMP does not yet have AI-specific control overlays. NIST AI RMF and OMB M-24-10 fill that gap. OMB M-24-10 superseded prior OMB AI memos in 2024; verify the active version as of 2026-06 before citing.

Audit reality

Activity	Typical duration
Readiness assessment	2-3 months
3PAO assessment	3-6 months
PMO review and JAB / Agency ATO	3-9 months
Total elapsed (first-time Moderate)	12-18 months
Total elapsed (first-time High)	18-24 months

Most teams underestimate the SSP writing phase. Plan 6 months for SSP, SAP, SAR, and POA&M before the 3PAO walks in.

The DoD Cloud Computing Security Requirements Guide (SRG) defines Impact Levels. IL2 is the lowest. IL6 holds Secret. IL7 (Top Secret) exists in concept but is not a generally authorized commercial tier.

If you are selling cloud or SaaS to DoD, the IL determines who can run it, who can touch it, and where the bits can live.

The five levels at a glance

Level	Data type	FedRAMP baseline	US person admins required?	Common workloads	AI implications
IL2	Public, non-critical mission info	Moderate	No	Public DoD sites, low-sensitivity SaaS	Public-facing chatbots, general-purpose copilots over public docs
IL4	CUI, non-CUI sensitive	Moderate + DoD overlay	Yes (US persons)	Most DoD CUI workloads	RAG over CUI doctrine, fine-tuned models on FOUO data
IL5	Higher-sensitivity CUI, mission-critical	High + DoD overlay	Yes (US persons, cleared admins for some)	National security systems with CUI, C2 support	Most operational DoD AI: targeting support, intel triage at CUI
IL6	Classified up to Secret	High + DoD overlay + SIPR	Yes, cleared at level	SIPR-resident workloads	Classified AI: cleared LLMs, SIPR-side RAG, multi-INT fusion
IL7	Top Secret (conceptual)	N/A	N/A	Not a commercial tier	Custom solutions, agency-specific

Mapping of FedRAMP baseline to IL is current as of 2026-06; verify in the latest DISA Cloud Computing SRG before citing.

IL3 was retired and folded into IL4. You will still see IL3 in old docs. Treat it as IL4.

IL5 vs IL6: where the boundary sits

The trigger is data classification, not workload sensitivity. If the data is classified Secret, you need IL6. If the data is CUI no matter how mission-critical, you sit at IL5.

Practical effects of the IL5 to IL6 step:

• IL6 lives on SIPRNet. No internet path. Provisioning, patching, and monitoring all run over classified networks.
• All admins need a Secret clearance at minimum. Many roles need higher.
• Physical security of the data center: SCIF-equivalent.
• Hardware is dedicated. No multi-tenancy with non-DoD or non-cleared tenants.
• Cross-domain transfer (NIPR to SIPR) requires a CDS (Cross Domain Solution). No casual data movement.

For AI specifically: model weights trained on Secret data are themselves Secret. You cannot fine-tune at IL5 and deploy at IL6 without a CDS event for the weights. Most teams train and serve on the same side.

Authorized cloud providers

Provider	IL2	IL4	IL5	IL6
AWS GovCloud (US)	Yes	Yes	Yes	AWS Secret Region
Microsoft Azure Government	Yes	Yes	Yes	Azure Government Secret
Microsoft Azure Government Top Secret	N/A	N/A	N/A	TS (separate auth)
Oracle Government Cloud	Yes	Yes	Yes	Limited
Google Distributed Cloud (air-gapped)	Yes	Yes	Yes (select regions)	Limited
IBM Cloud for Government	Yes	Yes	Limited	N/A

Provider authorizations shift. Status as of 2026-06; verify against the current DISA Cloud Marketplace before citing in proposals.

For AI workloads, the practical landscape as of 2026-06:

• IL4/IL5 commercial frontier models: available through Azure Government (OpenAI) and AWS GovCloud (Bedrock with Anthropic Claude, others). Verify model availability and IL coverage at time of proposal.
• IL6 frontier models: more limited. Most teams ship open-weight models (Llama family, Mistral family) onto SIPR-resident GPU infrastructure.

Common gotchas

Connectivity. IL4 and IL5 workloads traverse the Cloud Access Point (CAP) when reaching agency networks. The CAP is a chokepoint. Throughput-sensitive AI (high-token-per-second serving) needs capacity planning with the CAP operator.

NIPR vs SIPR boundaries. Code, models, and data do not cross networks by email or USB. Cross-domain transfer needs a CDS. Plan your CI/CD on the side where the workload lives.

Data spill. A spill happens when classified data lands on a lower-classification system. For AI: a user pastes Secret content into an IL5 prompt. The logs now contain Secret data. The whole logging system gets sanitized or destroyed. Build prompt-side classification filters and assume spills will happen.

US person admin requirement. From IL4 up, cloud admins with access to the customer environment must be US persons. From IL5 up, often cleared. This narrows the labor pool and shows up in pricing.

Foreign-developed model weights. If a model was trained outside the US, expect questions about supply chain, training data provenance, and embedded backdoors. Open-weight models with US-based training pipelines have a smoother path.

NIST SP 800-53 Rev 5 has 20 control families and over a thousand individual controls. You will not memorize them. You will see the same ones over and over on AI systems.

Five families do most of the work for AI deployments. Learn the controls below and you will hold your own in an assessment.

AC: Access Control

The assessor's first stop. Who can call your model, who can read its outputs, who can touch its weights.

Control	What it covers	AI-specific reading
AC-2	Account management	Service accounts that call model APIs. Each agent or tool needs its own identity, not a shared key.
AC-3	Access enforcement	The serving layer must enforce per-user authorization on every inference call. "The frontend checks it" is not enough.
AC-6	Least privilege	The model's tool-use scope. If the LLM has a database tool, the tool's DB role gets only the rows it needs.
AC-17	Remote access	How developers reach training infrastructure. Bastion plus MFA, not direct SSH.

"Least privilege" for AI is harder than for traditional apps. A capable agent wants broad tools. Resist the urge to give it admin. Scope every tool to the minimum row, file, or endpoint it needs.

AU: Audit and Accountability

The assessor's second stop. Can you reconstruct what happened?

Control	What it covers	AI-specific reading
AU-2	Event logging	Every prompt, every response, every tool call, every model version. Timestamp, user, session.
AU-3	Content of audit records	Enough detail to reconstruct the decision: input, output, model id, system prompt hash, retrieved documents.
AU-6	Audit review and analysis	Someone reads the logs. Not just stores them. Anomaly detection on prompt patterns counts.
AU-12	Audit record generation	The logging is built in, not bolted on. Generated by the serving layer, not by middleware that can be bypassed.

The gap most AI teams hit: they log prompts and final responses but not the intermediate reasoning, tool calls, or retrieved context. When an incident hits, that intermediate trace is what the IR team needs. Log it.

CM: Configuration Management

What exactly is running, and how did it get there?

Control	What it covers	AI-specific reading
CM-2	Baseline configuration	The model version, the system prompt, the retrieval index version, the tool definitions: all pinned. "Latest" is not a baseline.
CM-3	Configuration change control	Model swap goes through change control. Prompt template edits go through change control.
CM-7	Least functionality	Turn off tools, plugins, MCP servers you don't need. Each enabled capability is attack surface.
CM-8	System component inventory	The component list includes models, embeddings, fine-tunes, datasets, prompt templates. Not just containers.

A model is a configuration item. A system prompt is a configuration item. A retrieval corpus is a configuration item. Treat them like code: versioned, reviewed, deployed through a pipeline.

IA: Identification and Authentication

Who or what is calling?

Control	What it covers	AI-specific reading
IA-2	User identification and authentication	The end user authenticates to the app. The app does not just pass a service account to the model.
IA-5	Authenticator management	API keys, OAuth tokens, certificates used by the model to call tools. Rotation, storage, scope.
IA-9	Service identification and authentication	When the model calls an internal API, it presents an identity that the API verifies. mTLS, signed JWTs, SPIFFE.

Agentic systems break IA assumptions. An agent acting on behalf of a user needs delegated authentication. The tool call must carry the user's identity, not the agent's. OAuth on-behalf-of flows or signed identity tokens. Plan this before the assessor asks.

SI: System and Information Integrity

Is the system behaving the way it should?

Control	What it covers	AI-specific reading
SI-2	Flaw remediation	Patching the inference runtime, the model server, the CUDA drivers, the embeddings library. Inventory and timelines.
SI-3	Malicious code protection	Model files can carry malicious payloads (pickle exploits, embedded executables). Scan weight files before loading.
SI-4	System monitoring	Detecting prompt injection attempts, jailbreaks, anomalous tool-call patterns.
SI-7	Software, firmware, and information integrity	Hash-pinned model weights. Verify the SHA before loading. Signed model artifacts where possible.
SI-10	Information input validation	Input filtering on prompts. Output filtering on responses. This is your prompt injection defense layer.

SI-10 is where prompt injection lives. The assessor will ask: how do you validate input that contains both user instructions and retrieved content? If you don't have an answer, write one before they ask.

I'm worried about X: read these controls

Concern	Start here
Prompt injection	SI-10, SI-4, SC-7
A leaked API key giving the model access to too much	AC-6, IA-5, IA-9
Reconstructing what the model said and why	AU-2, AU-3, AU-12
Model swap silently changing behavior	CM-2, CM-3, CM-8
Malicious weights from an untrusted source	SI-3, SI-7, SR (Supply Chain Risk)
User can see another user's prompts	AC-3, SC-4, SC-28
Training data leaking through model outputs	AC-3, SC-8, plus NIST AI RMF MAP-2
Insider misusing the model	AU-6, AC-2, PS (Personnel Security)

The families above are not exhaustive. SC (System and Communications Protection), SR (Supply Chain Risk), and CP (Contingency Planning) all show up on real ATO packages. Start with the five above. The rest will follow.

A STIG (Security Technical Implementation Guide) is DISA's prescriptive hardening guide for a specific product or technology. Each STIG is a list of checks with severity (CAT I, II, III), the fix, and how to verify.

STIGs update on a quarterly cadence. If you cite a specific check ID, verify it is still current.

Most common STIGs hit by AI deployment stacks

RHEL 9 STIG. The most common OS STIG for new DoD AI work as of 2026-06. Covers SSH hardening, auditd config, file permissions, FIPS mode, SELinux. Expect 200+ checks. GPU driver installs frequently break STIG-mandated kernel module signing.

Ubuntu 22.04 STIG. Common where teams want CUDA on a recent distro without RHEL's licensing. Similar shape to the RHEL STIG. The audit subsystem (auditd) and AppArmor rules are the usual friction points.

Ubuntu 24.04 STIG status as of 2026-06; verify before assuming coverage. Newer LTS releases often lag the STIG by 12 to 18 months.

Kubernetes STIG. Pod Security Standards, RBAC, etcd encryption, audit logging, admission controllers. AI workloads with GPU operators, custom resources, and Helm charts collect findings fast.

Docker Enterprise / Containerd STIG. Image signing, registry trust, seccomp profiles, no privileged containers. GPU passthrough often requires capabilities that violate the STIG by default. Document the exception.

The DISA "Docker Enterprise" STIG covers a specific runtime. Status of a general containerd STIG as of 2026-06; verify before citing.

NGINX STIG. Common for inference gateways and RAG front ends. TLS config, header policies, request limits, logging.

PostgreSQL STIG. Used for vector databases (pgvector), application data, and audit log storage. Authentication, encryption at rest, audit logging.

Application Security and Development (ASD) STIG. The catch-all for custom-built apps. SDLC controls, input validation, error handling, dependency management. Your AI app code is assessed against this.

What container STIGs mean for inference serving

Inference servers (vLLM, TGI, Triton, Ollama, llama.cpp) ship as containers. The container STIG applies to the image, the runtime, and the orchestrator.

Common friction:

• Privileged containers. GPU drivers often want --privileged or specific device capabilities. The STIG prohibits privileged by default. Use the NVIDIA Container Toolkit with device plugins and CDI; avoid privileged.
• Root inside the container. Many inference images run as root. STIG wants non-root. Build a non-root variant or document the exception with mitigations.
• Image provenance. Pull from Iron Bank where possible. If you can't, sign your own images and pin by digest.
• Seccomp and AppArmor profiles. Default profiles often block syscalls CUDA wants. Custom profiles, not disabled profiles.

SCAP automation

SCAP (Security Content Automation Protocol) is how STIG checks get automated. The scanner reads an XCCDF benchmark, runs OVAL checks against the system, and produces a results file.

What actually runs:

• SCAP Compliance Checker (SCC) or OpenSCAP runs against each host.
• The scanner walks the XCCDF benchmark, executes OVAL definitions (config reads, file checks, command runs).
• Output: an XCCDF results file with pass/fail per check.
• Findings feed STIG Viewer or eMASS for the POA&M.

What SCAP catches well: file permissions, sysctl values, service states, package versions, audit rule presence.

What SCAP misses: anything that requires judgment. "Is the system prompt protected from disclosure?" is not an OVAL check. Manual review fills the gap.

The 5 findings AI teams always get on first pass

1. FIPS mode not enabled on the GPU host. The OS is FIPS, the GPU driver loads cleanly, but the inference runtime uses non-FIPS crypto for TLS to backends. Fix: pin TLS libraries to FIPS-validated builds; verify with the CMVP certificate number.

2. Container running as root. Inference container UID 0. Fix: build a non-root variant. If the runtime refuses, document the exception and add compensating controls (read-only root filesystem, no capabilities).

3. Audit logging gaps in the model server. vLLM or TGI logs to stdout. The host captures it but not at the level AU-3 wants. Fix: emit structured audit events from the serving layer, ship to the central audit collector, retain per AU-11.

4. Model weights not integrity-verified at load. Weights pulled from a registry, no hash check at load time. Fix: pin by SHA, verify at load, fail closed if mismatch.

5. Default admin credentials on a sidecar. A vector DB, a metrics endpoint, a model registry shipped with default creds. Fix: rotate at deploy, store in a secrets manager, enforce in CI before the image lands in the registry.

An SBOM (Software Bill of Materials) is a structured inventory of the components in a piece of software. Think nutrition label.

For AI systems, the label gets longer. The model is a component. The embeddings model is a component. The training data is a component, or at least a referenced artifact. The fine-tuning corpus is a component.

SBOM in plain English

For every piece of software you ship, list:

• What it is (name, version, purpose)
• Where it came from (publisher, source repo, registry)
• What's inside it (sub-components, libraries, dependencies)
• How to verify it (hash, signature)
• How it's licensed

The buyer can then answer questions like: "When CVE-2026-12345 drops against libssl, which of my systems are exposed?" Without an SBOM, the answer is a long Friday.

SPDX vs CycloneDX

Format	Maintained by	Strengths	Pick when
SPDX	Linux Foundation	Mature license metadata, ISO/IEC 5962:2021 standard	License compliance is the primary driver; you already use SPDX-License-Identifier tags in source
CycloneDX	OWASP	Strong vulnerability and supply-chain extensions; ML-BOM and CRYPTO-BOM profiles	AI/ML components, cryptographic inventory, deeper vulnerability tracking

For AI work specifically, CycloneDX has a dedicated ML-BOM extension (machine learning bill of materials) that represents models, datasets, training runs, and inference configs as first-class objects. SPDX 3.0 added AI and dataset profiles to close the gap.

Most federal teams accept either. Pick one and be consistent across your pipeline.

EO 14028

Executive Order 14028, "Improving the Nation's Cybersecurity," issued May 2021. Established SBOM as a federal procurement requirement for software vendors.

Flow-down from 14028:

• NTIA published "Minimum Elements for an SBOM" (July 2021)
• NIST SP 800-218 (Secure Software Development Framework, SSDF) operationalized the secure-development requirements
• OMB M-22-18 and follow-on memos required agencies to obtain attestations from software producers

EO 14028 SBOM provisions remain active as of 2026-06. Subsequent EOs have layered AI-specific requirements on top; verify the current AI EO before citing in proposals. The number has changed since 2023.

In practice today: if you sell software to a federal agency, you provide an SBOM and a CISA self-attestation form.

CISA SBOM guidance

CISA leads the federal SBOM effort. Useful artifacts:

• "Minimum Elements for a Software Bill of Materials" (NTIA, 2021). The seven baseline fields every SBOM entry needs.
• Secure Software Self-Attestation Form. The form CIOs collect from software producers under M-22-18.
• SBOM use cases and reference architecture. How to consume SBOMs across an agency.
• VEX (Vulnerability Exploitability eXchange). Companion document. Tells the buyer whether a known CVE in a component is actually exploitable in your product.

VEX matters for AI. A model framework will carry dozens of transitive CVEs. Most are not exploitable in your deployment. VEX is how you communicate that without the buyer chasing every one.

DoD requirements

DoD applies the federal SBOM baseline and adds DoD-specific guidance through OUSD(A&S) memos and DAU education.

As of 2026-06, expect SBOM requirements written into:

• DFARS clauses on cybersecurity (252.204-7012 and friends)
• Contract language under PWS / SOO for software deliverables
• Iron Bank container submission requirements (SBOMs at image build time)

DFARS clause numbers and SBOM-specific language change with rule updates; verify against the current DFARS as of 2026-06 before citing in proposals.

DoD continues to push SBOM consumption into eMASS workflows. If your product ships to a DoD program, the SBOM lands in the program's ATO package.

AI-specific representation

The traditional SBOM was built for compiled binaries and library trees. AI needs more. Two extensions cover the gap:

• CycloneDX ML-BOM. Defines component type: machine-learning-model and data types. Captures training data sources, model architecture, hyperparameters, evaluation metrics.
• SPDX 3.0 AI profile. Adds AI package types, dataset packages, energy consumption fields, intended-use documentation.

For a fine-tuned model deployed in production, your SBOM should represent:

• The base model (name, publisher, version, license, hash of weight files)
• The fine-tuning dataset (source, size, date, license/clearance, sensitivity)
• The training pipeline (framework, version, hyperparameters)
• The fine-tuned model artifact (hash, format, quantization)
• The serving runtime (vLLM, TGI, Triton): version and container hash
• The embeddings model if RAG is involved
• The vector index version and the corpus it indexed

The 6 fields every AI SBOM entry needs

For each AI component (base model, fine-tune, dataset, embeddings model):

1. Component name and version. Unambiguous. "llama-3.1-8b-instruct" not "Llama".
2. Publisher / source. Where the artifact came from. Hugging Face repo + commit, internal registry path, contract deliverable ID.
3. Cryptographic hash. SHA-256 of the weight file or container digest. Pinned, verified at load.
4. License or use restriction. Apache 2.0, Llama Community License, government-furnished, ITAR-controlled. The legal posture of using the weights.
5. Training data provenance. For base models: what the publisher disclosed (often limited). For fine-tunes: explicit dataset reference with sensitivity classification.
6. Intended use and known limitations. Pulled from the model card. The procurement and ATO teams need this in writing.

The NTIA minimum elements give you the first three for free. The last three are the AI-specific lift. Build them into your build pipeline so the SBOM is generated, not hand-written.