DON26BZ03-NV059 TITLE: Real-time Zero Trust Data and Access Control for Combat Systems
OUSW (R&E) CRITICAL TECHNOLOGY AREA(S): Applied Artificial Intelligence (AAI)
COMPONENT TECHNOLOGY PRIORITY AREA(S): Integrated Sensing and Cyber
PROJECTED CMMC LEVEL REQUIREMENT: Level 2 (Self)
The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.
OBJECTIVE: Develop a real-time Zero Trust data access control system for combat systems.
DESCRIPTION: The Navy relies on combat system data for critical decision-making in wartime. This data must be secure to prevent unauthorized access and ensure its integrity. Current security measures are struggling to keep up with evolving threats, making it difficult to guarantee data is only seen by authorized personnel. This vulnerability compromises tactical advantages and risks operational effectiveness. Traditional security approaches are often too slow and inflexible for the dynamic nature of modern naval operations. An answer to this need is not commercially available.
The Navy seeks an adaptive "Zero Trust" data control system. Zero Trust is a security strategy for modern multi-cloud networks. Instead of focusing on the network perimeter, a Zero Trust security model enforces security policies for each individual connection between users, devices, applications and data.
Zero Trust operates on the principle of "never trust, always verify" rather than granting implicit trust to all users inside a network. This granular security approach helps address the cybersecurity risks posed by remote workers, hybrid cloud services, personally-owned devices, and other elements of today’s networks. This goes beyond simply having usernames and passwords. The Navy needs to verify every data access request in near real time, regardless of the user's location or device.
The sought solution requires leveraging both Government and commercial technologies: Advanced Authentication - moving beyond passwords to biometrics, multi-factor authentication, and behavioral analysis; Micro-segmentation - dividing data into smaller highly-controlled compartments to limit the impact of any potential breach (think of it like having separate locked filing cabinets for different types of sensitive information); Artificial Intelligence (AI) and Machine Learning (ML) - detecting anomalous behavior and automatically adapting security measures, which could involve analyzing user access patterns to identify potential threats in real-time; and Blockchain Technology - exploring its potential for secure data logging and access control, ensuring an immutable record of all data transactions.
This Zero Trust system must ensure that only authorized personnel can access sensitive data, regardless of location or device type, which is crucial for maintaining a tactical advantage in future conflicts where information superiority will be paramount. Existing, new, and emerging technologies will be crucial in building this system.
While promising technologies exist, they are not currently integrated or robust enough to meet the Navy's stringent security requirements. The new system must address real-time performance and must ensure access verification suitable for fast-paced combat scenarios. The Navy requires near-instantaneous system access to effectively respond to dynamic and evolving threats.
Furthermore, scalability and integration with complex Navy networks and systems must be ensured, along with system resilience to cyberattacks and the ability to function in degraded environments (i.e., situations where critical infrastructure or communication links may be compromised due to enemy action, natural disasters, or other disruptive events). The solution must develop faster (reduce average authentication time from 15 seconds to 5 seconds) and more efficient authentication methods; implement micro-segmentation techniques to reduce the attack surface by dividing a network into smaller isolated security segments; integrate AI/ML for real-time threat detection and response; and explore and adapt blockchain technology for secure data management. The Navy aims to achieve significant improvements compared to existing systems, including reducing access latency by at least 50%, reducing the risk of unauthorized data access by at least 90%, and streamlining data management processes to reduce administrative overhead by at least 25%.
The developed technology will be evaluated against National Institute of Standards and Technology (NIST) standards for compartmented data control, cybersecurity and data integrity (e.g., NIST SP 800-207, Zero Trust Architecture).
The Navy requires the development and integration of an adaptive "Zero Trust" data control system to secure critical combat data. This system must leverage advanced authentication, micro-segmentation, and AI/ML to provide near real-time, verified access for authorized personnel across any device or location. Key performance requirements include reducing authentication time to under five seconds, decreasing the risk of unauthorized data access by at least 90%, and ensuring the system is scalable, resilient in degraded environments, and compliant with NIST standards.
Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. § 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and NAVSEA in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations.
PHASE I: Develop a concept for a real-time Zero Trust data access control system for combat systems, specifically addressing the NIST standards associated with compartmented data control. Demonstrate the feasibility of this concept by providing detailed system architecture, including key technologies, algorithms, and data flow diagrams, which must include modeling and simulation to show the system's potential to meet Navy performance goals in the Description. (Note: If modeling and simulation alone cannot sufficiently demonstrate feasibility for specific aspects of the concept, propose and justify the use of subscale prototypes or surrogate systems, outlining their required characteristics and how they will contribute to a comprehensive feasibility assessment. For example, a subscale prototype might demonstrate the performance of a novel authentication mechanism under simulated network conditions, while a surrogate system could represent a simplified version of a combat system component for integration testing.)
The Phase I Option, if exercised, will include the initial design specifications and capabilities description to build a prototype solution in Phase II.
PHASE II: Develop a prototype of the Zero Trust data access control system for combat systems based on the results of Phase I. Demonstrate the core functionalities of the proposed system, including authentication, authorization, micro-segmentation, and real-time threat detection. Support testing of the prototype in a representative environment mirroring the complexity and data flow of a combat system network and including simulated cyberattacks and operational scenarios to assess the system's resilience and performance under stress. Deliver the prototype to the Navy.
It is probable that the work under this effort will be classified under Phase II (see the Description for details).
PHASE III DUAL USE APPLICATIONS: Support the Navy in transitioning the technology to Navy use. Transition the prototype Zero Trust data access control system into a fully operational capability for Navy use within the Maritime Targeting Cell - Afloat/Expeditionary (MTC-A/X) platform. The final product will be a robust, scalable, and secure system capable of managing and controlling access to sensitive combat system data in real-time, adhering to NIST standards and achieving the performance improvements outlined in previous phases.
The core technology developed under this effort has significant potential for dual-use applications in various commercial sectors. The need to protect sensitive data is not unique to the military. Businesses across numerous industries, including finance, healthcare, and energy, face similar challenges in safeguarding proprietary information and customer data from cyber threats and unauthorized access. The Zero Trust security model developed for the Navy can be adapted to protect sensitive corporate data, such as financial records, intellectual property, and personal health information.
REFERENCES:
KEYWORDS: Zero Trust Architecture; Access Control; Data Integrity; Cybersecurity; Multi-factor Authentication; Micro-segmentation
| 7/6/26 | Q. | The topic description asks proposers to explore blockchain technology for secure data logging and access control, ensuring an immutable record of data transactions. Would a local-first, hash-chained, cryptographically signed append-only ledger, providing tamper-evident audit records on each node and supporting replication and cross-node anchoring when connectivity permits, satisfy the intent of this element, or does the Navy specifically require distributed ledger technology with consensus across multiple nodes? |
| A. | A local-first, hash-chained, cryptographically signed append-only ledger that provides tamper-evident audit records on each node and supports replication and cross-node anchoring when connectivity permits would satisfy the intent of this element. The Navy does not specifically require distributed ledger technology with consensus across multiple nodes; the requirement is for an immutable, tamper-evident audit log that meets operational and security objectives, especially in environments with intermittent or degraded connectivity. | |
| 7/1/26 | Q. | 1. What is the current baseline for access latency (in order to claim at least 50% reduction)?
2. What is the current baseline for unauthorized access risk management (in order to claim at lease 90%% reduction)? |
| A. | 1. Offerors should use representative or synthetic baselines for modeling and clearly document their assumptions when claiming at least a 50% reduction.
2. Offerors should define and document their baseline assumptions for risk measurement in order to substantiate claims of at least 90% reduction. |
|
| 7/1/26 | Q. | "The described system's immutable transaction records and authentication credentials must remain trustworthy over the service life of the combat systems they protect. Should proposers treat quantum-resistant cryptography (e.g., CNSA 2.0 timelines, NIST FIPS 204/ML-DSA) as an evaluation consideration for the Phase I architecture, or is algorithm selection deferred to Phase II?" |
| A. | Proposers should consider quantum-resistant cryptography as an evaluation consideration for the Phase I architecture, given the requirement for immutable transaction records and authentication credentials to remain trustworthy over the service life of the combat systems. However, detailed algorithm selection may be further refined in Phase II. | |
| 6/29/26 | Q. | The topic emphasizes resilience in degraded and contested environments. Should proposers assume that the enforcement mechanism must maintain correct operation even in the event of a compromised host operating system or host processor firmware — that is, should the enforcement layer be architecturally independent of the host software stack? |
| A. | Proposers should assume that the enforcement mechanism must maintain correct operation even in the event of a compromised host operating system or host processor firmware. The enforcement layer should be architecturally independent of the host software stack to ensure resilience and security in degraded and contested environments. | |
| 6/29/26 | Q. | For the Phase I prototype demonstration, is there a preferred combat system bus protocol (e.g., AMBA AXI4, VME, PCIe, MIL-STD-1553) against which proposers should validate their enforcement architecture, or is protocol selection at the proposer's discretion? |
| A. | For the Phase I prototype demonstration, protocol selection is at the proposer’s discretion. Recommend proposers select protocols that are representative of Navy combat-system environments and document their rationale. | |
| 6/25/26 | Q. | We would appreciate clarification on the intended scope of the system architecture in Phase I versus later phases. The topic description states that Phase I should “develop a concept for a real-time Zero Trust data access control system for combat systems, specifically addressing the NIST standards associated with compartmented data control” (emphasizing access control and the Zero Trust control plane). However, later phases describe a final capability that “manag[es] and control[s] access to sensitive combat system data in real time,” which appears to include data-plane enforcement and system-level isolation.
Could you clarify whether the Navy expects Phase I concepts to address only the control-plane elements of Zero Trust (authentication, authorization, policy evaluation), or whether Phase I should also address data-plane mechanisms such as system isolation, workspace encapsulation, or wrapped application access models? |
| A. | Phase I should focus on concept development, architecture, and control-plane elements, while later phases expand to data-plane enforcement and system-level isolation. | |
| 6/25/26 | Q. | 1. Is the focus on user authentication, or do assets/devices connecting to the network need to be authenticated as well?
2. For resiliency, can we assume a combination of a centralized CA and distributed (2nd) CAs that PEPs work with to authenticate users/assets during network disruptions? 3. Should the solution include mitigation against corrupted/failing/compromised network infrastructure? For instance, elements of the solution could interact to find data paths around compromised network/link segments. |
| A. | 1. Both user and device/asset authentication are required.
2. A combination of centralized CA and distributed secondary CAs for PEPs is acceptable for resiliency during network disruptions. 3. The solution should include mitigation against corrupted, failing, or compromised network infrastructure, including dynamic data path selection. |
|
| 6/24/26 | Q. | Are the scalability requirements known? (eg: Need to be able to scale up to 500,000 users across 50 applications and networks) |
| A. | Recommend that offerors design for extensibility and document assumptions. | |
| 6/24/26 | Q. | Is there an intended security assurance level (eg: Impact Level 5/6) that this solution must be built to? |
| A. | Build the solution to the appropriate security assurance level (e.g., Impact Level 5/6) as required for Navy operational environments. | |
| 6/24/26 | Q. | Will this project have access to the DoW GenAI initiative and be able to leverage DoW internal AI models? |
| A. | Proposers should not assume access to the DoW GenAI initiative or internal DoW AI models. | |
| 5/10/26 | Q. | Will any of the intended operating locations or personnel be non-Navy Industry level users? |
| A. | Some operating locations or personnel may be non-Navy industry users; design for flexibility. | |
| 6/24/26 | Q. | Will the intended operating locations be entirely NIPRNET connected or is SIPRNET also intended? |
| A. | Classified operating locations may be relevant; do not assume NIPRNET-only. | |
| 6/24/26 | Q. | Should proposers assume any limitations on endpoint hardware capabilities, processing resources, biometric devices, or specialized authentication hardware within representative combat system environments? |
| A. | Biometric devices and advanced authentication hardware should not be assumed universally present across all platforms. As such, proposed solutions should be adaptable, offering robust security and Zero Trust enforcement even on resource-limited devices, and should provide alternative authentication and access-control mechanisms where specialized hardware is unavailable. | |
| 6/24/26 | Q. | What assumptions should proposers make regarding degraded communications, disconnected operations, and intermittent network connectivity in afloat or expeditionary environments? |
| A. | Proposers should design for robust, autonomous operation in environments where connectivity is unreliable or absent, ensuring that Zero Trust principles are upheld without dependence on continuous reach-back to central services. The architecture must support local decision-making, secure logging, and seamless recovery/synchronization when communications are restored. | |
| 6/24/26 | Q. | Should the Phase I architecture prioritize shipboard environments, shore-based environments, or a hybrid architecture supporting both? If requirements differ, should both operational contexts be addressed? |
| A. | The architecture should support both shipboard and shore-based environments, or a hybrid, as requirements dictate. | |
| 6/24/26 | Q. | Should proposers assume support for multiple authentication assurance levels (e.g., workstation access, application access, data access, and privileged administrative access), each with different authentication requirements? |
| A. | Support for multiple authentication assurance levels (workstation, application, data, privileged access) should be assumed, each with different requirements. | |
| 6/24/26 | Q. | Are there existing Navy identity, credential, and access management (ICAM) services, PKI infrastructure, or authentication solutions that the Phase I concept should assume will be available for integration? |
| A. | Assume existing Navy ICAM services, PKI infrastructure, and authentication solutions are available for integration. | |
| 6/24/26 | Q. | What combat system environment should proposers use as the primary Phase I reference architecture (e.g., CANES, GCCS-M, Aegis, MTC-A/X, or another representative environment)? |
| A. | For Phase I, use a generic or platform-agnostic combat-system reference architecture, with a pathway toward MTC-A/X. | |
| 6/24/26 | Q. | Are there operational or cybersecurity restrictions regarding the use of wireless technologies (e.g., Wi-Fi, Bluetooth, NFC, wearable authenticators, or proximity-based credentials) that should be assumed during Phase I concept development? |
| A. | Assume operational and cybersecurity restrictions on wireless technologies; use of Wi-Fi, Bluetooth, NFC, and wearables. | |
| 6/23/26 | Q. | The topic does not reference the NIST SP 800-82 or the DoW CIO ZT For OT Activities and Outcomes guidance - will these be the OT-related ZT reference guidance and evaluation criteria, or is a different standard be utilized? |
| A. | NIST SP 800-82 and DoW CIO ZT for OT Activities and Outcomes are relevant for OT-related ZT guidance. | |
| 6/23/26 | Q. | Are cloud, edge, shipboard, expeditionary, and disconnected deployment models all in scope, or should offerors assume a specific deployment environment for Phase I and Phase II? |
| A. | Cloud, edge, shipboard, expeditionary, and disconnected deployment models are all in scope; offerors should address the most relevant environments for their solution. | |
| 6/23/26 | Q. | Are there specific cybersecurity, safety, or mission-assurance constraints that should govern automated access denial, quarantine, micro-segmentation, or other enforcement actions in operational combat-system environments? |
| A. | Enforcement actions must comply with Navy and DoD cybersecurity policies and standards (e.g., NIST SP 800-53, NIST SP 800-207, CMMC, NISPOM). Automated responses should be auditable, reversible, and based on risk assessment. Micro-segmentation should be granular enough to contain threats but flexible enough to allow legitimate mission data flows. | |
| 6/23/26 | Q. | For Phase III transition, the topic identifies the Maritime Targeting Cell - Afloat/Expeditionary platform. Should Phase I and Phase II concepts be explicitly tailored to that transition target, or should offerors present a more general combat-system access-control architecture with a transition path to that platform? |
| A. | Phase I and Phase II concepts should be platform-agnostic. | |
| 5/10/26 | Q. | Should the proposed solution be designed primarily as an inline enforcement capability, an out-of-band policy-decision capability, an integration layer around existing systems, or is the Government open to any architecture that satisfies the performance and security requirements? |
| A. | The Government is open to any architecture (inline enforcement, out-of-band policy-decision, integration layer, etc.) that satisfies performance and security requirements. | |
| 6/23/26 | Q. | What unclassified, synthetic, surrogate, or Government-furnished data will be available for Phase I or Phase II modeling, simulation, prototype development, or performance evaluation? |
| A. | Unclassified, synthetic, or surrogate data may be used for Phase I and Phase II; government-furnished data is not guaranteed. | |
| 6/23/26 | Q. | In Phase II, what constitutes a “representative environment” for testing? Please clarify expected scale, data-flow complexity, number of users/devices, representative combat-system components, cyberattack scenarios, and performance thresholds. |
| A. | A representative Phase II environment should include assume a segmented, multi-tiered network topology with 50–200 users, 100–500 devices (including sensors, workstations, and tactical endpoints), high data-flow rates (10–100 Mbps per segment), latency constraints under 100 ms for critical data, and intermittent connectivity (e.g., due to EMCON or adversary action). | |
| 6/23/26 | Q. | How should offerors address operations in degraded, denied, intermittent, or limited-connectivity environments? In particular, should the system continue making local access-control decisions when disconnected from central services, and are there preferred fail-open, fail-closed, or mission-prioritized behaviors? |
| A. | The system should continue making local access-control decisions when disconnected from central services; fail-open, fail-closed, or mission-prioritized behaviors should be determined by operational context, with a preference for mission assurance. | |
| 6/23/26 | Q. | The topic references blockchain technology for secure logging and access control. Is blockchain a required design element, or may offerors propose alternate tamper-evident, immutable, or non-repudiable logging mechanisms that meet the same operational and security objectives? |
| A. | Blockchain is not a required design element; alternate tamper-evident, immutable, or non-repudiable logging mechanisms are acceptable if they meet operational and security objectives. | |
| 6/23/26 | Q. | For operational-technology and embedded-system portions of the representative environment, should offerors assume constraints such as legacy operating systems, limited compute resources, intermittent connectivity, no endpoint agent installation, safety-critical timing requirements, or restricted ability to modify host software? |
| A. | For OT and embedded-system portions, assume constraints such as intermittent connectivity, no endpoint agent installation, safety-critical timing, and restricted ability to modify host software. | |
| 6/23/26 | Q. | Are specific modeling, architecture, or systems-engineering formats preferred for Phase I deliverables, such as DoDAF views, SysML, MBSE artifacts, executable simulations, performance reports, data-flow diagrams, or interface-control descriptions? |
| A. | No specific modeling, architecture, or systems-engineering formats are mandated; DoDAF views, SysML, MBSE artifacts, executable simulations, performance reports, data-flow diagrams, and interface-control descriptions are all acceptable. | |
| 6/23/26 | Q. | For Phase I feasibility, what level of modeling and simulation is expected? For example, should offerors model cyber effects, network latency, policy-decision performance, combat-system data flows, degraded communications, representative workloads, or some combination of these? |
| A. | Phase I modeling and simulation should include cyber effects, network latency, policy-decision performance, combat-system data flows, degraded communications, and representative workloads. | |
| 6/23/26 | Q. | Should proposed solutions preserve CAC/PKI-based authentication as a mandatory element, or may offerors propose complementary or alternative mechanisms such as risk-based authentication, behavioral analytics, biometric factors, device posture, or continuous authentication? |
| A. | Proposed solutions should preserve CAC/PKI-based authentication as a mandatory element but may propose complementary or alternative mechanisms. | |
| 6/23/26 | Q. | What existing Government-furnished infrastructure, interfaces, or services should offerors assume must be integrated with during Phase I and Phase II? Conversely, what components of the representative combat-system environment should be treated as out of scope for modification? |
| A. | Offerors should assume integration with existing Navy ICAM services, PKI infrastructure, and authentication solutions; components outside the representative combat-system environment may be out of scope for modification. | |
| 6/23/26 | Q. | What authoritative identity, credential, and attribute sources should offerors assume are available in the target environment, such as DoD PKI/CAC, roles, billets, clearance attributes, device posture, mission context, or locally maintained access-control data? |
| A. | Offerors should assume authoritative sources such as DoD PKI/CAC, roles, billets, clearance attributes, device posture, mission context, and locally maintained access-control data are available. | |
| 6/23/26 | Q. | Please clarify the expected access-control model. Is the Government seeking system- or network-level access control, data-object-level access control, attribute-based access control, or some combination of these? |
| A. | The expected access control model is a combination of system level access control, data object level access control, and attribute based access control. | |
| 6/23/26 | Q. | In order to consider solution options for application layer controls in the ZTA solution, will the govt provide a data dictionary, YAML, any applicable JSON structures and / or ontologies that inform us of the messaging protocols and data being exchanged so that we can best model the solution and verify that it will meet latency thresholds and other performance requirements? Are there specific APIs that must be accommodated and can we have the specs of those? Any network constraints, overhead limitations, etc would also be helpful. |
| A. | Proposers are expected to use representative models and standard assumptions for Navy combat-system messaging protocols and data flows in their modeling and simulation activities. If such technical details (e.g., data dictionaries, API specs, or protocol definitions) are made available, it would likely occur in later phases (such as Phase II). For Phase I, no specific APIs or data structures are identified for accommodation, and proposers should model typical Navy network constraints—including low-latency requirements, support for intermittent connectivity, and overhead limitations—based on public standards and best practices. | |
| 6/23/26 | Q. | The solution model and sim environment would be most robust if it demonstrated the ability to meet the clarified ability to “…support a heterogeneous environment with a mix of operating systems and device types, including both general-purpose and mission-specific hardware. ”
Is there any chance that a list of the protocols or systems that make up the Navy Combat Systems C4ISR architecture that is applicable to this SBIR could be provided? Any system that would require enforcement of a ZTA solution IOT communicate with MTC-A/X? GCCS-M, TADIL, and other systems? For the list of systems or protocols, will the govt provide interface documentation (ICD), or anything to establish the minimum protocols that must be accommodated? |
| A. | A list of protocols or systems (e.g., GCCS-M, TADIL) is not provided; offerors should use representative Navy C4ISR protocols and systems and document their assumptions. Interface documentation (ICD) is not guaranteed for Phase I. | |
| 6/22/26 | Q. | The topic specifies reducing average authentication time from 15 seconds to 5 seconds. Could the Government clarify (1) how authentication time is measured, (2) what activities are included in that measurement (e.g., credential validation, MFA, authorization, policy evaluation, network communication, data access), and (3) the primary sources of latency in the current operational environment? |
| A. | Authentication time is measured from user initiation to access granted, including credential validation, MFA, authorization, policy evaluation, network communication, and data access; primary sources of latency include network delays, credential checks, and policy evaluation. | |
| 6/22/26 | Q. | The Phase III transition target is identified as the Maritime Targeting Cell - Afloat/Expeditionary (MTC-A/X). For Phase I feasibility analysis and Phase II prototype integration testing, does the Navy prefer that proposers design against a Government-furnished surrogate or reference architecture representative of MTC-A/X data and message flows, or should proposers design against a generic NAVSEA combat-system enclave topology that the proposer models and documents independently for Navy review? |
| A. | For Phase I feasibility and Phase II prototype integration, proposers should design against a generic NAVSEA combat-system enclave topology that is modeled and documented independently, unless otherwise directed by the Navy; government-furnished surrogate or reference architectures are not guaranteed. | |
| 6/22/26 | Q. | The topic emphasizes function in degraded environments. To size offline policy caching, local audit-chain growth, and re-attestation behavior correctly, could the Navy clarify the intended Zero Trust operating envelope under denied or disconnected conditions? Specifically, is the design point measured in minutes of disconnection (transient comms outages), hours (a contested operating window), or days (sustained denied operation)? |
| A. | The intended Zero Trust operating envelope under denied or disconnected conditions should cover minutes (transient outages), hours (contested windows), and days (sustained denied operation); solutions should be robust across all these scenarios. | |
| 6/22/26 | Q. | Zero Trust mandates centralized policy management, but this topic requires operation in degraded environments where the central policy authority may be unreachable due to battle damage or communications loss. In that scenario, should policy enforcement points continue operating with locally cached policy at a reduced confidence level, or should they fail to a deny-all posture until connectivity is restored? |
| A. | Policy enforcement points should continue operating with locally cached policy at a reduced confidence level during loss of connectivity, rather than failing to a deny-all posture, to maintain mission effectiveness. | |
| 6/22/26 | Q. | Could you provide a reference (DoNI/R, etc.) or further details on the level of micro-segmentation desired? For example, is the desired micro-segmentation per endpoint, per user, per process, per file, or per platform? Explanation: The required micro-segmentation will bound the available technologies that can meet those requirements. |
| A. | Proposers should design for fine-grained, context-aware micro-segmentation—ideally at the user, device, data-object/message, and compartment level, and extend to process or application level where operationally practical. This approach aligns with NIST and DoD Zero Trust guidance. | |
| 6/13/26 | Q. | The Q&A confirms that OT environments including sensors, weapons control, and navigation are in scope. Are there specific industrial communication protocols used in the target combat system networks (e.g., Modbus TCP, DNP3, OPC-UA, BACnet) that proposers should prioritize for protocol-aware access control, or should proposals address multiple common OT protocols? |
| A. | The SBIR topic does not specify particular industrial protocols. Proposers should address multiple common OT protocols relevant to Navy combat systems to ensure broad applicability and protocol-aware access control across diverse OT environments. | |
| 6/13/26 | Q. | For Phase II prototype testing in a "representative environment mirroring the complexity and data flow of a combat system network," will the Government provide access to a test environment or reference architecture, or should proposers plan to develop their own surrogate test environment for Phase II integration testing? |
| A. | Proposers should plan to develop their own surrogate test environment for Phase II integration testing. The SBIR topic does not guarantee Government-provided testbeds or architectures for Phase II; representative environments should be constructed by the proposer to mirror Navy combat-system complexity and data flows. | |
| 6/13/26 | Q. | For Phase I, will the evaluation favor architectures demonstrating a localized edge-resident policy engine with cryptographically immutable audit logging during DDIL/comms-denied operation, including offline log integrity and re-verification upon reconnection? |
| A. | Yes. The evaluation will favor architectures that support localized, edge-resident policy engines and cryptographically immutable audit logging that maintain log integrity during disconnected, degraded, intermittent, or limited (DDIL) communications, with re-verification and reconciliation upon reconnection. | |
| 6/11/26 | Q. | For Phase II prototype testing in a "representative environment mirroring the complexity and data flow of a combat system network," will the Government provide access to a test environment or reference architecture, or should proposers plan to develop their own surrogate test environment for Phase II integration testing? |
| A. | Proposers should plan to develop their own surrogate test environment for Phase II integration testing. The SBIR topic does not guarantee Government-provided testbeds or architectures for Phase II; representative environments should be constructed by the proposer to mirror Navy combat-system complexity and data flows. | |
| 6/13/26 | Q. | The topic lists a Projected CMMC Level Requirement of Level 2 (Self). Is a completed SPRS self-assessment required at the time of proposal submission, or can it be completed prior to Phase I contract award? |
| A. | As stated in the DON Proposal Submission instructions, CMMC Level requirements are identified within each topic and must be met prior to award. | |
| 6/11/26 | Q. | Is the Government seeking an integrated concept spanning all the named technology areas, or is a proposal that deeply advances one element within a broader reference architecture, for example the authorization and enforcement layer, responsive? |
| A. | The Government is seeking an integrated concept spanning all the named technology areas—including advanced authentication, micro-segmentation, AI/ML for threat detection, and secure data management (potentially with blockchain or equivalent auditability).
A proposal that only advances one element (such as just the authorization and enforcement layer) would not be fully responsive unless it is clearly positioned as a critical, integrable component within a broader Zero Trust architecture and demonstrates how it enables or enhances the full end-to-end solution the Navy requires. |
|
| 6/10/26 | Q. | Could you please clarify or provide examples of use cases that you would like to target. Thank you for your time. |
| A. | Targeted use cases include:
|
|
| 6/8/26 | Q. | Which operating systems / types of devices are part of the requirement? |
| A. | Proposers should assume the Zero Trust solution must support a heterogeneous environment with a mix of operating systems and device types, including both general-purpose and mission-specific hardware. | |
| 6/8/26 | Q. | Are you interested in Zero Trust for Operational Technology environments too? |
| A. | The focus for this topic is on combat systems, real-time data, and resilience in degraded environments and includes Operational Technology (OT) environments such as sensors, weapons control, navigation, and other mission-critical embedded systems. | |
| 6/7/26 | Q. | If we want to upload the document and presentation we created for this RFP or solicitation, what are the steps we need to take in order to upload the artifacts (documents) in order to apply for this potential opportunity? I ask, because when I tried to that for this particular opportunity, it is not listed under the DOW SBIR 2026 BAA or DOW STTR 2026 BAA or others. Please advise. |
| A. | A Phase I proposal template specific to DON to meet Phase I requirements is available at https://navysbir.com/links_forms.htm . As noted in the DON instruction, Supporting Documents (Volume 5) will not be considered in the selection process. | |
| 6/7/26 | Q. | What are the Phase 1 budget and timeline constraints for this topic? What is the page limit for Phase 1 proposals? |
| A. | Thank you for your interest in the DON SBIR/STTR Programs! As noted in the DoW Preface for this solicitation, questions posted to DSIP Topic Q&A must be limited to specific information related to understanding a particular topic’s requirements.
For questions related to DON’s participation in the solicitation or questions specific to DON’s component instruction you may email the DON SBIR/STTR Program Management Office at [email protected] You will also find the information you are requesting in the DON 2026 Release 3 BAA instruction. |
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoW FY-26 Release 3 SBIR BAA. Please see the official DoW Topic website at www.dodsbirsttr.mil/submissions/solicitation-documents/active-solicitations for any updates. The DoW issued its Navy FY-26 Release 3 SBIR Topics pre-release on June 3, 2026 which opens to receive proposals on June 24, 2026, and closes July 22, 2026 (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (June 3, through June 23, 2026) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. The TPOC contact information is listed in each topic description. Once DoW begins accepting proposals on June 24, 2026 no further direct contact between proposers and topic authors is allowed unless the Topic Author is responding to a question submitted during the Pre-release period. DoD On-line Q&A System: After the pre-release period, until July 8, 2026, at 12:00 PM ET, proposers may submit written questions through the DoW On-line Topic Q&A at https://www.dodsbirsttr.mil/submissions/login/ by logging in and following instructions. In the Topic Q&A system, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing.
DoW Topics Search Tool: Visit the DoW Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoW Components participating in this BAA.
|