Digital Acquisition in Defense: Six Years of the Pentagon’s Digital Engineering Strategy

In 2018, the Office of the Under Secretary of Defense for Research and Engineering issued a Digital Engineering Strategy that called, in plain language, for a fundamental shift: from documents as the authoritative record of defense systems to authoritative digital representations—models, databases, and connected architectures that would persist across a system’s lifecycle. The follow-on directives were not subtle. The Air Force’s 2019 Digital Acquisition pathway, the Army’s 2020 Digital Transformation Strategy, and the 2022 DAF Digital Engineering Implementation Plan all pointed the same direction.

Six years into this effort, the defense industrial base presents a study in accelerating divergence. The largest prime contractors have made genuine, measurable investments. Lockheed Martin, Raytheon Technologies (now RTX), Northrop Grumman, and Boeing Defense have all stood up dedicated digital engineering organizations, built Model-Based Systems Engineering (MBSE) competencies, and in several cases integrated model-based approaches into active production programs. Below that tier, the picture changes sharply. For the several thousand second-tier suppliers and the tens of thousands of third-tier suppliers that constitute the actual production base for defense hardware, digital acquisition remains aspirational language in contract requirements that many cannot practically satisfy.

What “Digital Acquisition” Actually Requires

Before assessing adoption, it helps to be precise about what the DoD strategy actually demands. At its core, digital acquisition requires three things working together.

First, an authoritative digital source of truth: a model or connected set of models that formally represents system requirements, architecture, behavior, interfaces, and verification status—and that is kept current as design evolves. Not a PDF of requirements. Not a Word document with change bars. A live, queryable representation.

Second, a digital thread: the connected linkage that allows any stakeholder to trace from an operational need through requirements, through design artifacts, through verification evidence, through test results, and ultimately through as-built configuration—without manually assembling that chain from disparate document stores.

Third, digital data rights and delivery: contracts that specify what digital artifacts must be delivered, in what format, at what fidelity, and with what government rights to access and reuse them.

Each of these requirements exposes a different fault line in the industrial base.

Where the Primes Are

The large prime contractors have, by any fair assessment, made substantive progress—driven partly by genuine conviction that digital engineering reduces development risk, and partly by the pragmatic reality that major new programs increasingly require it as a condition of competition.

Northrop Grumman’s work on the B-21 Raider is the most frequently cited example of digital engineering at scale on a major defense program. The program used a model-based approach from the outset, with digital design data serving as the configuration baseline rather than traditional engineering drawings. Northrop has been careful about what it will say publicly—B-21 is among the most sensitive programs in the DoD portfolio—but Air Force statements and contractor briefings at conferences like the annual NDIA Systems Engineering Division have confirmed that the digital approach contributed to an unusually smooth progression through critical design review relative to programs of comparable complexity.

Lockheed Martin’s F-35 Block 4 modernization effort has similarly leaned on MBSE tooling to manage the requirement density of a continuous capability upgrade program running across three variants and multiple international partners. The original F-35 development program was, famously, not a digital engineering success story. Block 4 is a partial correction: the requirements management infrastructure has been substantially rebuilt around connected models, even if the full digital thread to production and sustainment remains incomplete.

RTX’s work on hypersonic programs and next-generation missile systems has moved toward model-based requirements definition as a standard internal practice, accelerated by the recognition that hypersonic development timelines make traditional document cycles structurally incompatible with program schedules.

None of this is to suggest the primes have solved digital engineering. The honest assessment from engineering leadership at these companies—when speaking off the record at technical conferences—is that digital thread connectivity remains inconsistent, that MBSE tool proliferation has created integration problems, and that the cultural shift from drawing-centric to model-centric practice is genuinely difficult to sustain across organizations of tens of thousands of engineers.

The Supply Chain Gap Is Structural

The divergence below the prime tier is not primarily a motivation problem. Conversations with program managers, supplier development officers, and trade associations representing aerospace and defense suppliers consistently reveal that smaller companies understand the direction of travel. The problem is structural.

Tooling cost and complexity. The MBSE tool stack—combinations of Cameo, Capella, IBM DOORS or DOORS Next, Jama Connect, Polarion, or similar platforms, integrated with simulation environments and PLM systems—represents a capital and licensing investment that is feasible for a company with hundreds of systems engineers and amortizable across dozens of programs. For a 200-person electronics subassembly supplier with two or three engineers focused on requirements and systems work, the same investment is prohibitive.

Personnel scarcity. The defense industrial base collectively lacks enough trained MBSE practitioners. The primes are competing aggressively for systems engineers with model-based skills. Tier 2 suppliers are largely unable to compete on compensation. Training internally requires time and a learning curve that most program schedules do not accommodate.

Contractual inconsistency. This may be the most underappreciated structural problem. DoD contracts increasingly contain digital engineering requirements—specified digital deliverables, MBSE artifacts, digital thread documentation—but the specification language varies enormously across program offices, acquisition commands, and contracting vehicles. Suppliers on three different programs may face three incompatible interpretations of what a “digital requirements baseline” means. The compliance cost is not just technical; it is interpretive and administrative.

Government receiving capability. Perhaps the most ironic structural barrier is that the government, in many cases, cannot reliably receive and use the digital artifacts it contractually requires. Program offices that lack the tools, training, or data infrastructure to ingest a Cameo model or query a DOORS Next database end up accepting a PDF export as a substitute—which tells suppliers exactly how serious the requirement really is.

