Real-time Zero Trust Data and Access Control for Combat Systems

# Q&A Changes Summary **New Answer Added:** - **Q1** now has a complete answer clarifying that a local-first, hash-chained, cryptographically signed append-only ledger satisfies the blockchain requirement. The Navy does NOT require distributed ledger technology with consensus across multiple nodes—the focus is on immutable, tamper-evident audit logs suitable for intermittent connectivity environments. **No other substantive changes detected.** Questions Q2–Q16 and their answers remain identical to the previous version. Q17 appears truncated in both versions and was not updated.

**Changes to Q&A:** - **Q2 answered:** Offerors must use representative/synthetic baselines and document assumptions to substantiate claims of 50% latency reduction and 90% risk reduction. - **Q3 answered:** Quantum-resistant cryptography should be considered in Phase I architecture design; detailed algorithm selection may be refined in Phase II. All other Q&As (Q1, Q4-Q18) remain unchanged from previous version.

**Summary of Q&A Changes:** **New Question Added:** - Q1 (now first): Clarifies blockchain implementation—local-first, hash-chained append-only ledger acceptable; distributed ledger consensus not strictly required. **Renumbered Questions:** - Previous Q1-Q20 shifted to Q2-Q20 due to new blockchain Q1 insertion. - Original Q2-Q3 (baseline latency/crypto) now Q2-Q3. - Original Q4-Q19 now Q4-Q19. **No New Answers Added:** - All renumbered questions retain original answers unchanged. - Questions Q20+ (previously marked "...") remain incomplete in both versions. **Key Impact:** Blockchain/ledger technology guidance is now prioritized as opening clarification, explicitly permitting local-first append-only implementations over distributed consensus models for Phase I concepts.

**Changes to Q&A:** Added answers to Q3 and Q4: - **Q3**: Enforcement layer must be architecturally independent of host software stack, maintaining operation even if OS/firmware compromised. - **Q4**: Protocol selection at proposer's discretion for Phase I prototype; recommend documenting rationale for Navy combat-system representativeness. Q20 appears truncated in updated version (text cuts off mid-question).

# Q&A Changes Summary **New/Updated Answers Added:** - **A5**: Phase I focuses on control-plane elements; data-plane enforcement deferred to later phases. - **A6**: Both user and device authentication required; centralized + distributed CAs acceptable; dynamic data path selection needed for compromised infrastructure. - **A7**: Design for extensibility; document scalability assumptions (no fixed requirement stated). - **A8**: Build to appropriate security assurance level (e.g., Impact Level 5/6) for Navy environments. - **A9**: Do NOT assume access to DoW GenAI initiative or internal AI models. - **A10**: Design for non-Navy industry users; assume flexibility required. - **A11**: Classified (SIPRNET) environments may be relevant; don't assume NIPRNET-only. - **A12**: Don't assume biometric/advanced hardware universally available; design for resource-limited devices with alternative authentication. - **A13**: Design for autonomous operation in disconnected/unreliable connectivity; local decision-making required without dependence on central services. - **A14**: Support both shipboard and shore-based (or hybrid) environments. - **A15**: Support multiple authentication assurance levels (workstation, application, data, privileged). - **A16**: Assume existing Navy ICAM, PKI, and authentication solutions available for integration. - **A17**: Use platform-agnostic reference architecture with pathway to MTC-A/X. **Key Clarifications**: Control-plane focus for Phase I; disconnected/degraded operations required; no DoW GenAI access; flexible hardware assumptions.

# Q&A Changes Summary **New Answers Provided:** - **Q18** (Wireless Technologies): Operational and cybersecurity restrictions assumed on Wi-Fi, Bluetooth, NFC, and wearables. - **Q19** (OT Standards): Clarifies NIST SP 800-82 and DoW CIO ZT for OT Activities and Outcomes are relevant guidance. - **Q20** (Deployment Models): Cloud, edge, shipboard, expeditionary, and disconnected models all in scope; offerors should address most relevant environments. - **Q21** (Enforcement Constraints): Actions must comply with Navy/DoD policies (NIST SP 800-53, 800-207, CMMC, NISPOM); must be auditable, reversible, risk-based; micro-segmentation should balance containment with mission flexibility. - **Q22** (Phase III Transition): Phase I/II concepts should be **platform-agnostic** (not tailored to Maritime Targeting Cell). - **Q23** (Architecture): Government is open to any architecture (inline, out-of-band, integration layer) meeting requirements. - **Q24** (Test Data): Unclassified/synthetic data acceptable for Phase I/II; government-furnished data not guaranteed. - **Q25** (Phase II Environment): Representative environment specs: 50–200 users, 100–500 devices, 10–100 Mbps data flows, <100 ms latency, intermittent connectivity. - **Q26** (Partial): Addresses degraded/denied/intermittent connectivity operations (answer appears truncated).

# Q&A Section Changes Summary **New questions added:** - Q1: Baseline metrics clarification – current access latency baseline (to measure 50% reduction) and unauthorized access risk baseline (to measure 90% reduction) - Q2: Quantum-resistant cryptography consideration (CNSA 2.0, NIST FIPS 204/ML-DSA) – whether to address in Phase I or defer to Phase II **Questions removed/consolidated:** Approximately 9 questions were removed from the original Q&A (Q7, Q15-Q31 from original list), leaving 31 questions in the updated version compared to the original ~31-question set. The truncation suggests the updated document may continue beyond what was provided. **Key clarification added:** The new Q1 and Q2 introduce **measurable performance baselines** and **cryptographic roadmap considerations** that were not previously addressed, indicating the Government is seeking concrete metrics for evaluation and long-term security posture planning. **No substantive answer updates noted** to previously answered questions in the visible portion – the changes appear to be additions and reorganization rather than revisions to existing responses.

