In the fall of 2025, a commercial ASP.NET web application with an MSSQL backend was deployed to IL-4 and TOP SECRET environments via Second Front's Game Warden platform. The application is now operational on JWICS, supporting US Space Force operational and intelligence missions.
This is what the journey looked like — not as an architecture document, but as a sequence of engineering problems that had to be solved to get from "it runs in Docker" to "it's fielded and authorized at TS."
The starting point: a commercial application before IL-4
The vendor had a working commercial application. It was containerized, running in Docker, deployed to commercial cloud infrastructure. The product worked. The team was capable. USG customer demand existed at both the CONTROLLED and TOP SECRET levels.
What the vendor didn't have was visibility into how many findings the deployment to a hardened DoW environment would produce, how long remediation would take, or what it would cost. The gap wasn't the product and it wasn't the team's capability. The gap was information.
What broke
When the application hit the hardened baseline — Istio service mesh, Kyverno policy enforcement, hardened image requirements — the failures were immediate and specific.
Container images. The application's Docker images were built on standard Debian bases with standard runtimes. Those base images carried vulnerability counts no authorizing official would accept. Every image needed to be rebuilt on a hardened base, and for some runtimes, that meant authoring OCI build scripts from scratch and sourcing base images specifically selected to drive down final-image vulnerability counts. The goal was not just a working image — it was an image that an AO would sign.
The database. The application's data layer was built for managed MSSQL — the kind of hosted database service you get in commercial cloud. The target enclave offered no managed SQL service. Not a limited one. None.
This is where most projects stall. Replacing a managed database with a containerized one inside a hardened Kubernetes environment is a known pattern, but it requires specific engineering: a hardened database image, persistent storage via PVC, an init container for schema creation and migration, backup automation, and mTLS-aware connection configuration.
Millabs built a purpose-made MSSQL container that handled initialization, migration, and steady-state operation. The application's data layer was preserved. No product rewrite was required.
Policy admission. The standard Kyverno failures — containers running as root, missing securityContext, writable root filesystem, no resource limits. Each one a straightforward fix, but each one invisible until you deploy against the actual baseline.
Service mesh. Inter-service communications that worked without Istio broke with it. Health checks, sidecar startup ordering, TLS termination conflicts. Diagnosable and fixable, but only once you've seen the specific error in the actual mesh configuration.
How the Game Warden deployment was done
Millabs worked inside the vendor's engineering team, not adjacent to it. Changes landed in their repo, on their pipeline. The intent was not to build a parallel engineering effort but to transfer the enclave-specific knowledge the vendor's team needed to own the product going forward.
Container build engineering — authoring OCI build scripts, selecting hardened base images, iterating on vulnerability posture until the image scans met the AO's threshold.
Database container construction — the purpose-made MSSQL container was the single hardest technical lift. It had to handle first-run initialization, schema migration from any prior version, and normal steady-state operation, all in a hardened image running as non-root with a read-only root filesystem.
Authorization artifact package — the technical documentation required for Certificate-to-Field / ATO, written in the format and level of detail the reviewing authority expects. SSP, CMP, IRP, contingency and disaster recovery plans, DIRA, hardware and software listings, control implementation narratives.
The outcome
Successful deployment to IL-4 and TOP SECRET environments in the fall of 2025. The product is operational on JWICS. The vendor is positioned to sell against classified requirements.
Published coverage: Second Front Systems Powers Millabs Deployment to Top Secret Environment | Second Front Speeds Millabs Tools Into JWICS, Cutting Years Off Deployment
What happened next
With the platform successfully deployed at IL-4 and TS, the next challenge was larger: the vendor needed the product to exist as a cloud service offering — not as software a customer installs, but as a service running across security domains inside government-accredited infrastructure.
That is a different engineering and accreditation problem. It touches every part of the architecture at once:
Cloud service provider integration — aligning the offering with established USG enterprise cloud providers so it rides accredited infrastructure rather than requiring its own accreditation from zero.
Multi-level service architecture — spanning commercial through classified domains, including compartmented and special-access environments (NIPR, SIPR, JWICS, SEC).
Metadata strategy — governing how information is labeled and moved across domains. This is the substrate every cross-domain authorization decision rests on.
Security incident management — meeting government operational reporting expectations, not just commercial SLA practice.
Approving authority navigation — FedRAMP, DoW CIO/CSO, DISA, SAF CIO, SSC. Knowing which door to knock on, in what order, is most of the schedule.
The product is now positioned as a cloud service supporting US Space Force combatant command and intelligence missions, with an authorization pathway and multi-domain architecture the government side could approve.
What vendors should take from this
Three things:
The gap is predictable. Every commercial application I've deployed or analyzed hits the same failure classes: policy admission, image provenance, missing managed services, service mesh conflicts, egress violations. The specific findings vary by application, but the categories are consistent. They are engineering problems with engineering solutions.
The gap is cheaper to find early. This engagement happened before the Millabs Big Bang lab existed in its current form. The failures were discovered against Game Warden's actual admission pipeline, sequentially, over weeks. Each serial rejection cycle consumed cleared engineering labor at GSA rates ($145–$200/hr) or commercial cleared rates ($200–$325/hr) — and a multi-week wait between cycles doesn't stop the clock on engineering salaries. Today, those same findings would be cataloged in a single deployment attempt in a private lab — week one, before anyone submits anything to a live platform.
The product doesn't have to change. The application's architecture was preserved. The data layer was preserved. No product rewrite was required. What changed was the container images, the deployment configuration, and the infrastructure services surrounding the application. The vendor's product is the same product — it just runs in a hardened environment now.
If your product works in commercial cloud and a government customer wants it in an authorized environment, the question is not whether it will need engineering work. It will. The question is whether you discover that work in a week or across a year.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He deployed the commercial application described in this post to IL-4 and TOP SECRET via Game Warden, and is currently supporting its positioning as a multi-domain cloud service for US Space Force missions.
If your product needs to make the same journey, contact Millabs for a free diagnostic call.