A program office issues an RFQ for a software system. The requirement includes deployment to an authorized environment — FedRAMP, IL-4, or a program-specific accredited platform. Three vendors respond. The cheapest bid wins.
Six months later, the project is dead. Not because the software doesn't work — it works fine in commercial cloud. The project died because the authorization and deployment engineering cost was larger than anyone expected, and the cheapest bid didn't include it.
This pattern repeats across the Department. I've watched it happen from the government side as Division Chief at the Space Warfighting Analysis Center, and I've watched it from the vendor side deploying commercial products into hardened enclaves. The mechanism is the same every time: the bid prices the software, not the deployment. The deployment cost surfaces later. And by then, the options are all bad.
How the cost hides
A vendor responding to an RFQ prices what they know: software licenses, configuration, customization, training, and support. If the RFQ requires FedRAMP certification or deployment to an authorized environment, the vendor estimates that cost too — but the estimate is built on assumptions, not findings, because nobody has deployed the product against the actual baseline to see what breaks.
The assumptions are always optimistic. The vendor assumes their containers will pass the vulnerability gate (they usually carry hundreds of CVEs in the base images). They assume the enclave provides managed services their product depends on (it usually doesn't). They assume their architecture will work under the service mesh (it usually conflicts with Istio in specific, predictable ways). They assume the authorization timeline is 90 days (it's typically 6-12 months for a first deployment).
The cheapest bid reflects the most optimistic assumptions. A vendor who prices authorization at $50K instead of $250K isn't being dishonest — they genuinely don't know what they'll hit. There's no common practice requiring vendors to deploy against the actual baseline before bidding, so estimates are built on experience with commercial environments that work very differently.
Three ways this kills projects
The vendor discovers the real cost and asks for more money
This is the most common failure mode. The vendor deploys against the baseline, discovers 10-30 findings, realizes the remediation is a six-month engineering effort, and submits a change order. The program office now faces a choice: pay significantly more than the awarded contract value, or start over.
Starting over means a new RFQ, a new evaluation, a new award, and 6-12 months of schedule slip — with no guarantee the next vendor won't face the same gap. Accepting the change order funds work that should have been in the original estimate but couldn't have been, because the information wasn't available at bid time.
Neither option is good. Both are expensive. And both stem from the same root cause: the deployment cost wasn't knowable from the information available during the bid.
The vendor absorbs the cost and cuts corners
The vendor discovers the deployment is harder than expected. They're locked into a fixed-price contract. The rational response is to minimize the authorization effort — skip the hardened base image rebuild, submit with known vulnerabilities and hope for a POA&M, defer the managed service replacement, submit incomplete authorization artifacts. Each shortcut creates a finding at the authorization gate. Each finding creates a review cycle. Each review cycle burns 2-4 weeks.
The product eventually gets rejected or arrives with so many POA&Ms that the AO questions whether it's operationally viable. The program office has a product that technically passed but practically can't be trusted, and the vendor has burned through their margin.
The project dies on cost shock
This is the quietest failure mode. An Air Force base issued an RFQ for a web-based replacement for a legacy backflow prevention tracking system — the kind of system an AO is actively pushing to get off the network. The requirement specified FedRAMP certification. The team with the requirement knew they needed a replacement. What they didn't know was the scope of what "FedRAMP-certified replacement" actually costs to build and authorize. When that number became clear, the project was terminated. The legacy system — the one the AO wanted gone — kept running because nobody could scope an affordable path to replacing it.
I've seen the same pattern with a major commercial application that consumed over $10M in authorization effort — most of it navigating a process misaligned with the product's architecture — and a specialized analysis tool whose deployment died entirely because nobody could quantify the technical lifts. In every case, the requirement was real, the urgency was real, and the products worked. The authorization cost is what killed them — not because the teams lacked commitment, but because nobody could distinguish the real cost from the worst-case estimate.
The worst part: the actual remediation cost in these cases was almost certainly smaller than the number that killed the conversation. Authorization cost estimates built without empirical data default to the worst case. A $10M estimate might contain $2M of real work and $8M of unknowns priced at maximum risk. But nobody can tell the difference without deploying the product against the baseline to see what actually breaks.
What the program office can do differently
Require deployment evidence in the bid
Instead of asking vendors to estimate authorization cost, require them to demonstrate deployment readiness. A vendor who has deployed their product against a hardened baseline and can submit a findings register with their proposal is giving you a defensible cost number. A vendor who can only estimate is guessing.
This doesn't disadvantage smaller vendors. A one-week deployment test is a fraction of the proposal development cost for a significant contract, and it gives the vendor a defensible number to bid with — which protects them as much as it protects the program.
Evaluate authorization cost separately from software cost
When authorization cost is bundled into the total bid, it's invisible. The evaluator sees a total price and can't distinguish between "cheap software with expensive authorization" and "expensive software with cheap authorization." Requiring vendors to break out the authorization and deployment engineering cost as a separate line item makes the risk visible.
A vendor whose software costs $500K but whose authorization cost is $50K is a different proposition than a vendor whose software costs $300K but whose authorization cost is $250K. The second bid looks cheaper at the total. It isn't.
Price the IT integration cost before award
The system will deploy to an accredited environment operated by an IT organization. That organization will absorb integration and operations costs that are not in the vendor's bid — because they're not the vendor's responsibility. But they are real costs that the Department pays.
Requiring the vendor to estimate the IT integration burden — or better, requiring the receiving IT organization to validate the vendor's estimate — surfaces these costs before the award decision. A vendor whose product requires 15 days of IT integration at cleared labor rates is more expensive than their bid shows, and the program office should see that number before committing.
The math
A vendor who demonstrates deployment readiness before contract award gives you:
- A specific findings register (not an estimate)
- A CVE count and hardened image strategy (not an assumption)
- A missing-services inventory with replacement costs (not a hope)
- An IT integration cost estimate (not silence)
- A realistic authorization timeline (not 90 days)
A contract awarded without this information produces a $250K-$2M cost discovery in month 4-6, when the vendor deploys for the first time and discovers what everyone would have known in week one.
The cheapest bid is the one that includes the cost of the deployment engineering. Every other bid is missing the cost — not intentionally, but because the information needed to estimate it wasn't available at bid time.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems, Cybersecurity Chief at the Air Force Lifecycle Management Center, and Division Chief at the Space Warfighting Analysis Center (USSF/NRO). He has seen authorization cost kill projects from every seat at the table — and knows the number is almost always smaller than the estimate that stops the conversation.
If your program is evaluating vendor bids that include authorization work and nobody has validated the deployment cost, contact Millabs.
Millabs performs independent deployment and authorization assessments on behalf of program offices — separate from the vendor relationship — through existing government contract vehicles. If your program needs to validate a vendor's deployment estimate, scope the authorization pathway, or evaluate readiness before award, rbu@millabs.net.