Read enough modernization plans for classified estates and you will find the same sentence in most of them: define the platform once as infrastructure as code, and pursue a single authorization across all security domains.
The instinct is right, and the literal thing is sometimes available. Whether it is available to you has a definite answer, and it is worth having that answer before the sentence goes into a plan.
The framework is not the obstacle
Start by clearing away an objection you may have been handed, because it is wrong.
An authorization boundary can contain components at more than one classification level. That is ordinary, not exotic. Where it happens, categorization takes the high water mark for each security objective under CNSSI 1253 rather than splitting the boundary, and multilevel systems and cross-domain solutions are authorized on exactly that basis. Nor is an AO's purview confined to a single level: JSIG, for one, governs systems at all classification levels under a special access program authorizing official's purview.
So if every domain in question falls under one AO, a single authorization spanning all of them is available to you. Go and get it. It is the cleanest outcome and nothing in the framework stands in the way.
The obstacle, where there is one, is organizational.
Count the names
Authorizing officials hold independent authority. An AO accepts risk on behalf of their organization for systems within their purview, and that authority is theirs. No AO binds another, and no document issued under one authority obliges a different AO to accept anything.
In a large classified estate the domains often sit in different authority chains altogether. Collateral systems fall to a Component AO under DoDI 8510.01. SCI systems fall to an intelligence element AO under ICD 503. SAP systems fall to a SAP AO under JSIG and DoDM 5205.07. Different governing policy, different overlays, different people. No amount of architecture merges those, because what separates them is not technical.
Which makes the first move a diagnostic, not a design exercise:
List your domains. Name the AO for each. Count the distinct names.
One name, and the single authorization is on the table. Several names, particularly across the collateral, SCI and SAP lines, and it is not available at any level of engineering effort. A plan that promises it anyway will be identified by the first AO who reads it, and the credibility you lose there is expensive.
Estates of the shape this series describes usually come back with several names. The rest of this post is for them.
The form that works either way
Change one word and you get something that works whether you have one AO or six.
Not one authorization. One assessed platform definition, inherited by each domain's authorizing official.
The platform is defined once, as code. It is assessed once against that definition, with the evidence produced by the pipeline that builds it. It is deployed in each domain from the same definition. Each AO reviews one thing, sees that it is the same thing their peer reviewed, and accepts it for their domain on their own authority.
Where several AOs are involved you do not get one ATO, and you were never going to. You get one artifact to build, one assessment to perform well, and several acceptances of it. In cost terms that is most of what people wanted from the single-ATO idea. Where a single AO does cover everything, the same discipline is what makes the single authorization tractable rather than a decade-long documentation exercise. Either way the engineering is identical, which is a good reason to start on it before the AO question is settled.
The policy wind is also behind you. DoD direction is that authorizations be accepted reciprocally to the maximum extent possible, and that a refusal be timely, documented, and reported up to the component senior information security officer. An AO who declines to inherit does not simply decline. They owe a written rationale to someone above them. That is not the same as being obliged to accept, and you should never present it as though it were, but it does mean a well-built inheritance case starts from a favorable position rather than asking for a favor.
What makes it defensible
The inheritance argument stands on a claim that has to be true: that the instance running in each domain is genuinely the same as the definition that was assessed.
This is precisely why infrastructure as code is the enabling piece rather than a modernization fashion. When the platform is a set of definitions in version control, built by a pipeline that emits its own evidence, "provably identical across domains" is a checkable statement rather than an assurance. Drift is detectable. Divergence is a diff. An AO being asked to inherit can see what they are inheriting.
Hand-built environments cannot make that claim honestly, no matter how carefully they were built to the same design. Two clusters assembled by the same skilled team from the same drawing are similar. They are not the same, nobody can demonstrate that they are, and an AO is right not to inherit on the strength of it.
The second half, which is where the queue goes
There is a bigger prize here than control inheritance, and it is the one that addresses the trap from the third post in this series.
Where the platform is a reviewed definition, a change to it is a reviewed pull request against something already assessed. That opens a path to treating whole classes of routine change as pre-approved standard changes, rather than as individual hand-written security impact assessments.
Recall that the approval queue is typically the largest single contributor to patch latency, and that it is slow because the team is at capacity on recurring work. This is the mechanism that removes work from that team rather than adding to it, which makes it the rare modernization that a fully committed authorization team can afford to say yes to.
That is worth stating explicitly when you propose it. Every other improvement asks them to spend capacity they do not have. This one gives some back.
What it does not do
Two honest limits, because a proposal that omits them will be caught.
Per-domain authorization work does not go to zero. Site-specific and domain-specific controls remain, along with the local AO's own requirements and process. A meaningful share of the work is irreducible, and anyone promising otherwise is selling something.
The authorization bill does not fall much. What changes is what the same team can do with it. You are buying capacity, not budget. As a share of a smaller estate, authorization may even rise.
That is still the right trade. An estate whose authorization team has usable slack can patch quickly, field capability on a schedule that matters, and absorb the next change. One without it cannot do any of those things, at any budget.
This is the last post in the series. It began by asking what the estate buys rather than what it costs.
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).
Millabs models estates of this shape and reruns the model the day a real input arrives. If you want to know what your own numbers say rather than what someone else's do, write to rbu@millabs.net.