Steven Hernandez is a DevSecOps and Cloud fellow at Systems Planning & Analysis, supporting U.S. Space Force command-and-control missions.
Walk into any defense technology event this year, and the conversation is artificial intelligence, start to finish. AI is real and it matters. But that focus has crowded out a quieter shift that will do more to determine whether new capability actually reaches the warfighter: platform engineering.
Platform engineering is the practice of building the shared, self-service foundations on which software is delivered. A platform is an internal product: the shared, self-service layer of infrastructure, pipelines, and hardened services that other teams build on, so the secure path is the default path and no one solves the same problem twice. That matters everywhere in software delivery, but it matters even more in defense because of authorization.
Nothing reaches the mission until it has an Authorization to Operate (ATO) under the Risk Management Framework, and earning that accreditation is some of the heaviest, slowest work in government software development lifecycles. A traditional ATO commonly takes six to 18 months, expires in roughly three years, and has to be re-earned for major changes. An accredited, self-service platform helps to rewrite that math through common control inheritance. Accredit the infrastructure once as a common control provider, and the applications that get delivered on top of it inherit those controls instead of re-earning them.
The Air Force’s Platform One provides the Party Bus service to run under a continuous authorization and states that new software can be approved for operation in about 30 days, compared with the six-month-plus norm. Other authorized DevSecOps platforms, including Kessel Run and Kobayashi Maru, offer a similarly condensed Path to Production.
This is what continuous authorization to operate (cATO) assumes, and it is worth settling one misconception: the platform does not hand out the authorization. A human authorizing official does, and what gets authorized is the system, not the pipeline. The platform industrializes the evidence and inherited controls that ongoing authorization runs on, enabling the authorization flow to keep pace with delivery instead of freezing it. The payoff accumulates as the accreditation and enclave access won on one contract become a baseline the next team reuses at far lower marginal cost. This is the head start that a challenger cannot easily copy.
The need for an internal platform discipline was demonstrated in industry first. After Amazon folded its software delivery machinery into shared platforms, it reached a production deployment rate of roughly every 11.6 seconds while cutting deployment-caused outages by 75%. Netflix did the same with a centrally supported paved road that it eventually open-sourced, sparing its teams from each carrying that load alone. Gartner now expects 80% of large engineering organizations to run internal platform teams by 2026.
None of this argues against AI. However, a model is inert until a platform can deliver, monitor, and re-authorize it inside a controlled environment. AI helps expose whether that delivery substrate is real. DORA found AI’s effect on performance strong where platform quality is high and negligible where it is low; MIT’s Project NANDA report found about 95% of enterprise AI pilots delivered no measurable profit-and-loss impact. The gap was traced back to integration, not model intelligence. Whatever comes next, from post-quantum cryptography to tools nobody has named, will ride the same platform requirements.
The hardest dependencies are often human: an authorizing official willing to move, a team of capable and independent assessors, delivery teams that actually adopt the paved roads you’ve built. The platform produces the evidence, but a human still grants the decision. The latest model may get the headlines, but the platform decides whether the mission ever sees the capability. For this wave of modernization and the next, that is the layer worth watching.