Programs That Have Worked—and Programs That Have Stalled

The Army’s Future Long-Range Assault Aircraft (FLRAA) program, awarded to Bell in 2022, is among the clearest recent examples of digital engineering requirements being implemented with genuine government intent. The Bell V-280 Valor’s competitive history involved extensive model-based design, and the FLRAA contract explicitly requires digital thread maintenance as a program execution standard, with government review of digital artifacts at major milestones. The Army stood up digital engineering support infrastructure at Program Executive Office Aviation specifically to receive and review these deliverables. Whether execution will match intent through production remains to be seen, but the structural conditions—government receiving capability, clear contract requirements, contractor investment—are in place.

The Joint All-Domain Command and Control (JADC2) effort, by contrast, illustrates what happens when digital engineering aspirations meet architectural complexity and institutional fragmentation. JADC2 involves dozens of programs, multiple services, multiple prime contractors, and a conceptual architecture that has shifted repeatedly. Multiple program offices have issued requirements for digital architecture representations using incompatible modeling frameworks. The result has been a collection of technically compliant but practically unconnected digital artifacts—each program’s models correct in isolation, interoperable with nothing. The digital thread across JADC2 programs does not exist in any meaningful operational sense.

The Ground-Based Strategic Deterrent (GBSD, now Sentinel) program is an instructive middle case. Northrop’s digital engineering approach on Sentinel has been more consistently implemented than on most programs of its scale, driven partly by the lessons internalized from B-21 and partly by aggressive government oversight from AFNWC. But independent assessments and Government Accountability Office reviews have noted that the digital thread to suppliers remains incomplete—the program’s digital baseline captures the prime’s design authority but does not consistently integrate supplier-provided components and subsystems into a unified model.

What Enforcement Actually Looks Like

The gap between contract requirements and operational digital thread is partly a technical problem and partly a contract administration problem. Defense Contract Management Agency (DCMA) has developed some digital engineering oversight capability, but enforcement of digital artifact quality—as opposed to delivery—requires technical judgment that DCMA does not consistently have at the program level.

The practical consequence is that digital deliverable requirements function, for many programs, as compliance checkboxes rather than operational constraints. Suppliers learn what format and level of fidelity will pass review. Program offices learn what to ask for to avoid conflict. The digital artifacts accumulate without necessarily constituting a functioning digital thread.

The DoD’s response to this problem has included the Digital Engineering Ecosystem initiative, piloted by OUSD(R&E), and a series of digital engineering reference architectures intended to standardize what programs should require and what government should expect to receive. Progress on standardization has been real but slow. The MBSE tool market has not consolidated around common interchange formats—SysML v2 adoption is progressing but not yet dominant in production programs—and the government’s own enterprise digital infrastructure remains fragmented across services and commands.

The Honest Five-Year Outlook

Projecting to 2031, the realistic trajectory is not universal digital thread adoption. It is tiered adoption with structural support for smaller suppliers.

The primes will continue to deepen digital engineering practice on new program starts. The cultural and organizational shift is far enough along at Lockheed, Northrop, RTX, and Boeing Defense that model-based practice is now the default for new development programs, even where legacy sustainment work remains document-centric. Competitive pressure from DARPA and OSD programs that require digital engineering as a condition of award will accelerate this.

The supply chain gap will require deliberate policy intervention to close. Several mechanisms are in discussion or early implementation: DoD-sponsored shared digital infrastructure that smaller suppliers can access without full enterprise tooling investment; simplified digital delivery standards calibrated to tier 2 and tier 3 supplier capabilities; mentor-protégé digital engineering programs that pair smaller suppliers with primes or government technical organizations.

The government receiving problem must be addressed in parallel. Program offices that cannot ingest and use digital artifacts will continue to create perverse incentives for suppliers to deliver compliant-but-useless digital content. Investment in program office digital engineering capacity—tools, training, and dedicated personnel—is a prerequisite for meaningful enforcement.

The tools serving this space are themselves evolving. Platforms like Flow Engineering, built specifically for AI-assisted requirements management and traceability with modern graph-based architectures rather than document-centric workflows, represent the direction that requirements and systems engineering tooling is moving—toward connected, queryable, AI-assisted models rather than the database-with-a-document-viewer paradigm that characterizes older enterprise platforms. As these tools mature and as SysML v2 interchange matures, the technical barriers to digital thread connectivity across supply chain tiers should decrease. The organizational and contractual barriers will take longer.

An Honest Assessment

The Pentagon’s Digital Engineering Strategy has produced real progress—concentrated at the prime contractor tier and on specific high-priority programs where government program offices invested in the receiving infrastructure to make digital thread requirements meaningful. It has not produced a transformed defense industrial base. The supply chain below the primes remains largely document-centric, and the gap is widening rather than narrowing as primes invest in capabilities their suppliers cannot match.

The next five years will determine whether digital acquisition becomes a genuine supply chain standard or a compliance exercise that the large primes satisfy while the production base that actually builds defense hardware continues to work from drawings and PDFs. That outcome depends less on technology—the tools exist—and more on whether acquisition policy, contract administration, and government infrastructure investment catch up to the rhetorical commitment that has been on paper since 2018.

The strategy was sound. The execution has been incomplete. That is an honest summary of where defense digital acquisition stands in 2026.