Your program office manages a radar. Or a sensor platform. Or a ground station, an EW system, a C2 node, or any hardware system that collects data, processes it, and pushes results somewhere. The hardware passed its developmental and operational tests. The contract delivered on spec.
Then somebody needs to connect it to the network.
The radar's software services — the display interface, the data ingest pipeline, the alerting logic, the analytics dashboard — need to deploy to an IT environment that is already accredited, already operated by an IT organization, and already running on a hardened baseline your vendor has never seen. The radar hardware operates under one security boundary. The software services operate under another. The two connect via an interconnect agreement that nobody has drafted because nobody realized there were two boundaries until the program tried to go operational.
This isn't unusual, and it isn't a planning failure. In hardware acquisition, the software is naturally assumed to be the simpler part of the system — and in the vendor's development environment, it is. The complexity appears when that software has to operate inside an accredited IT environment with its own security baseline, its own authorization framework, and its own operational requirements.
The gap between "it works" and "it's authorized"
Your vendor builds radars. They are very good at building radars. Their software team writes code that processes radar data and presents it to operators. That software runs on the vendor's infrastructure during development and testing, where it works perfectly.
When that software needs to run inside your accredited IT environment, three things change simultaneously:
The infrastructure disappears. The vendor's development environment has managed databases, managed caches, load balancers, external identity providers, and unrestricted egress. Your accredited IT environment has a hardened Kubernetes substrate with Istio service mesh, Kyverno policy enforcement, and no managed services. Every infrastructure dependency the software assumes must be replaced with something that runs inside the enclave.
The security posture is enforced, not documented. In commercial development, security controls are a compliance exercise — you document them and an assessor validates the documentation. In a hardened DoW enclave, security controls are enforced by the platform. Containers that run as root won't start. Images with critical CVEs won't pass the vulnerability gate. Outbound network calls to license servers will be silently dropped. The platform doesn't care what the vendor intended — it enforces what the baseline requires.
The authorization pathway multiplies. The hardware has its own security assessment. The software services have a separate authorization under RMF. The connection between the hardware boundary and the IT boundary requires an interconnect agreement. If the software services process data from multiple classification levels or multiple programs, data governance requirements add another layer. Each of these has a different authorizing official, different artifacts, and a different timeline — and they must align before the system goes operational.
The vendor knows how to build the hardware and write the software — that's what they were hired to do, and they're good at it. Navigating the hardened IT platform, the authorization framework, and the interconnect agreement is a different discipline, and it's reasonable that a hardware vendor hasn't needed it before.
What typically surfaces late
The software is a separate authorization
One of the most common discoveries late in a hardware program: the software services are not covered by the hardware system's security assessment. The hardware assessment addresses the physical platform, its electronic security characteristics, and its communications interfaces. The software services that deploy to a separate IT environment require their own ATO under the IT environment's authorization framework. These are two different assessments, two different AOs, and two different sets of artifacts.
If the program assumed "the system gets one ATO," the discovery that it needs two — plus an interconnect agreement — adds 6-12 months and a significant authorization engineering effort that wasn't in the original plan. This isn't an oversight — it's a distinction that doesn't surface until the system reaches the network boundary.
The receiving IT environment has its own requirements
The IT organization operating the accredited platform where the software will deploy has requirements the vendor hasn't encountered: hardened base images, container policy compliance, vulnerability gates, service mesh compatibility, image signing and attestation, and an operational patching cadence.
A well-built commercial application with full Docker and Kubernetes support recently produced 10 deployment findings when deployed against a hardened baseline for the first time — including secrets silently absent at runtime, services listening on undocumented ports, and 685 CVEs in the container images driven by the base image, not application code. These are standard findings for any commercial software arriving at a hardened platform. Your vendor's radar software will hit the same categories.
The IT organization absorbs the integration cost for operating the vendor's software after delivery — container patching, database operations, monitoring, storage — and that cost is almost never scoped before the system arrives.
The deployment estimate is based on a different problem
When a radar vendor estimates "software deployment cost," they're drawing on their experience deploying software — which is deploying to their own infrastructure, not to a hardened DoW enclave. The estimate isn't wrong for the problem they know. It's wrong for the problem they'll actually face, because the two environments impose fundamentally different constraints.
Hardware vendors navigating authorization incrementally — discovering failures one at a time through the platform's review pipeline — typically spend 12-18 months and $500K-$2M in authorization engineering. Most of that cost is delay: a team of cleared engineers waiting for review cycles to complete, discovering the next failure, fixing it, and resubmitting. At cleared labor rates ($175/hr GSA Schedule, $200-$325/hr commercial market), a 5-person team over 6 months of serial discovery costs approximately $840,000 in labor alone.
The actual technical remediation — the container hardening, the managed service replacements, the service mesh fixes, the authorization artifacts — is typically 4-10 weeks of focused engineering. The difference between $840,000 and the actual remediation cost is the cost of not knowing what the findings are before starting.
What helps
Require the vendor to demonstrate software deployment readiness separately from hardware delivery. The hardware passing its tests doesn't tell you anything about whether the software services will deploy to the accredited IT environment. Require the vendor to deploy their software against a hardened baseline and produce a findings register — the same way you require hardware testing before accepting delivery.
Scope the authorization pathway before contract award. Which framework applies to the software services? Which AO? What does the interconnect agreement between the hardware boundary and the IT boundary look like? If these questions don't have answers before the contract is awarded, the authorization timeline in the vendor's proposal is a guess.
Involve the receiving IT organization early. The IT team that will operate the vendor's software services needs to be in the conversation during requirements — not after delivery. They can tell you what the integration cost looks like, what the platform requires, and whether the vendor's software architecture is compatible with the target environment.
Budget the authorization engineering separately. The authorization work for the software services is a different discipline from the hardware development — it requires DevSecOps, RMF, and platform-specific deployment engineering. Scoping it as a distinct work item, rather than bundling it into the hardware contract, makes the cost visible and ensures the right skills are applied to it.
The radar works. The software doesn't deploy.
The pattern is consistent. A hardware program delivers a capable system. The software services that make the system operational need to deploy to an accredited IT environment. The deployment engineering, the authorization pathway, and the IT integration cost weren't scoped in advance — not because anyone dropped the ball, but because these costs live at the intersection of hardware acquisition, software deployment, and IT operations, where no single organization has complete visibility.
The gap is predictable, finite, and cheaper to scope before it becomes a schedule problem. A systems authorization study that maps both boundaries — hardware and IT — before the vendor starts building tells you exactly what the authorization looks like, what the IT environment requires, and what the realistic timeline and cost are. The vendor walks into the program office with specific answers instead of assumptions.
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 — including standing before the authorizing official to defend continued ATOs for systems that had outgrown their authorization posture — and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO). He understands what a hardware program office faces when the system needs to connect to the network and nobody has mapped the path.
If your program manages a hardware system whose software needs to deploy to an accredited IT environment and nobody has mapped the authorization pathway, contact Millabs.
Millabs performs independent authorization pathway assessments on behalf of program offices — mapping both boundaries, scoping the IT integration, and producing a plan the program can act on — through existing government contract vehicles. rbu@millabs.net.