Three times in the past two years, I've watched the same thing happen: a program office wants a commercial software product, the vendor prices the authorization work, and the number is large enough that nobody moves. The project doesn't die because the problem is unsolvable. It dies because nobody can distinguish the $2M version from the $10M version, and the estimate defaults to the larger number.
The estimate is too high because it's built on unknowns, not findings. And unknowns are always expensive.
The pattern
Case 1: A major commercial application needed authorization for deployment to operational users in a DoW environment. The authorization process consumed over $10 million in total effort. The application is authorized and fielded today — but most of that cost was navigating an authorization process that wasn't designed for the application's actual architecture, not remediating the application itself.
Case 2: A specialized analysis tool with strong USG demand was requested for deployment to an authorized environment. The tool was desktop-based — not containerized, not designed for a hardened Kubernetes baseline. The USG was interested. The vendor was willing. The effort died because nobody could quantify the technical lifts, and the USG would not fund an estimate that existed only as "it will be expensive."
Case 3: An Air Force base solicited a FedRAMP-certified replacement for a legacy tracking system. Straightforward requirement — web-based, track inventory per regulatory standards. The effort died when the government realized what a compliant replacement would actually cost.
All three follow the same arc: a real operational need, a willing vendor, and a cost estimate that existed as a vague large number rather than a specific scoped plan.
Why the estimates default to worst case
Authorization estimates are built by people who have seen authorization go badly. They're not wrong to be cautious — they've watched projects consume millions and years. But the caution produces estimates that assume everything is hard:
"The entire application needs to be re-architected." Usually it doesn't. Most commercial applications have a sound architecture — they were just built for a commercial environment. The containers need non-root users and hardened base images. The data layer needs a containerized replacement for managed services the enclave doesn't offer. These are scoped work items, not a rewrite.
"Managed services must be replaced with custom builds." Sometimes, but specifically scoped. No managed PostgreSQL in the enclave? That's a containerized PostgreSQL with a PVC, an init container, and a backup CronJob — a known pattern with a known level of effort. Not an unknown.
"The authorization process itself is unpredictable." It's not, once you know the findings. The unpredictability comes from discovering findings sequentially over months, each one resetting the timeline. If you know all the findings on day one, the authorization process is a sequence of known gates.
What a fit screen actually reveals
I deploy vendor products into a Big Bang instance — the same hardened Kubernetes substrate underlying most DoW program-office platforms — and report what breaks.
A recent deployment of an open-source application produced 10 findings — 7 configuration issues, 1 vulnerability posture blocker (685 CVEs in the upstream image), and 2 FIPS compliance gaps. Before deploying, an architecture review had predicted 27–32 findings. The model was wrong in both directions: it predicted 8–13 days of work that didn't need to happen, and missed 7 runtime findings that only deployment reveals.
The full study eliminated the 685 CVEs entirely (hardened image rebuild to 0 residual), implemented the FIPS code changes, and delivered working Dockerfiles, a CI pipeline, and operational manifests. Remaining effort to deploy on a target platform: 4–6 days.
The math: what a DoW authorization cost estimate looks like
At GSA Schedule rates for cleared DevSecOps engineers (~$175/hr midpoint), the numbers are specific:
The fit screen ($24,500) eliminates $21,000–$28,000 in direct engineering waste — work items that would have been scoped, budgeted, and executed before anyone discovered they were unnecessary. It roughly breaks even on engineering alone. But the real value is calendar time: each of those 7 serial runtime findings, discovered on a target platform instead of a lab, is a 1–3 week submission-rejection-fix cycle. That's 7–21 weeks of project delay.
The full study ($47,500) eliminates ~$148,000 in one-time engineering labor. But the number that matters is recurring: each of those 685 CVEs requires a security impact statement that must be re-validated on every release, on a severity-driven schedule. Over a 5-year ATO lifecycle with monthly releases, that's approximately $956,000 in CVE documentation labor — eliminated permanently by hardening to 0 residual CVEs.
20:1 return. $47,500 against ~$956,000 in avoided lifecycle cost.
What not knowing your ATO cost estimate costs
The fit screen costs $24,500 and takes one week. Set against that:
- A six-month authorization slip on a federal pipeline you've already forecast
- An engineering team spending cycles on enclave-specific problems that are outside their core expertise
- A program office that loses patience and moves to a competitor whose product was already authorized
- A $10M authorization effort that could have been scoped at a fraction of that cost if the findings had been visible from the start
- $330,000/year in recurring CVE documentation labor that could have been eliminated with a base image rebuild
The most expensive estimate is the one that's wrong. The fit screen makes it specific.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. Formerly Division Chief, Space Warfighting Analysis Center (USSF/NRO) and Cybersecurity Chief, AFLCMC.
If a program office wants your software and nobody can tell you what authorization will cost — contact Millabs.