You won a Phase II. The money is obligated, the period of performance is running, and the technology works. That is the hard part of the science, and it is genuinely hard.
It is not the hard part of the transition.
I spent most of my career on the government side of this boundary. As an ISSM and ISSE for legacy weapon systems I stood in front of authorizing officials to defend continued authorizations. As a Division Chief at the Space Warfighting Analysis Center I was on the receiving end when systems arrived and needed to run in an environment authorized to process government information. Now I do the other half of the job: I take commercial products and deploy them into hardened enclaves.
From both sides, the failure mode looks the same. The technology is fine. The transition stalls on work that nobody scoped, nobody budgeted, and nobody was tracking until roughly month fourteen of an eighteen-month period of performance.
This post is for the company that just won, or is about to win, a Phase II, a Direct to Phase II, a STRATFI or TACFI, or a DIU other transaction. Five things are worth knowing now rather than later.
1. Start with your own work plan
Before anything else, go read the statement of work you signed.
Phase II work plans are written by the company, at proposal time, sometimes two years before the work comes due. Security, cybersecurity, and operational readiness tasks get written into them because they are reasonable things to promise and because evaluators like seeing them. Then they sit near the back of the schedule at month fourteen, sixteen, or eighteen, and nobody looks at them again until they are due.
It is worth checking whether yours contains one. If it does, ask four questions:
- What does the deliverable actually say? A task titled "security assessment" can mean a two-page memo or it can mean a compliance posture assessment, a threat model, control alignment against published standards, and a mitigation plan.
- What is the acceptance criterion? If it reads something like "government approval of readiness for deployment," that is not a checkbox. Someone in the government is being asked to sign that your system is ready to field. The document has to be substantive enough to support that signature.
- Who owns it? In most small companies the honest answer is nobody. It was written by whoever assembled the proposal and it has not had an owner since.
- Was it priced? Work plans usually do not itemize cost by task. A security and readiness deliverable in an R&D-heavy contract is a small line in a big number, and small lines are the ones that get absorbed by the engineering they sit next to.
None of this is a problem if you find it in month three. It is a problem if you find it in month sixteen, because by then the remaining period of performance cannot absorb the work.
2. CMMC is about your company, not your product
This is the one that surprises people most, and it has nothing to do with what you built.
If your contract puts controlled unclassified information on your systems, and for most defense R&D awards it does, then the requirement attaches to your company. Your laptops. Your source control. Your cloud services. Your internal network. Your design data. Check whether your contract cites DFARS 252.204-7012, 7019, 7020, or 7021, and check what CMMC level it names.
CMMC Level 2 is NIST SP 800-171, which is 110 controls. That is not a policy document exercise. It is an infrastructure and operations posture that has to exist, be maintained, and be evidenced.
Here is the part worth hearing from a small business rather than from a compliance vendor: Millabs looked at CMMC for its own systems and found the cost hard to justify at our size. Standing up compliant infrastructure ran on the order of a hundred thousand dollars in hosts, servers, and supporting infrastructure before any ongoing maintenance, monitoring, or assessment cost. For a company living on a Phase II award, that is a meaningful share of the money going to compliance infrastructure instead of to research.
The realistic paths for a company your size are usually not "build it in house." They are managed compliant enclave providers and compliant virtual desktop services, where you rent the compliant environment and keep your covered data inside it rather than trying to bring your entire corporate network into scope. That is a scoping decision, and it is much cheaper to make deliberately in month two than to discover in month fifteen.
One boundary, stated plainly: Millabs is not a C3PAO and does not perform CMMC certification assessments. What we do is readiness work, which means telling you what applies to you, what it will cost, and what your realistic options are. The certification itself belongs to an accredited assessor.
3. "Controlled Unclassified" does not mean "commercial with extra paperwork"
If your product touches government data of almost any kind, procurement, logistics, technical specifications, maintenance records, operational planning, it is very likely handling CUI.
The words sound mild. The consequence is not. In defense environments, CUI generally means Impact Level 4 at minimum, and the authorization burden at IL-4 looks a great deal more like the classified side than like the commercial cloud you are running in today. Your FedRAMP status, if you have one, does not carry you across that line by itself.
The gap here is cultural before it is technical. Commercial software is built in environments with a risk tolerance the government does not share. "Ship it and patch later" is a rational commercial posture. It is not an available posture inside an authorized environment, where every container image passes a policy admission gate on the way in, base images have to come from approved sources, and the security posture is not negotiable at the point of deployment.
4. Your product will not deploy as it is
I say this with some confidence because I have not yet seen one that did, and because the ones that break are usually well-built.
We run a private Big Bang instance as a lab. It is our own environment, not a government-authorized system, and that is exactly the point: it lets a product fail in a place where failing is free. Here is why we built it.
What that lab keeps finding:
Vulnerability gates. A recent well-built open source application arrived with 685 CVEs in its container images, 28 critical and 96 high. Almost none of that came from application code. It came from the Debian base image and the language runtime. Those images would not pass a production vulnerability gate in any authorized environment. Rebuilding on hardened base images eliminated all 685, but that rebuild is two to four weeks of engineering that nobody had scoped.
Missing managed services. Commercial products assume managed PostgreSQL, managed Redis, object storage, managed SMTP, and an external identity provider. A hardened enclave is a Kubernetes compute substrate with policy enforcement. It is not a cloud provider and it usually offers none of those. Every missing service becomes something somebody has to build, harden, and operate, at roughly three to seven days of specialized engineering each.
Runtime failures you cannot read off a diagram. On that same application, an architecture model predicted 27 to 32 findings. The deployment produced 10 real ones, and seven of them were runtime failures invisible from the Dockerfile, the Helm chart, or the architecture drawings. Service mesh behavior, policy admission, and egress restrictions do not show up in code review. They show up when the pod starts.
Notice which direction the model was wrong in. It was wrong in both. It planned for work that was not needed and missed failures that were. That is the general case for authorization estimates built without deployment data: they default to the worst case because unknowns are priced as risk, and the real number is almost always smaller and differently shaped than the assumption it replaces.
It can be done. A commercial product went from a Docker image to IL-4 and TOP SECRET on a timeline that held. It held because the deployment engineering was found early and scoped, not because it was avoided.
5. If you build hardware, you have three security problems, not one
A large share of defense SBIR and STTR awards go to hardware: sensors, spacecraft components, accelerators, RF, robotics, optics. Hardware companies get scoped into security work that is not theirs, and it costs them money and schedule.
There are three distinct domains, and conflating them is the expensive mistake.
Your corporate systems. Your design data, your source, your tooling. This is the CMMC problem from section 2, and it is unambiguously yours.
The design artifact itself. RTL, firmware, a board design, an IP core. It is not a system and it does not independently get assessed against security controls. What matters here is provenance and supply chain integrity: where it was designed, who had access, what export control applies, what went into it.
The end system that uses your hardware. The tactical terminal, the sensor pod, the spacecraft bus. This is where security technical implementation guides, control baselines, and the authorization actually apply. It belongs to the program office, the integrator, and in silicon terms to whoever fabricates the part. Not to you.
Your software deliverables, drivers, APIs, configuration tools, simulation environments, sit in a fourth place: they are yours, and they get evaluated in the context of the end system.
The reason this matters commercially is that a task written broadly enough to cover memory integrity, secure boot, firmware trust, and secure register handling can read like a promise to assess silicon security on a target platform that does not exist yet. Structure the deliverable so it covers what you actually own, and identify the rest as requiring the platform or foundry, once a target is selected. Government customers generally prefer that answer. It gives them a cleaner picture than a report that quietly papers over the boundary. And if your award is for a hardware system, it is worth being clear with yourself early that the software inside it needs its own authorization path.
6. The clock is the actual risk
Everything above is manageable work. The reason it kills transitions is timing.
Authorization work is discovered late by default, because nothing forces it to surface early. You are heads-down on the technical milestones the contract is really about. Your government technical point of contact is tracking those same milestones. The receiving IT organization that will eventually have to operate your product is not in the conversation yet. Nobody is doing anything wrong. The cost simply falls in the gap between three organizations that each own a different part of the problem.
Finding a deployment problem in month four is a scoping conversation. Finding the same problem in month fourteen is a schedule failure, because the remaining period of performance cannot absorb six to ten weeks of engineering plus a rebuild plus a compliance posture you do not have yet.
7. What you get for solving it
The reason this is worth real attention rather than a late memo is what sits on the other side.
Phase III is a genuinely unusual instrument. Under 15 U.S.C. 638(r)(4), a Phase III award is exempt from competition requirements because Phase I and Phase II already satisfied them. There is no limit on the number of awards, the duration, the contract type, or the dollar value, no time limit by which Phase III must follow Phase II, and no requirement for a sole source justification under FAR Part 6 or for publicizing under FAR Part 5.
That is why so much of this market is invisible. Large single-award vehicles held by defense software companies are Phase III instruments, which is precisely why they never appear in solicitation data. They did not have to be advertised.
Reauthorization was signed into law in April 2026, after a six-month lapse, and runs through 30 September 2031. The current authorization includes training for the acquisition workforce specifically on Phase III agreements, data rights, and sole source awards. Contracting officers are being taught to use this path.
None of that helps you if your product cannot be fielded. Phase III is a transition mechanism, and transition means the thing runs, in their environment, under their rules. The companies that get there are the ones for whom deployment was an engineering problem solved in year one, not a discovery made in the last quarter of the period of performance.
What to do in the next thirty days
- Read your work plan. Find the security, cybersecurity, or operational readiness task if there is one. Note the due date, the deliverable definition, and the acceptance criterion.
- Find the DFARS clauses in your contract. Determine whether CUI applies to you and at what CMMC level, and decide early whether you are building a compliant environment or renting one.
- Ask your government technical point of contact where this is going to run. Which platform, which impact level, which receiving IT organization. That single question determines most of the technical answers.
- Inventory your external dependencies. Every database, cache, object store, queue, identity provider, and outbound service your product needs. Then find out which of those the target environment provides. The gap is your build list.
- Scan your container images and record the count at critical and high severity, along with the base image each one came from. If you have never run this, the number will be larger than you expect and it will mostly not be your fault.
- Deploy against a hardened baseline once, deliberately. Either in your own lab or someone else's. What you want out of it is a findings register: specific failures, with logs and reproduction steps, and a remediation estimate. That register is what turns a guess into a number you can defend to a program office.
That last one is the whole argument in miniature. The difference between a company that transitions and one that does not is rarely the technology. It is usually whether the deployment problems were found while there was still time and money to fix them.
If you want the short version
You have a period of performance, a technology that works, and a set of authorization problems that are entirely solvable and entirely invisible from where you are standing. The cheapest month to look at them is this one.
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 authorizations, 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.
Millabs runs a private Big Bang lab, which is our own system and not a government-authorized environment, specifically so that products can fail there instead of in front of a program office. If you want to know what your product does against a hardened baseline before your government customer finds out, here is what an enclave fit study delivers, or write to rbu@millabs.net.
Millabs is not a C3PAO and does not perform CMMC certification assessments. CMMC work is readiness only.