You build a sensor platform. A C2 node. A ground station. An edge device that collects data, processes it, and pushes results to a central system. The hardware works. The software running on it works. The program office wrote the requirements. You won the contract.
Then someone asks: how does this get authorized?
The hardware operates under its own security boundary. The centralized software services — the dashboards, the data ingest, the analytics — deploy to an IT environment that someone else operates. The two connect via an interconnect agreement. And nobody has defined how the total system gets authorized, which framework applies, which authorizing official owns the decision, or what artifacts are required.
This is not an unusual situation. It is the standard situation for hardware systems with embedded software components, and it is where authorization timelines and cost estimates go wrong — not because the technology is hard, but because the authorization pathway hasn't been mapped.
Two boundaries, one hardware system ATO
Most hardware systems with software components end up spanning two security boundaries:
The hardware boundary. The physical system — the sensor, the node, the platform — operates under a security assessment that covers its physical and electronic security characteristics. This is typically the vendor's territory. You know how to build hardware and get it certified.
The IT boundary. The centralized software services that support the hardware — data storage, analytics, user interfaces, integration with other systems — deploy to an IT environment maintained by a government IT operations organization. This environment already has its own authorization. Your software has to fit within it.
The interconnect agreement governs how the two boundaries communicate. It defines what data crosses, how it's protected, and which side is responsible for what. Without it, neither side can complete its authorization.
What vendors don't always know to plan for
If you've built hardware systems before, you know how to get the hardware certified. What may be less familiar is the specific DevSecOps pipeline and platform processes that the software side has to navigate:
Which framework applies. RMF, FedRAMP, CNSSI 1253, DoDI 8510.01 — the answer depends on the impact level, the data classification, and the operational environment. The wrong assumption here wastes months of artifact preparation against the wrong standard.
Which AO owns the decision. The authorizing official for the software side may be different from the one for the hardware. For systems crossing organizational boundaries — say, a Space Force sensor feeding data to a combatant command system — there may be multiple AOs involved, and the sequence in which they're engaged determines the timeline.
What the software components face in the IT environment. If the centralized services deploy to a DoW-hardened platform — Platform One, Game Warden, a program-office Big Bang environment — the containers must pass policy admission, use hardened base images, replace missing managed services, and integrate with the service mesh. These are the same technical challenges any commercial software faces, but hardware vendors often encounter them for the first time because their expertise is in the hardware, not the DevSecOps pipeline.
What the receiving IT organization will absorb. The IT O&M team that operates the target environment didn't plan for your system arriving. They need to know what to maintain, what to monitor, and what the ongoing integration cost looks like. This number is almost never well estimated, and it's the one that causes friction after delivery.
What an embedded software authorization study produces
Millabs' Tier 3 engagement — the Multi-Domain / Systems Authorization Study — covers both sides of this problem:
Software component deployment. The centralized software services are deployed against a hardened Big Bang baseline in a private lab. Every failure surfaces in the first week: policy admission rejections, image findings, missing managed services, service mesh conflicts, egress violations, FIPS compliance gaps. The output is a specific findings report with a remediation roadmap and cost estimates — the same deliverable any commercial software vendor receives.
Authorization pathway for the total system. Which framework applies, which AO, which artifacts are required, what the interconnect agreement between hardware and IT boundaries needs to contain, and the gate sequence. This is presented as a plan the vendor delivers to the program office — not a Millabs opinion, but a specific, actionable authorization strategy.
Integration cost for the IT environment. What the receiving IT organization will need to do, how long it takes, and what it costs. This is the number that prevents the post-delivery surprise where the IT O&M team discovers they're absorbing unplanned work.
The deliverable is a complete authorization plan. The vendor walks into the program office with specific answers to questions the program office may not have known to ask: how the system gets authorized, what the IT O&M organization needs to plan for, and what the realistic timeline and cost look like.
The goal is to empower the vendor to advise the program, not wait for the program to figure it out.
Why this matters now
SBIR and AFWERX-funded companies increasingly build systems with embedded software — AI at the edge, autonomous sensors, distributed C2 nodes. The SBIR process funds the technology development. It does not fund — and often does not plan for — the authorization work required to field the system in an accredited DoW environment.
A Phase II vendor with a working prototype and a program office customer can spend months discovering that nobody has defined the authorization pathway, that the software components face a set of technical challenges they didn't anticipate, and that the IT organization receiving the system wasn't consulted about what they'd need to absorb.
A 5–6 week study at the end of Phase II — or the beginning of Phase III — replaces that discovery process with a specific plan. The vendor knows the authorization pathway, the technical remediation scope, and the integration cost. The program office knows what to fund. The IT organization knows what to plan for.
The cost of not scoping it
Hardware vendors who discover authorization requirements incrementally — one finding at a time, one gate at a time — typically spend 12–18 months and $500K–$2M navigating to authorization. Most of that cost is in the navigation, not the remediation.
The labor driving those numbers is cleared DevSecOps and cybersecurity engineering — the most expensive technical talent in the federal market. GSA Schedule rates (Alliant 3, OASIS+) for mid-senior cleared engineers run $145–$200/hr. On the commercial market, the same profile commands $200–$325/hr, and that assumes you can find one — recruiting a cleared engineer with enclave experience takes 3–6 months, and sponsoring a new clearance takes 9–18 months.
Every month of incremental discovery on a live platform consumes that labor at full rate while the engineering team waits on review cycles they can't accelerate. A 5-person team burning through 6 months of serial discovery at GSA rates costs roughly $840,000 in labor alone — before any remediation work begins.
A systems authorization study costs $82,500 and takes 5–6 weeks. The output is a specific plan with specific numbers. The plan might still show expensive remediation — but it's a number, not a guess, and it's almost always smaller than the assumption it replaces.
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. Working fluency across Platform One, Big Bang, Game Warden, and the approving bodies that authorize systems within them.
If your hardware system has software components that need authorization and nobody has defined the pathway, contact Millabs.