Ask the people running an expensive classified estate why they have not modernized it, and you will usually get a version of this: we know. We do not have time.
That answer is normally treated as an excuse. It is not. It is the most accurate description of the problem anyone in the building will give you, and it is worth taking literally.
The trap, stated plainly
An authorization team supporting independent boundaries is close to fully committed by construction. Annual assessments, continuous monitoring, plan-of-action tracking, and the assessment work for each boundary do not pause. They recur, they overlap, and they land on the same small pool of cleared people.
Now propose an architecture change.
Every significant change to an authorized system triggers a security impact assessment. That is not bureaucracy, it is the framework working as designed: you changed the thing the authorizing official accepted, so the change has to be evaluated against the accepted risk posture before it goes in.
The assessment is performed by the same team that is already committed. So the improvement intended to free their capacity consumes their capacity first, in advance, with no guarantee the change survives review.
This is a genuine trap and it is stable. A team in it will decline modernization proposals indefinitely, correctly, on grounds that have nothing to do with whether the proposal is good.
Why the slack is smaller than the arithmetic suggests
Take whatever spare capacity you think the team has, then apply two corrections.
Fragmentation. Authorization capacity does not pool. Three separate two-week gaps across three boundaries are not six weeks of project time. They are three two-week gaps, and no meaningful assessment work fits in one. Usable slack is always a fraction of nominal slack, and the more boundaries there are, the smaller the fraction.
Coverage. Count the months in a three-year cycle during which some live assessment is running somewhere in the estate. In a multi-boundary environment that number is high enough that "between assessments" is not a real state the organization is ever in.
The practical result is that a team that looks like it has a person's worth of spare capacity has considerably less than that in a form anyone can use for a project.
What it costs downstream
The same constraint shows up in places nobody attributes to it.
Patch latency is the clearest one. When you measure the chain from vendor release to deployed change in an environment like this, the approval step is routinely the largest single contributor. Longer than testing. Longer than the transfer. Longer than the deployment itself. The queue is not slow because the reviewers are slow. It is slow because they are at capacity on recurring work that cannot be deferred.
This matters because patch latency is usually diagnosed as a tooling problem, and tooling is then bought to fix it. The tooling arrives, the queue does not move, and the organization concludes that nothing helps.
Time from capability request to fielded capability has the same shape and the same cause.
The only two ways out
Reduce the number of things that need independent assessment. This is the structural fix and it is the subject of the last post in this series. Fewer boundaries, and one platform definition assessed once rather than several assessed separately.
Change what counts as a significant change. A large share of security impact assessments are written by hand, from scratch, for changes that are routine and repetitive. Where the platform is defined as code and the evidence is produced by the pipeline, many of those changes can be pre-approved as standard changes against a reviewed definition, rather than assessed individually. That is a real reduction in per-change effort, and it is what collapses the queue.
Note what neither of those is. Neither is hiring. Cleared, qualified authorization staff are the scarcest input in this market, and an organization that could solve this by hiring would already have solved it.
The consequence for anyone selling into this
If you are proposing anything to an organization in this state, your proposal has an authorization cost, and their capacity to pay it in labor is the binding constraint, not their budget.
A proposal that does not say how much assessment work it creates, and how much it removes, is not a complete proposal. It is asking a team with no slack to find some, and the answer will be no.
Next in this series: why shrinking the estate does not save money, and what does.
Robert Burckner is the founder of Millabs Corporation. He has served as ISSM and ISSE for legacy weapon systems and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO).