Your vendor has a working product. It runs in commercial cloud. The demo looked great. Their proposal says they can deploy to your accredited environment in 90 days.
How do you know if that's true?
In my experience on both sides of this boundary — as a Division Chief at the Space Warfighting Analysis Center receiving systems into accredited environments, and now as someone who deploys commercial products into hardened enclaves — the honest answer is usually that nobody knows yet. The vendor believes it because their product works in Docker. The program believes it because the vendor's proposal says so. And the gap between "runs in commercial cloud" and "runs inside your hardened enclave" doesn't become visible until month four, when the deployment starts failing and the schedule starts slipping.
This isn't anyone's fault. The vendor hasn't deployed against the baseline because there's no common practice requiring it. The program hasn't asked because the questions aren't obvious until you've been through it.
These are the five questions I wish someone had handed me when I was on the government side evaluating vendors.
Question 1: Have you deployed your product against an actual hardened baseline?
Not "do you have Docker support." Not "are you Kubernetes-native." Not "do you have a FedRAMP authorization."
Have you taken your containers, deployed them into an environment running Istio service mesh, Kyverno policy enforcement, and hardened base images — the same substrate your accredited platform runs on — and observed what happens?
If the answer is no, every timeline in their proposal is a guess. A well-built open-source application with full Docker and Kubernetes support recently produced 10 deployment findings when deployed against a hardened baseline for the first time. Seven of those findings were runtime failures invisible from reading the Dockerfile, the Helm chart, or the architecture diagrams. The vendor's deployment estimate was based on 27-32 predicted findings. The model was wrong in both directions — it planned for work that wasn't needed and missed failures that were.
What a good answer sounds like: "Yes, we deployed against [specific platform or lab], and here is the findings register." A document listing specific failures with logs and reproduction steps means they've done the work. An architecture diagram and a schedule means the work is still ahead — and the timeline should reflect that.
Question 2: What is the vulnerability posture of your container images?
Every accredited platform has a vulnerability gate. Critical CVEs typically block production admission outright. Your vendor's container images were built on a base image — Debian, Ubuntu, Alpine, or a language-specific runtime — and that base carries vulnerabilities the vendor didn't introduce but is responsible for.
The application referenced above carried 685 CVEs in its container images — 28 critical, 96 high — driven entirely by the Debian base and Ruby toolchain, not by application code. The application itself was well-built. The images would not pass any production vulnerability gate in any accredited environment.
Rebuilding on hardened base images (Chainguard wolfi, in this case) eliminated all 685 CVEs. But if nobody asks the question before contract award, the rebuild becomes an unplanned engineering project — typically 2-4 weeks — that the vendor didn't scope and your timeline didn't account for.
What to ask: "What base images do your containers use, what is the current CVE count at critical and high severity, and what is your plan to meet the vulnerability gate on [target platform]?" Many vendors haven't run this scan yet — that's normal for commercial software. The point of asking is to surface the work before it becomes a schedule item.
Question 3: Which managed services does your product require that the enclave doesn't provide?
Commercial applications assume managed PostgreSQL, managed Redis, S3-compatible object storage, managed SMTP, and external identity providers. Most accredited enclaves provide none of these. The enclave is a Kubernetes compute substrate with policy enforcement — not a cloud provider.
When a vendor's product requires managed PostgreSQL and the enclave offers bare Kubernetes, someone has to build, harden, and operate a containerized database replacement. That's 3-7 days of specialized engineering per missing service, at cleared labor rates of $175/hr (GSA Schedule) to $325/hr (commercial market). If nobody identifies the missing services before contract award, the cost appears as an unplanned change order — or worse, as a silent schedule slip while the vendor figures it out.
What to ask: "List every external service your application depends on — database, cache, object storage, message queue, identity provider, SMTP, external APIs — and confirm which of those exist on [target platform]." Most commercial vendors haven't had a reason to evaluate this — their product was built for environments that provide these services. The question helps both sides scope the gap early.
Question 4: Who absorbs the integration cost on the IT side?
This is the question nobody asks until it's too late. Your program office accepts delivery of the vendor's system. The system deploys to an accredited platform operated by an IT organization. That IT organization now absorbs the integration and ongoing operational cost — container image maintenance, database operations, service mesh configuration, monitoring, storage provisioning, and patching.
This cost is easy to miss because it's not in anyone's natural field of view. The vendor scopes delivery. The program office scopes capability. The IT organization often doesn't enter the conversation until they receive a deployment request. Nobody is at fault — the cost falls in the gap between three organizations that each own a different part of the problem.
Before contract award, one question surfaces it: "Has the receiving IT organization been consulted on integration requirements, and has the integration cost been included in the deployment estimate?" That question connects the three organizations early enough to plan.
At cleared IT operations rates ($145-$200/hr GSA, $200-$325/hr commercial), unscoped integration work adds up quickly. A deployment that arrives without integration planning routinely costs the IT organization $50,000-$150,000 in unplanned labor — not because anyone failed, but because the cost wasn't visible until the system arrived.
Question 5: What happens if the product doesn't pass the authorization gate?
This is the risk question. Your vendor's deployment attempt fails. The product can't pass the vulnerability gate, or it breaks under the service mesh, or it requires managed services the enclave doesn't offer. What happens next?
If the answer is "the vendor remediates and resubmits," the follow-up is: what does that remediation cost, and who pays for it? If the vendor priced their proposal assuming a clean deployment, the remediation is unfunded work. If the contract doesn't include remediation scope, the vendor has no obligation to perform it. If the period of performance can't absorb the delay, the product doesn't get fielded — not because it doesn't work, but because nobody scoped the deployment engineering.
The alternative: require the vendor to demonstrate deployment readiness before contract award. A one-week deployment test against a hardened baseline — the vendor's cost, not yours — produces a specific findings register that tells you exactly what will break, how long the remediation takes, and what it costs. That register turns your go/no-go decision from a guess into an informed judgment.
The pattern
Every one of these questions has the same structure: it surfaces a cost that is real, predictable, and cheaper to discover before contract award than after.
Authorization cost estimates built without empirical data default to the worst case. The vendor either underestimates because they haven't deployed against the baseline, or overestimates because they're padding for unknowns. Either way, the budget decision is based on a number that's hard to defend.
A deployment test replaces the guess with findings. The remediation number is almost always smaller than the assumption it replaces — because most of the cost in a traditional estimate comes from unknowns, not from actual technical work. Requiring your vendor to demonstrate deployment readiness before contract award — at the vendor's expense, not yours — turns a guess into a defensible number.
What this is not
This is not a recommendation to add gates, slow acquisition, or make vendors jump through hoops. It is a recommendation to ask five questions that surface predictable costs before they become surprises.
If your vendor can answer all five with specifics — a findings register, a CVE count, a missing-services inventory, an IT integration estimate, and a remediation plan — your deployment risk is well understood. If the answers aren't available yet, that's useful information too — it tells you where the unknowns are and what to scope next.
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 — standing before authorizing officials to defend continued ATOs — and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO). He now deploys commercial products into the same hardened environments he once operated.
If your vendor can't answer these questions and you'd like to understand what a deployment test looks like, contact Millabs.
Millabs also performs independent deployment assessments on behalf of program offices — separate from the vendor relationship — through existing government contract vehicles. If your program needs an independent evaluation of a vendor's readiness before committing budget, the conversation starts the same way: rbu@millabs.net.