Part of the DoW SBIR/STTR FY27 Release 2 topic list. Browse all 83 topics by industry or service.
Topic MDA27BZ02-DV008 from the DoW SBIR 2027 BAA, Release 2. Pre-release now; proposals due January 6, 2027, 12:00 PM ET.
Quick answer
MDA27BZ02-DV008 is a Missile Defense Agency Direct-to-Phase II SBIR topic seeking a repeatable virtualization bridge that runs hard-to-containerize legacy software as virtual machines managed by Kubernetes, including in air-gapped environments. Phase I-like proposals will be rejected. Proposals are due January 6, 2027, 12:00 PM ET.
Solicitation at a glance
- Topic number: MDA27BZ02-DV008
- Official title: Virtualization Bridge for Kubernetes: Enabling Complex Legacy Applications
- Agency: Missile Defense Agency
- Program: SBIR (DoW SBIR 2027 BAA, Release 2)
- Award type: Direct to Phase II (no Phase I awards)
- Award amount: Up to $2,000,000 (Direct to Phase II). Source: MDA Release 2 instructions in DSIP.
- CMMC level: Level 2 (Self)
- ITAR: Yes. Export-controlled (ITAR/EAR); see topic text
- Technology areas: Information Systems
- Pre-release (direct TPOC contact allowed): November 4 to December 2, 2026, 8:00 AM ET
- Opens in DSIP: December 2, 2026, 8:00 AM ET
- Proposals due: January 6, 2027, 12:00 PM ET
- Official source: DSIP Topics app (search MDA27BZ02-DV008)
BW&CO's take
What the Missile Defense Agency wants
MDA wants a repeatable way to run software that is hard to containerize, such as legacy simulation and analysis tools, GUI-dependent applications, and digital twins, as virtual machines managed by Kubernetes. The bridge should give these VMs scheduling, networking, storage, security, observability, and automation, work in local, hosted, and air-gapped clusters, and support GPU and host device assignment. Phase II implements it on a hosted or enterprise platform such as EKS, AKS, or OpenShift as fully automated Infrastructure-as-Code, covering storage, VM templates, golden images, RBAC, secure remote access, PKI/TLS, logging, metrics, backups, and import workflows, plus a cost/performance baseline.
Who is a good fit
- Hands-on experience running VMs as Kubernetes workloads
- Infrastructure-as-Code with tools like Terraform and Helm on EKS, AKS, or OpenShift
- Air-gapped, high-security deployments with RBAC, PKI/TLS, audit logging, and secure remote desktop access
- GPU passthrough and host device assignment for VM workloads
Watch-outs
- This is Direct-to-Phase II only. Phase I-like proposals are rejected as nonresponsive, and your feasibility documentation must show proof of concept in a relevant environment and/or TRL 5 or higher, from work substantially performed by your company or PI. Phase II starts by converting "the local prototype", so a working local implementation is the natural evidence.
- The approach must be distinguished from container runtime isolation and enterprise virtualization layers. Explain how your approach differs from both.
- The Phase II demonstration must show repeatable deployment, validated execution of legacy applications, secure user access, telemetry visibility, documented scaling constraints, and a baseline cost/performance comparison.
- The topic is marked ITAR-restricted, so export-control rules apply, and it lists CMMC Level 2 (Self).
Think your company fits MDA27BZ02-DV008? Talk with BW&CO before the January 6 deadline.
Plan Your MDA27BZ02-DV008 Submission
Official topic text (verbatim from DSIP)
The text in this section is copied word for word from the official DSIP topic as published on November 4, 2026. DSIP is the official source and topics can be amended. Always confirm the current version at dodsbirsttr.mil before you submit. Our commentary above is BW&CO's interpretation, not Government guidance.
Title
Virtualization Bridge for Kubernetes: Enabling Complex Legacy Applications
Objective
Develop a repeatable implementation pattern for running difficult-to-containerize software inside Kubernetes, beginning with legacy simulation and analysis tools and expanding to niche planning frameworks and complex “digital twins” within air-gapped, high-security environments. The goal is to reduce reliance on isolated physical workstations or manually managed Virtual Machines (VMs), improve repeatability through Infrastructure-as-Code (IaC), and facilitate integration with Kubernetes-hosted services such as object storage, databases, logging, monitoring, artificial intelligence / machine learning (AI/ML), workflow engines, and secure access.
Description
This topic proposes using a virtualization bridge to host applications that are impractical to containerize, bringing orchestration capabilities (scheduling, networking, storage, security, observability, automation, platform integration) to any workload deployed in Kubernetes.
Many mission, engineering, simulation, and analysis tools are challenging to operate as conventional containers due to dependencies on full operating system environments, desktop/Graphical User Interface (GUI) components, licensing services, specialized drivers, hardware access, or tightly coupled runtime requirements. A virtualization bridge allows virtual machines to run as Kubernetes-managed workloads, enabling VM-based applications to coexist with containerized services on the same platform.
This effort proposes using a virtualization bridge to host applications that are impractical to containerize, bringing orchestration capabilities (scheduling, networking, storage, security, observability, automation, platform integration) to any workload deployed in Kubernetes.
The starting point is an available Kubernetes environment (local clusters, hosted platforms, air-gapped environments). The virtualization bridge extends Kubernetes with VM-specific Application Programming Interfaces (APIs), centralizing workload placement, lifecycle management, access control, telemetry, and integration within the Kubernetes control plane. Compared to traditional VM hosting, this model improves operational repeatability and enables cluster-native integration with data services, Continuous Integration / Continuous Deployment (CI/CD) workflows, and AI/ML services.
This approach should be distinguished from related technologies such as container runtime isolation and enterprise virtualization layers. The core technology should be adaptable for local evaluation, deployment to hosted Kubernetes, and later for enterprise distributions or air-gapped environments.
Production-grade solutions require nodes with hardware virtualization support. For Graphics Processing Unit (GPU) or specialized device access, the virtualization bridge should support host device and GPU assignment, with integration patterns for GPU-accelerated VMs.
Phase I
Phase I-like proposals will not be evaluated and will be rejected as nonresponsive. For this topic, the Government expects the small business would have accomplished the following in a Phase I-like effort via some other means, e.g., independent research and development (IRAD) or other source, a concept for a workable prototype or design to address, at a minimum, the basic capabilities of the stated objective above. Proposal must show, as appropriate, a demonstrated technical feasibility or nascent capability. The documentation provided must substantiate the proposer’s development of a preliminary understanding of the technology to be applied in their Phase II proposal in meeting topic objectives.
Documentation should comprise all relevant information including, but not limited to, technical reports, test data, prototype designs/models, and performance goals/results. Feasibility = maturity and what have you already done/validated.
Proposers interested in participating in Direct to Phase II must include in their responses to this topic Phase I feasibility documentation that substantiates the scientific and technical merit and Phase I feasibility described in Phase I above has been met.
(i.e., the small business must have performed a proof of concept like “Phase I” component and/or other validation in a relevant environment, and/or at a much higher Technology Readiness Level (TRL) level (5 or higher) and describe the potential commercialization applications. The documentation provided must validate that the proposer has completed development of technology in previous work or research completed.)
IRAD work: Documentation should include the most relevant information including, but not limited to: technical reports, test data, prototype designs/models, and/or performance goals/results. Work submitted within the feasibility documentation must have been substantially performed by the proposer and/or the principal investigator (PI).
Phase II
Under the proposed solution, the contractor shall implement the virtualization bridge within a hosted or enterprise Kubernetes environment, such as Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), or Red Hat OpenShift. The contractor shall convert the local prototype into a fully automated, reusable deployment using Infrastructure-as-Code tools (e.g., Terraform, Helm). The solution shall encompass configuration of the virtualization bridge, persistent storage integration, VM templates, golden images, namespace and Role-Based Access Control (RBAC) boundaries, secure ingress or remote desktop access, Public Key Infrastructure (PKI) / Transport Layer Security (TLS), logging, metrics, backups, and image/data import workflows. The contractor shall ensure that node selection meets hardware virtualization requirements and assess application needs for GPU passthrough, high-memory nodes, and persistent storage. The contractor shall demonstrate repeatable deployment, validated execution of legacy applications, secure user access, telemetry visibility, documented scaling constraints, and provide a baseline cost/performance comparison.
Phase III Dual Use Applications
The contractor shall scale the proposed virtualization bridge solution to support multi-user operations, defining VM profiles for various application types and utilizing Kubernetes scheduling, node pools, quotas, templates, autoscalers, and policy-driven placement. User access shall be integrated with enterprise identity management, RBAC, audit logging, session controls, and approved remote access mechanisms. The solution shall enable cluster-adjacent storage, centralized observability, AI/ML workflow integration, and advanced tooling. Compliance and security controls shall be standardized through Kubernetes-native policies, image provenance, secrets management, network policy, storage encryption, logging, and deployment pipelines. For air-gapped environments, the contractor shall deliver a deployable bundle containing all necessary artifacts and documentation, resulting in a portable, virtualization-based operating model suitable for development, integration, and secure mission deployment.
References
Department of Defense (DoD) Enterprise DevSecOps Reference Design: Provides the architecture and security mandates for Kubernetes-based software factories. (https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf)
Cloud Native Computing Foundation (CNCF) – KubeVirt Project: An example of an open-source standard for building virtual machine management interfaces into Kubernetes. (https://kubevirt.io/)
DoD Platform One / Iron Bank: Repository for hardened containers and DevSecOps standards for secure environments. (https://p1.dso.mil/)
National Institute of Standards and Technology (NIST) Special Publication 800-190: Application Container Security Guide for securing container-centric enterprise architectures. (https://csrc.nist.gov/publications/detail/sp/800-190/final)
Keywords
Kubernetes virtualization; legacy applications; infrastructure-as-code; secure access; multi-user deployment; air-gapped environments; container-native virtualization
Frequently asked questions
What is MDA27BZ02-DV008?
It is a Missile Defense Agency SBIR topic to build a repeatable pattern for running difficult-to-containerize legacy simulation, analysis, and digital twin software as Kubernetes-managed virtual machines in air-gapped, high-security environments.
When is MDA27BZ02-DV008 due?
Proposals are due January 6, 2027, 12:00 PM ET. DSIP pre-release began November 4, 2026, and direct contact with the topic authors is allowed only until the topic opens on December 2, 2026, 8:00 AM ET.
Is this a Phase I or Direct-to-Phase II topic?
It is Direct-to-Phase II. Phase I-like proposals will be rejected as nonresponsive, so you must include feasibility documentation, such as technical reports, test data, and prototype designs, showing Phase I-equivalent work substantially performed by your company or PI.
Is this container sandboxing or a conventional VM platform?
Neither. The topic asks for a virtualization bridge that extends Kubernetes with VM-specific APIs so VMs run as Kubernetes-managed workloads alongside containers, and says it should be distinguished from container runtime isolation and enterprise virtualization layers.