The sentence that arrives before the contract does
Most teams meet this world sideways. You have a working product, commercial customers, a model that performs — and then a program office or a prime says "we would need this at IL5," or "it has to run inside our enclave, disconnected." The instinct is to hand that to legal. It is an architecture problem, and it hurts when it arrives late because the answers change the software, not the paperwork.
On the name: Executive Order 14347, signed 5 September 2025, authorizes "Department of War" as a secondary title for the Department of Defense in non-statutory communications. Only Congress can change the statutory name, so both are correct — and "DoD" is what appears in the regulations below.
One document decides most of it
The controlling document is the DoD Cloud Computing Security Requirements Guide, maintained by the Defense Information Systems Agency and published on the DoD Cyber Exchange. It sorts information into four impact levels — IL2, IL4, IL5 and IL6 — and attaches requirements for separation, location, connectivity and personnel to each. There is no IL1 or IL3; an earlier model had six, and two were folded into their neighbors.
Two changes matter to anyone reading older summaries. DISA re-issued the guide as two documents — one for cloud service providers, one for mission owners — and moved the baseline to NIST SP 800-53 Revision 5, so check any citation you read, including ours, against the current release. And the guide is not FedRAMP: FedRAMP is the floor, set as the minimum baseline for DoD cloud services by a DoD CIO memorandum of 15 December 2014, and impact levels layer DoD requirements on top. "FedRAMP IL5" describes nothing.
| Level | What the SRG says it covers | What it forecloses for a product team |
|---|---|---|
| IL2 | Publicly releasable information, and unclassified information not designated CUI. | Little. Most commercial SaaS reaches it on a FedRAMP Moderate posture. |
| IL4 | Controlled unclassified information and other non-public mission data. | Open internet access. Traffic arrives through a DoD cloud access point, which changes who can reach the login page. |
| IL5 | CUI needing protection beyond IL4, and unclassified national security system data. | Shared tenancy with commercial customers. Physical separation from non-DoD, non-federal tenants is required — a hosting decision. |
| IL6 | Classified national security information up to SECRET, and no higher. | Everything that assumes a network. A closed enclave reached only from SIPRNet has no package index, no model hub. |
Level definitions and their separation, location and connectivity requirements: DoD Cloud Computing Security Requirements Guide (DISA), on the DoD Cyber Exchange at public.cyber.mil. IL5 separation sat at §5.2.2.3 in the numbering vendor guidance still cites. Third column is our reading, not SRG language.
Which of the three shapes you are
Settle the role first — most product companies are in two at once.
You offer a cloud service. The offering needs a DoD Provisional Authorization from DISA at the level in question, and DFARS 239.7602-1 directs the contracting officer — narrow exceptions aside — to award only to a cloud service provider granted one at the level appropriate to the requirement, checked against the DoD Cloud Service Catalog. A whitepaper does not substitute for the listing.
Your software runs inside someone else's authorized environment. You inherit their boundary, egress rules, logging destination and identity provider, and must break none of it. The authorization is their authorizing official's; your job is to be reviewable by a person you will never meet.
You handle controlled unclassified information on your own systems. This surprises people, because it can begin with one email attachment. DFARS 252.204-7012 requires safeguarding covered defense information, implementing NIST SP 800-171, and — where an external cloud service holds it — that the provider meet requirements equivalent to the FedRAMP Moderate baseline. It also requires reporting a cyber incident at dibnet.dod.mil within 72 hours, using a DoD-approved medium assurance certificate obtained in advance. Getting one on the day of an incident is not a plan.
Where the data may sit
DFARS 252.239-7010 requires a contractor to keep government data within the United States or outlying areas unless the contracting officer authorizes otherwise. That reaches further into an AI system than teams expect, because here "the data" is not the production database. It is the training corpus, the checkpoints, the retrieval index, the evaluation set, the prompts and the run logs. A vector index over controlled documents holds what those documents held; embedding is not a laundering step.
Separation is where cloud shopping breaks, because a region labeled "government" is not an impact level. Microsoft's own IL5 guidance for Azure Government is unusually direct: the dedicated DoD regions give physical separation from non-DoD tenants by design, while in US Gov Arizona, Texas and Virginia you must place IL5 virtual machines on Azure Dedicated Host or isolated VM types and use customer-managed keys in Azure Key Vault. That is vendor documentation saying the same region both is and is not suitable, depending on how it is set up.
What one outbound call forecloses
The most consequential line in a defense-facing architecture is the one that calls somebody else's API. In a commercial product it is invisible — it is how the thing works. Inside an accredited boundary it is a data flow, and every data flow lands on a diagram someone signs.
NIST SP 800-53 Rev. 5 control SC-7 governs boundary protection, and unattributed egress from a vendor component is what an assessor goes looking for. At IL4 and IL5 the endpoint on the far side becomes part of your data path and would have to be authorized at the same level, which a commercial API is not. At IL6 the question does not arise, because the enclave is closed. So "we call a hosted model" is not an integration detail; it decides whether the product deploys. And teams underestimate how many calls an application makes on its own:
- Hosted inference endpoints — usually left in a "just for now" path nobody removes.
- Runtime package installs — a pip or npm resolution at container start is a network dependency.
- Model weight downloads — pulling from a public hub on first run means the artifact you shipped was incomplete.
- License checks — a phone-home that fails closed takes the product down on day one.
- Analytics and bundled front-end assets — crash payloads, web fonts, CDN scripts and map tiles all leave the browser.
The design answer is simple and uncomfortable: everything needed at runtime is inside the boundary at install time, and anything from outside arrives as a signed, hashed artifact the customer brings in. More on shipping into a customer-controlled sandbox and what runs offline.
Model hosting: three shapes that survive review
A managed model service already inside an authorized boundary. The shortest path when it fits. Microsoft has announced Azure OpenAI as authorized at DoD IL4 and IL5 within Azure Government, and AWS publishes model-by-model FedRAMP High and DoD IL4/IL5 approval status for Amazon Bedrock in GovCloud (US). The caveat is the whole game: authorization is per service, per model and per region, so the authority is the DoD Cloud Service Catalog and the provider's audit-scope page — never a marketing page, and never an assumption that a new model inherits its predecessor's status. See our comparison of managed model services.
Weights you host yourself inside the boundary. You take on serving, capacity, hardened images and patching, and get an unambiguous answer to "what does it talk to?"
A headless artifact installed into the customer's enclave. Smallest surface, hardest packaging problem. The three are not interchangeable — retrieval design, latency budget and evaluation harness differ — so choose before the design doc.
Nothing arrives pre-accredited
DISA assesses a cloud service offering and issues a Provisional Authorization for the levels it supports. A mission owner's authorizing official then leverages that PA to grant an ATO for the system running on top. An IL5-authorized platform hands your assessor inherited evidence; it does not authorize your product. Any vendor — ours included — calling a component "pre-accredited," or quoting a guaranteed authorization date, is describing a decision that belongs to a government official they have never met.
Logging is where product teams get surprised
Your logs contain the information your system handled, so they carry its level and belong inside the boundary rather than beside it. That invalidates most commercial observability stacks: error tracking, session replay and hosted APM are egress with a vendor on the far end, wired in so early nobody remembers they are there.
The subtler shift is what the records are for. In a commercial product logs are yours; in an accredited system they are evidence for someone else, and the AU control family in NIST SP 800-53 Rev. 5 governs which events are logged, who reviews them, how audit information is protected from modification, and how long it is kept. For an AI system the awkward part is that prompts and completions are the audit trail — fail to record them and you cannot answer "what did this system tell the analyst on the fourteenth"; record them and they inherit the level of the underlying data. What works: write to a path the customer designates, readable without your tooling, forwarded to their SIEM — and accept that you do not get the logs. More on federal auditability.
Identity: delete your user table
Self-serve signup, magic links, social login and a local password store all rest on an assumption that does not hold here. Federal logical access rests on HSPD-12 and the FIPS 201 standard for Personal Identity Verification credentials; the DoD Common Access Card is the department's implementation. Your application will not be issuing anyone an identity. Federate to the customer's identity provider over SAML or OIDC, take roles from their directory, use their privileged-access process rather than shipping an admin account, and expect single-tenant deployment per environment. Most of the work is in what you remove; the rest is making authorization legible, because an assessor will ask how a role maps to a permission and "it is in the code" does not survive that.
One adjacent rule, stated neutrally because it is routinely misread. The SRG limits which cloud service provider personnel may access systems processing DoD information: at IL4 and IL5 to U.S. persons, at IL6 to U.S. citizens with the required clearance. "U.S. person" is a legal-status term defined at 22 CFR 120.62 that includes lawful permanent residents — considerably broader than "citizens only." These are requirements on a provider's staffing and facilities, settled in a contract and a system security plan, not a screening heuristic for the engineers on your own team.
What this does to the roadmap
This is not a feature. It is a second shape of the same product: offline-installable, single-tenant, telemetry-free, with a versioned interface contract, a signed artifact, a bill of materials and an update path the customer controls. Teams that budget it as a feature find halfway through that the enclave build has forked and fallen behind, then make the parity call under time pressure. Budget the calendar the same way: authorization runs on the government's schedule, and what you control is how reviewable the system is when it gets there. That substrate is what our IL5 cloud engineering work covers — landing zones in Azure Government and AWS GovCloud, service-by-service accreditation checks against the DoD Cloud Service Catalog, STIG-compliant images, cloud-access-point routing, CAC/PIV-backed identity, and boundary documentation matching the architecture.
Where our scope ends
We do not issue authorizations, and cannot shorten someone else's
Authorizing officials grant ATOs; DISA issues provisional authorizations to offerings. We build to the control set, generate the evidence, and write the system security plan sections. See ATO engineering.
We are not a C3PAO and cannot certify you for CMMC
Level 2 certification assessments are performed by CMMC Third-Party Assessment Organizations authorized under 32 CFR part 170. We implement NIST SP 800-171 and scope the CUI enclave; the assessment goes to someone you pick.
We will not assess our own work
An assessment is worth only the independence behind it. If we build a system, its independent evaluation goes to a party with no stake in the finding.
We hold no facility clearance today and do no classified work on classified networks
Under the NISPOM at 32 CFR part 117 a facility clearance is sponsored by a government contracting activity or a cleared prime; a company cannot apply on its own. We build to the constraints those environments impose. Full scope, including what else we decline: what we build and what we decline.
Frequently asked questions
No. Impact level attaches to information, and earned service by service. Providers publish which services carry a DoD provisional authorization at which level, and vendor guidance is explicit that some regions need extra isolation — dedicated hosts, customer-managed keys — first.
Not as an ordinary outbound call. The endpoint becomes part of the system's data flow and would need authorization at the same level. The workable paths are a managed model service already authorized inside the boundary, weights you host there, or a headless artifact.
FedRAMP is the program DoD adopted as its minimum baseline in a December 2014 DoD CIO memorandum. Impact levels are a DoD construct in the Cloud Computing SRG, adding separation, location, connectivity and personnel requirements — side by side.