Ask anyone who has sold software to the government what the slowest part was, and you’ll often hear the same answer: not building it, but getting approval to run it. That approval is an Authority to Operate, or ATO, and for a small vendor it can feel like a wall.
That’s starting to change. Two efforts, one on the defense side and one government-wide, are pushing in the same direction. Here’s what they are and what a small software team should do about them.
Why ATO has been the bottleneck
A traditional ATO is a point-in-time review. You document your system, an assessor reviews it against a set of controls, and someone accepts the risk. Then you change the software, and the question becomes how much of that work you have to repeat.
That model fits poorly with teams that ship every week. The Department of Defense said as much in an April 2025 memo, Accelerating Secure Software: “Lengthy, outdated cybersecurity authorization processes frustrate agile, continuous delivery.”
SWFT: the Software Fast Track
That memo, signed by Katherine Arrington, then performing the duties of DoD CIO, set up the Software Fast Track (SWFT) initiative. It directed the department to define clear, specific:
- Cybersecurity and supply chain risk management (SCRM) requirements
- Rigorous software security verification processes
- Secure information-sharing mechanisms
- Government-led risk determinations to speed up cybersecurity authorizations
The memo is also blunt about open source: the department “currently lacks visibility into the origins and security of software code.” Expect questions about where your dependencies come from.
The department then asked industry for input. The combined RFI summary describes what respondents already do: continuous monitoring, code reviews, regular penetration testing and red-teaming internally, plus third-party audits and independent penetration tests. Respondents tied this to frameworks like FedRAMP, NIST, SOC 2 and ISO 27001. As GovCIO reported, the feedback pushed the Pentagon to move past “checking boxes” toward a data-driven trust model, including continuous ATO.
Continuous ATO in plain terms
Continuous ATO (cATO) flips the model. Instead of proving security once and hoping nothing changes, you show that your platform and process keep the software secure as it changes: automated testing, monitoring and supply chain controls running all the time, with evidence a reviewer can check.
The key shift for a vendor: your pipeline is the evidence. If your build system scans, tests and records everything automatically, you have most of what a reviewer wants. If it doesn’t, you’ll be assembling documents by hand every release.
FedRAMP 20x: the same idea for cloud services
On the civilian side, FedRAMP 20x is rebuilding how cloud services get authorized. The program says it’s in Phase 3, wide-scale adoption.
The milestones so far:
- A Moderate pilot ran from November 18, 2025 through March 2026. FedRAMP received 14 qualifying submissions, and the first cohort got pilot authorizations on March 6, 2026.
- The pilot tested Key Security Indicators, machine-readable measures of a provider’s security, at the Moderate level.
- FedRAMP 20x will first support Class A (Pilot), Class B (Low) and Class C (Moderate) certifications, with a High pilot planned next.
- FedRAMP says it will stop accepting new Rev5 certifications on June 11, 2027.
FedRAMP itself notes that future dates are estimates and will shift.
What they have in common
SWFT and FedRAMP 20x come from different places, but they reward the same things:
- Automated, machine-readable evidence instead of static documents
- Visibility into the software supply chain: what’s in your code and where it came from
- Continuous monitoring rather than one-time checks
- Independent verification where the risk calls for it
What small vendors should build in now
You don’t need to wait for final rules to get ready. Everything below is good engineering anyway.
A real CI/CD pipeline
Every change goes through the same automated build, test and deploy path. No manual deploys from someone’s laptop.
Software bills of materials
Generate an SBOM on every build so you can say exactly which dependencies, at which versions, are in each release.
Automated scanning
Static analysis, dependency vulnerability scanning and container image scanning, run on every build, with results saved.
Infrastructure as code
If your environments are defined in code, you can show exactly how they’re configured and that they haven’t drifted.
Logging and monitoring you can export
Centralized logs and alerts, with a way to share evidence without giving outsiders the keys.
Clear access control
Know who can touch code, pipelines and production, and keep a record.
Don’t overbuild
A three-person startup doesn’t need an enterprise compliance platform on day one. Start with the pipeline, the SBOM and the scanning. Add the rest as contracts and data sensitivity require it. The goal is that when someone asks for evidence, you can produce it from your systems instead of writing it from scratch.
Where we help
We build and run DevSecOps pipelines, cloud infrastructure and the evidence trail that goes with them. For defense startups without a senior technical leader, we also serve as a fractional CTO to make these decisions early. See our defense and dual-use page or book a call.