# Q&A Changes Summary **New Questions Added (2):** - Q1: Whether enforcement mechanism must be architecturally independent of host OS/firmware in compromised scenarios - Q2: Preferred combat system bus protocol (AMBA AXI4, VME, PCIe, MIL-STD-1553) for Phase I prototype validation **Questions Renumbered:** Previous Q1-Q31 shifted to Q3-Q31 to accommodate new entries. **Key Impact:** The additions signal increased focus on hardware-level independence and resilience in contested/degraded environments, suggesting the Government expects proposals addressing enforcement mechanisms that survive OS-level compromise.

**Summary of Q&A Changes:** Added 30 new questions (Q1–Q30) covering critical Phase I scope clarification, technical architecture, operational environment assumptions, and evaluation criteria. Key additions include: - **Scope clarification** (Q1): Phase I should address control-plane elements; data-plane mechanisms are negotiable - **Authentication** (Q2, Q11, Q27): Both user and asset authentication required; multiple assurance levels expected; CAC/PKI mandatory or alternative approaches acceptable - **Environment assumptions** (Q8–Q10, Q16, Q24): Heterogeneous OS/devices, both shipboard and shore-based, NIPRNET/SIPRNET, degraded/disconnected operations, legacy OT systems with resource constraints - **Reference architecture** (Q12–Q13, Q15): Existing Navy ICAM/PKI integration expected; NIST SP 800-82 and DoW CIO ZT For OT guidance referenced - **Phase II testing** (Q20–Q21): Government-furnished data availability unclear; "representative environment" scale/complexity still unspecified - **Design flexibility** (Q19, Q23): Multiple enforcement architectures acceptable; blockchain optional if alternatives meet objectives - **Deliverables** (Q25–Q26): Preferred formats (DoDAF, SysML, MBSE) and modeling/simulation depth not mandated - **Scalability, assurance levels, GenAI access, wireless constraints, fail-open/fail-closed behaviors**: All remain unanswered or unspecified

# Summary of Q&A Changes **New Answers Added:** - **Q1**: Clarified that proposers should use representative models and standard assumptions for Navy protocols in Phase I; detailed API specs and data dictionaries will likely be available in Phase II only. - **Q2**: Specified that micro-segmentation should be fine-grained at user, device, data-object/message, and compartment levels, extending to process/application level where practical, aligned with NIST/DoD guidance. - **Q3**: Confirmed proposers should address multiple common OT protocols relevant to Navy combat systems; no specific protocols mandated. - **Q4**: Clarified proposers must develop their own surrogate test environments for Phase II; Government will not provide testbeds or reference architectures. - **Q6**: Confirmed evaluation will favor edge-resident policy engines with cryptographically immutable audit logging supporting DDIL operations and reconnection reconciliation. **Key Changes:** Four previously unanswered questions (Q1, Q3, Q4, Q6) now have detailed answers setting Phase I expectations, OT protocol scope, testing responsibilities, and evaluation criteria for offline/edge capabilities.

# Summary of Q&A Changes **Key changes:** 1. **New Q1** added requesting technical specifications (data dictionaries, YAML/JSON structures, APIs, network constraints, latency thresholds) for application layer modeling 2. **Q7 received new answer** clarifying that Government seeks an **integrated concept spanning all technology areas** (authentication, micro-segmentation, AI/ML, secure data management). Single-element proposals are not fully responsive unless clearly positioned as critical integrable components within broader Zero Trust architecture. 3. **Question renumbering:** Previous Q2–Q12 shifted to Q2–Q12 with answers consolidated and reorganized for clarity. 4. **No budget/timeline answers added** — administrative questions remain redirected to DON SBIR/STTR PMO and BAA instruction.

Status changed from Pre-Release to Open

**Q&A Changes Summary:** One new question added (Q1) requesting clarification on micro-segmentation granularity levels (endpoint, user, process, file, or platform) to bound available technologies. All other questions renumbered accordingly. No previously unanswered questions received new responses. Existing answers remain unchanged.

**Q&A Changes Summary:** Added 3 new questions: Q1 addresses specific OT communication protocols (Modbus TCP, DNP3, OPC-UA, BACnet) for protocol-aware access control; Q2 clarifies whether Government provides test environment or proposers develop surrogate; Q4 asks about evaluation preference for edge-resident policy engines with cryptographic audit logging in degraded/comms-denied operations. Added answer to Q3 clarifying CMMC Level 2 self-assessment must be completed prior to award, not at submission.

Added Q1 asking whether the Government seeks an integrated concept across all technology areas or if proposals deeply advancing one element (e.g., authorization/enforcement layer) are acceptable. This question remains unanswered.

Q1 received a new answer providing six specific use cases for the Zero Trust solution, including data access control, command-and-control sharing, sensor/targeting data protection, tactical messaging, degraded environment operations, and maintenance/logistics data access limits.

**Q&A Changes Summary:** One new question added (Q1) from Bascom SW Team requesting clarification and examples of use cases for the Zero Trust solution. Previous Q&A items renumbered accordingly (Q2-Q5). No substantive answer changes to existing technical or administrative guidance.

Q1 and Q2 received new answers clarifying technical requirements: heterogeneous OS/device support required, and Zero Trust scope includes Operational Technology environments (sensors, weapons control, navigation, embedded systems). Q3 and Q4 remain unchanged.

Added 2 new topic-specific questions: Q1 on operating systems/device requirements and Q2 on Zero Trust for Operational Technology scope. Q3 received new answer directing to Phase I proposal template at navysbir.com and clarifying Supporting Documents won't be evaluated.

Added Q1 regarding document/artifact upload procedures for the application process. Q2 (previously Q1) remains unchanged, redirecting budget/timeline questions to the DON SBIR/STTR PMO and BAA instructions.