A software contract can expire before the software ever reaches the field. The accreditation architecture underneath it can stay in place for years. When a Program Management Office (PMO) or Portfolio Acquisition Executive (PAE) organization needs to field an in-demand application, that architecture is the gate, and it can outlast the contract, the vendor, and the original team that selected it.
That selection lands on your program office, yet most writings on the Authority to Operate (ATO) process still target vendors trying to break into government. Program offices, including the newly established PAE organizations, carefully highlight how the organization is structured and funded, but rarely discuss their responsibility to accredit the capability they are acquiring. A program office buys a capability, staffs the team responsible for defending the system, and moves the system through the Risk Management Framework (RMF) and DISA’s Cloud Computing Security Requirements Guide (CC SRG), all while a warfighter or mission owner waits for the delivery date.
Your program office can choose among three basic architectures to get a capability accredited, staffed, and fielded on schedule:
- Government-run software factory.
- Managed commercial platform, or a bring-your-own.
- Program-owned enclave.
A mismatched architecture rarely is visible at the start. The consequences show up later, when a capability fielded at one Impact Level (IL) can force a rebuild from the foundation to reach a higher one.
What a manual ATO costs a program office
The U.S. Department of War (DOW) does not make manual authorizations easy. A traditional RMF authorization built around static Word documents, spreadsheet-driven evidence, and periodic scans typically takes 18 to 24 months to move a system from a lab demo into production. Complex architectures targeting higher ILs routinely stretch past 36 months. A capability designed around an urgent mission requirement can therefore be functionally obsolete before an Authorizing Official (AO) ever signs the risk decision package.
The authorization timeline also compounds into a procurement problem. A platform may already be listed on the U.S. General Services Administration (GSA) Multiple Award Schedule (MAS) but may not be accredited to run in production, leaving the program office to pay for the software and then pay again to build and accredit the underlying infrastructure. Putting the compliance boundary and the compute on the same contract vehicle changes the procurement equation. The platform is directly reachable through a vehicle the agency already uses, the contracting officer can skip a standalone solicitation entirely.
Initial authorization is only the milestone; maintaining the authorization is the recurring operating cost. Under a do-it-yourself model, government or contractor staff indefinitely own 24/7 logging, continuous vulnerability scanning, and incident response. Second Front’s cost analysis puts a typical first-year DIY FedRAMP build at roughly $1.5 million, with complex builds moving past $3.7 million once re-architecture, failed assessments, and 30-month log-retention requirements enter the calculation. Afterward, the in-house Security Operations Center (SOC) required to keep the certification alive costs another $500k to $1M a year. Scale the DIY model across a portfolio of applications, against a shrinking federal cyber workforce, and the authorization problem becomes a staffing problem as much as a budgeting problem.
Federal statute is increasingly arming program offices to fight this inertia. Section 1522 of the Fiscal Year (FY) 2025 National Defense Authorization Act (NDAA) wrote presumptive reciprocity into defense procurement law, flipping the traditional burden of proof. A receiving AO must not presume the cybersecurity adequacy of the peer AO’s authorization and must provide a mission-specific technical justification to reject it.
Section 1521 of the FY2026 NDAA added teeth to that mandate by setting Department-wide cloud ATO timelines and establishing an Expedited Appeals Board chaired by the DOW Chief Information Officer (CIO).
If an applicant goes 180 days without a certification decision, the program office can escalate the case to the board, which has 90 days to rule. Yet, while Congress has provided the legal framework, program offices must still bring forward an airtight, runtime-enforced security package to overcome subjective AO risk aversion. However, in a recent hearing, lawmakers were still pressing the DOW CIO on why the authorization process remained frustratingly slow. The DoW CIO replied this was a top priority for her team to streamline the process through automation to support continuous and dynamic risk assessments. The policy exists; for many DOW programs, the practice is virtually non-existent.
Impact levels set the ceiling, and it does not flow uphill
Program offices size their architecture around the sensitivity of the data involved, using the impact tiers defined in the DISA CC SRG. Those tiers do not stack the way many roadmaps assume: a foundation accredited at a lower tier cannot retroactively protect a workload at a higher one. If a vendor clears FedRAMP Class C (Moderate) and a later contract calls for a Secret-level deployment, the architecture must be rebuilt rather than extended. A program office that architects only for IL2, assuming it can retrofit to IL5 or IL6 later, is walking into what practitioners call the retrofit trap.
The retrofit trap means moving a multi-tenant commercial footprint into a physically separated, U.S.-citizen-only environment after the fact, on the same 18-to-24-month clock the program office was trying to avoid in the first place. Second Front’s Impact Level breakdown covers the control-by-control mechanics for teams sizing the transition in detail.
Reciprocity means inheritance, not paperwork
Reciprocity begins with one AO accepting risk work another AO has already completed, which is the foundation of a layered compliance system. But reciprocity only works when the security work being reused is real.
The distinction is what enforces the controls after the paperwork is finished. An orchestration tool can auto-fill templates and generate a polished System Security Plan, but the document itself does not monitor the system at runtime. A platform hosts the workload, owns the security boundary, and carries the continuous monitoring obligations. AOs increasingly decline reciprocity when the claim rests on inherited paperwork without live technical enforcement behind it, because the AO is responsible for the risk.
The gap between paperwork-only reciprocity and platform-enforced reciprocity dramatically changes how much of the authorization burden a program must absorb. A vendor pursuing a DOW Authorization independently has to implement, document, and defend all 400+ controls in its IL baseline. Deployed on a managed Platform as a Service (PaaS) holding a DISA Provisional Authorization (PA), a vendor deploying In-Boundary can inherit upward of 80 percent of the baseline controls under an existing signed ATO, while an out-of-boundary model still yields roughly 60 percent inheritance for customer-owned packages. For the AO, the practical difference is simple: review one new application layer instead of an entire technology stack. As the DOW moves toward continuous authorization, the value of that model depends on a program office already having a platform capable of producing the live telemetry it requires.
Three ways to build the architecture
Government-run software factories
A software factory gives organic development teams a shared, government-owned continuous integration continuous deployment (CI/CD) pipeline and a pipeline-level continuous ATO (cATO) covering how the factory builds and ships code. For a program funding bespoke software from scratch, the combination can be a genuine force multiplier because developers inherit accreditation for how they build, not merely for what they build.
The limitation appears when the software factory has to host a mature commercial Software-as-a-Service (SaaS) or commercial-off-the-shelf (COTS) product rather than organic code. Onboarding a commercial vendor into a shared, multi-tenant factory environment generally restricts the workload to unclassified, IL2-scoped environments, which falls short of the classification levels many defense programs eventually require.
Beyond classification limits, program offices face a major contractual roadblock when attempting to onboard commercial software into government factories: intellectual property (IP) exposure and source code risk.
Most software factories require access to the vendor’s proprietary source code to execute white-box static code analysis and pipeline tests. Leading commercial SaaS providers and venture-backed dual-use companies routinely refuse to expose proprietary source code to a government repository, triggering months of legal and contracting standstills. In contrast, a true managed PaaS uses container-level scanning under a deny-by-default execution profile, validating compliance without ever touching proprietary source code.
Funding mechanisms introduce another operational bottleneck. Onboarding a commercial vendor into a government factory often requires executing Military Interdepartmental Purchase Requests (MIPRs) or crafting customer contract line items (CLINs) to fund pipeline integration. These inter-agency transfers frequently stall across fiscal quarters. By contrast, accessing a managed commercial platform via established vehicles like the Joint Warfighting Cloud Capability (JWCC) contract allows the program office to bundle the software license, hosting, and accredited compliance boundary into a single task order.
A software factory is an origin point, not necessarily an endpoint. Code developed inside the factory still needs a path into a broader set of commands and classification levels, and a pre-accredited commercial platform can become the path to wider deployment rather than a competing architecture.
Best fit for: When the program is funding organic developers to write bespoke code and wants to use existing DOW CI/CD pipelines from day one. The software factory does not have to be the application’s final destination; once the capability is ready to scale, the resulting code can still move onto a managed platform for distribution across a wider set of commands and classification levels.
Managed commercial platforms
A commercial provider spends the capital and engineering time required to secure high-level accreditations for the platform itself, then allows the program office’s vendor to deploy its application directly into the accredited environment. Because the platform provider owns infrastructure hardening, boundary defense, and continuous monitoring as a core business function, the program office does not have to recreate the Day 2 SOC operation underneath every application it fields.
Second Front’s Game Warden is the clearest working example of the managed commercial platform model in the current market. Game Warden holds a FedRAMP Class D (High) Certification (Marketplace listing FR2410866384), a DISA Provisional Authorization at IL5, and a GovRAMP Authorization. Second Front is one of only seven companies holding all three credentials at once. The platform also spans the full DOW Impact Level range, from IL2 through IL6 plus Top Secret environments, and was the first software platform authorized at IL5 for AWS GovCloud on the JWCC vehicle.
The difference shows up in deployment timelines. Sustainment cut a projected 12-month accreditation timeline to 58 days while reducing its internal accreditation team from ten people to three. Integrate fast-tracked an IL6 deployment in under 12 months on its way to a $25 million SBIR Phase III award, while Learn to Win became the first application to reach IL6 on SIPRNet through Game Warden. Deployments through Game Warden now run in as little as 90 days rather than the traditional 18-to-24-month baseline.
The tradeoff is real. A managed platform is built around modern, cloud-native architectures and a standardized security boundary controlled by the provider, meaning that a highly specialized legacy system or a workload that depends on bespoke hardware integration may find the standardized boundary restrictive rather than useful.
Best fit for: When the program has identified a mature commercial SaaS application or dual-use technology that needs to reach the warfighter across multiple Impact Levels. The managed platform model also fits offices that cannot absorb a $500,000-plus annual SOC bill or wait 18 to 24 months for the accredited environment underneath the application. Vehicles such as JWCC make procurement speed part of the same equation by allowing a program to purchase the software and the accredited environment supporting it in the same transaction.
A bring-your-own, program-owned enclave
The third path gives a program office complete control over architecture, tooling, and data residency through a fully custom, isolated enclave. A program office or vendor builds, documents, and defends the environment independently, generally inheriting only the Infrastructure-as-a-Service (IaaS) layer underneath the enclave. Complete architectural control matters for a narrow set of workloads. Cryptographic modules with no commercial equivalent, physical isolation beyond what IL6 already requires, or direct integration with tactical hardware such as drone telemetry or edge servers that cannot run on shared cloud infrastructure.
The cost of that control is substantial. A program office building its own enclave may inherit roughly 20 percent of the required controls from the underlying IaaS provider, leaving the remaining 80 percent for the program to implement, document, and defend on its own. The authorization effort then falls back onto the traditional 18-to-24-month timeline and can exceed $3 million before the first production workload runs.
What the bring-your-own path costs a program is usually one mission profile, not the entire program. A hardware-in-the-loop system that genuinely needs a custom environment does not mean the rest of the software portfolio should be architected the same way; the enclave can support the specialized workload while a managed platform carries everything else.
Best fit for: For the mission profile that has nowhere else to run, usually a hardware-in-the-loop integration, an air-gapped classification requirement, or a legacy system too monolithic to move onto modern infrastructure. The bring-your-own architecture decision applies to the individual workload. It should not automatically determine how the rest of the program’s software gets built.
| Government-run software factory | Managed commercial platform | Bring-your-own, program-owned enclave | |
| Best fit | Organic, bespoke code development | Fielding existing commercial SaaS or dual-use tech, from IL2 through IL6, plus Top Secret | Cryptographic modules with no commercial equivalent, physical isolation beyond IL6, or hardware-in-the-loop integration |
| Control inheritance | High for the build pipeline, but doesn’t extend to hosting beyond it | Upward of 80 percent, inherited from a live, signed ATO | About 20 percent, from the IaaS layer only |
| Day 2 monitoring | Factory covers the pipeline; the program covers wherever the code ends up hosted | Fully owned by the platform provider | Entirely the program’s or vendor’s responsibility |
| Typical fielding speed | Fast for organic development, slow for onboarding existing commercial SaaS | As little as 90 days | 18 to 24 months, often past 36 for complex builds |
When a different platform model fits better
No single architecture fits every workload.
A monolithic legacy system, for example, may not survive a modern PaaS boundary if the operating system cannot safely move onto shared cloud infrastructure. No amount of evidence-pipeline automation changes the compatibility problem.
Air-gapped weapons systems and shipboard tactical networks present a different kind of exception because the systems require physical, on-premises isolation with no cloud connectivity at all. For those workloads, localized edge deployment platforms like 2F Frontier or specialized custom environments can provide viable options.
Some programs also rely entirely on an organic, uniformed development team to solve a hyper-local problem from the ground up, in which case a commercial PaaS layer may introduce cost without solving a problem the program actually has.
In each case, a government software factory or purpose-built dedicated enclave is the architecture the workload requires, not a fallback.
Choosing your path
The era of choosing one architecture and living with it for the life of a mission is ending. A legislated ATO clock, a fixed deadline for machine-readable evidence, and a retrofit trap that grows more expensive with time are all pressing on the same decision, which makes the architecture question less about finding the easiest authorization available today and more about designing backward from the highest Impact Level the roadmap will eventually require.
Ready to map your program’s accreditation path? Speak with the Second Front team to see how Game Warden can compress the route to DOW ATO.
