ESBD_511008_1779240064776_SOL_ADD_3_371-00014.pdf

ADDENDUM OF SOLICITATION

1. SOLICITATION NO.

371-00014

2. ADDENDUM NO.

3. EFFECTIVE DATE

5/19/26

4. ISSUED BY

Texas Cyber Command Chief Procurement Office 1001W North Loop Blvd Austin, Texas 78756

5. NAME AND ADDRESS OF OFFEROR

6. The above numbered solicitation is amended as set forth in Item 7. The hour and date specified for receipt of Offers is extended, is not extended.

Offers must acknowledge receipt of this addendum prior to the hour and date specified in the solicitation or as amended, by one of the following methods:

(a) By completing Items 5 and 8, and returning 3 copies of the addendum; (b) By acknowledging receipt of this addendum on each copy of the offer submitted; or (c) By separate letter or e-mail which includes a reference to the solicitation and addendum numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER.

If by virtue of this amendment you desire to change an offer already submitted, such change may be made by e-mail or letter, provided each e-mail or letter makes reference to the solicitation and this addendum, and is received prior to the opening hour and date specified.

7. DESCRIPTION OF ADDENDUM:

The purpose of this addendum is to extend the response due date and provide answers to vendors’ questions.

1. The deadline for submitting responses to the RFO has been extended to May 28, 2026 at 3:00 pm.

Responses must be submitted to txcc.procurement@txcc.texas.gov.

2. Answers to questions that were submitted to TXCC prior to the deadline of 5/6/26 are included on the following pages.

Except as provided herein, all terms and conditions of the solicitation, as heretofore changed, remain unchanged and in full force and effect.

8a. NAME AND TITLE OF SIGNER (Type or Print)

8b. OFFEROR

(Signature of Person Authorized to Sign) Date Signed mailto:txcc.procurement@txcc.texas.gov

RFO 371-00014 – Texas Networks Operational Maneuver Vendor Questions and Answers

1. What is the aggregate peak throughput (Gbps) expected for Full Content Inspection, specifically considering TLS Decryption overhead?

Answer: Answered in RFO documents, see RFO Section 3.1(g).

2. Which specific cloud environments (e.g., Azure Government, AWS GovCloud) are currently in scope for the VM-Series deployment?

Answer: TXCC is not identifying a required named cloud environment for this solicitation.

Vendors may propose deployment within TXCC-designated data centers, TXCC-designated cloud environments, or TXCC-approved hosting environments, provided all external components are fully disclosed and approved in writing by TXCC. Any vendor-owned, subcontractor-owned, or third-party hosted component that stores, processes, transmits, manages, or analyzes TXCC data must satisfy the TX-RAMP Level 2 or FedRAMP Moderate-or-higher requirement, as applicable. Vendors should not assume Azure Government, AWS GovCloud, or any other specific cloud unless that environment is proposed by the Vendor and approved by TXCC.

3. To what extent does TXCC wish to retain "Write" access to security policies versus the responsibilities assigned to the vendor’s managed team?

Answer: TXCC will retain ultimate authority over security policy, enforcement policy, exception approval, and production use of any automated response action. The Vendor may be delegated administrative or policy-write functions necessary to operate and tune the managed service, but only through TXCC-approved role-based access, MFA, least-privilege permissions, change control, audit logging, and documented runbooks.

Production policy changes, exceptions, and material enforcement changes require written TXCC approval unless a pre-approved written emergency procedure applies.

4. Are there specific state or federal regulatory requirements for the duration of evidence preservation, such as maintaining 365 days of raw logs?

Answer: Logs will be streamed to a SIEM for retention. see RFO Section 2.5.

5. What is the required SLA for notification-to-action timelines for "Analyst-Approved" response actions?

Answer: The RFO does not establish a separate notification-to-action SLA specifically for analyst-approved actions. Vendors should describe their proposed notification-to-action workflow and time targets. For pricing and operational planning, vendors should assume that once TXCC approves a response action, the Vendor must execute or escalate the approved action as soon as practicable and within the applicable severity-based response or resolution target, unless TXCC change control requires a different timeline.

6. The RFO states that the solution may be deployed within TXCC-designated data centers, cloud environments, or hosting environments approved in writing by TXCC. Can TXCC clarify whether Vendors may propose a deployment model where the solution is installed, configured, operated, and managed entirely within TXCC-designated infrastructure, data centers, network environments, or approved insertion points, without using a Vendor-owned or third-party cloud/hosting environment?

Answer: Answered in RFO documents, see RFO Section 2.2.

7. If a Vendor proposes an on-premises or TXCC-designated infrastructure deployment where TXCC provides the data center environment, network connectivity, approved insertion points, out-of-band management access, and related services, would the Vendor still be required to hold TX-RAMP Level 2 or FedRAMP Moderate authorization directly?

Answer: Answered in RFO documents, see RFO Section 10 and Appendix A Section 10.4(B)(xxiv).

8. Can TXCC clarify whether the TX-RAMP Level 2 or FedRAMP Moderate requirement applies only when the Vendor uses a Vendor-owned, subcontractor-owned, or third-party cloud/hosting environment to store, process, transmit, manage, or analyze TXCC data outside of TXCC-controlled infrastructure?

Answer: Answered in RFO documents, see RFO Section 10 and Appendix A Section 10.4(B)(xxiv).

9. If the proposed solution keeps TXCC traffic, metadata, logs, telemetry, and derived outputs within TXCC-designated infrastructure, but the Vendor provides remote administration, monitoring, maintenance, support, or managed services through TXCC-approved access methods, would that remote support model trigger the TX-RAMP/FedRAMP requirement?

Answer: The RFO does not establish a separate notification-to-action SLA specifically for analyst-approved actions. Vendors should describe their proposed notification-to-action workflow and time targets. For pricing and operational planning, vendors should assume that once TXCC approves a response action, the Vendor must execute or escalate the approved action as soon as practicable and within the applicable severity-based response or resolution target, unless TXCC change control requires a different timeline.

10. For Vendors proposing a TXCC-hosted, on-premises, appliance-based, or non-cloud architecture, what documentation should be submitted to demonstrate compliance with the deployment and security requirements? For example, should Vendors include an architecture diagram, data flow diagram, description of where TXCC data is stored and processed, remote access controls, security control narrative, patch management process, and roles/responsibilities matrix?

Answer: Answered in RFO documents, see RFO Sections 4 and 5.

11. Will TXCC please extend the due date for the references, which were due on May 5, 2026?

Answer: Responses are now due on Thursday, May 28th, 2026 @ 3:00 PM CT.

12. Document ESBD_511008_1777470842949_371-00013 - Appendix A - OpenMarket_Ts_and_Cs is downloaded under RFO 371-00014. Please confirm that the “371- 00013” is the correct Appendix A to review for RFO 371-00013.

Answer: Texas Cyber Command’s Open Market Terms and Conditions are the same across all procurements in the currently posted solicitations. However, answered in RFO documents, see Addendum 2 (Appendix A filename revised to reflect the correct solicitation number; content unchanged).

13. Section 2.1.1 references "TXCC-designated boundaries" and Section 3.1(g) requires a minimum of 30 Gbps per direction. Can TXCC clarify (a) the number of physical or logical network boundaries to be inspected, (b) the aggregate sustained throughput required across all boundaries, and (c) whether the 30 Gbps requirement applies per boundary or in aggregate? This information is critical for accurate hardware sizing and HA cluster design.

Answer: The 30 Gbps per direction requirement should be treated as the minimum required inspection capacity under the agreed acceptance test traffic profile for the initial contracted capability. TXCC is not publishing the number of physical or logical boundaries, site counts, or detailed topology in the question response. Vendors should propose a scalable HA architecture, identify whether their proposed 30 Gbps capacity is per boundary or aggregate, and provide expansion options for additional TXCC-approved sites or bandwidth tiers.

14. Section 2.1 requires the Vendor to deliver a "turnkey managed FCI solution that includes all hardware, software, licenses..." and Section 8 references a single price for the turnkey solution. Can TXCC confirm that the hardware will be owned and maintained by the Vendor throughout the contract term as part of the managed service, and that TXCC does not require ownership transfer of the equipment at any point during or after the contract term?

Please also clarify the expected disposition of equipment at end of contract (vendor removal, transition to successor vendor, or buyout option).

Answer: Answered in RFO documents, see RFO section 2.1.1(d).

15. Section 2.5 requires integration with TXCC systems including SIEM, log management, monitoring, ticketing, identity, and access management platforms. Can TXCC identify (a) the specific SIEM platform in use (e.g., Splunk, Microsoft Sentinel, IBM QRadar, Elastic), (b) the identity provider for administrative access (e.g., Microsoft Entra ID, Okta, on-premises Active Directory), and (c) any other existing security tooling the solution must integrate with at go-live?

Answer: TXCC is not identifying specific SIEM, identity provider, ticketing, or security-tool product names in the solicitation question response. Vendors must support standards-based integrations, including syslog, API, file export, and other documented exchange mechanisms, and must integrate with TXCC-approved logging, monitoring, identity, administrative authentication, ticketing, and case-management tools identified during design and implementation. Product-specific details will be provided to the awarded Vendor on a need-to-know basis.

16. Section 2.2 states that TXCC will provide rack space, power, cooling, and network connectivity. Can TXCC confirm (a) the number and geographic locations of the data centers where equipment will be deployed, (b) whether sites are TXCC-operated, co-located, or hosted by a third party, and (c) the security clearance, badging, or background check requirements for vendor personnel performing on-site installation and ongoing maintenance?

Answer: TXCC will identify deployment locations, site access procedures, and site-readiness details to the awarded Vendor during design and implementation on a need-to-know basis.

Vendors should assume TXCC-designated facilities or approved hosting environments, TXCC-coordinated site access, badging or escort requirements, and compliance with TXCC site security procedures. Background check requirements must satisfy the requirements specified in the RFO, and all personnel must be U.S. citizens housed in the United States.

17. Section 3.1(c) requires TLS inspection using TXCC-approved certificate issuance and lifecycle management. Can TXCC clarify (a) whether TXCC will provide the root Certificate Authority (CA) for inspection, or whether the Vendor is expected to operate the CA on TXCC's behalf,

(b) the expected percentage of traffic subject to TLS inspection (e.g., all HTTPS, selective high-risk categories only), and (c) any categories of traffic that must be excluded from inspection (e.g., banking, healthcare, legal)?

Answer: TXCC will retain approval authority over any certificate authority, trust anchor, key storage, certificate issuance, access controls, and lifecycle management used for TLS inspection. A Vendor may propose certificate-management services, but those services must operate under TXCC-approved controls. TLS inspection will be selective and limited to TXCC-designated traffic classes and approved use cases; vendors should not assume blanket decryption of all HTTPS traffic, except for capacity planning purposes. TXCC may exclude certain confidential, regulated, sensitive, or legally restricted traffic categories, such as privileged, PII/SPI, financial, PHI, legal, or other TXCC-designated traffic, and any payload inspection beyond approved defaults must be separately authorized in writing.

18. Section 10 states that hosted services using third-party cloud providers must be deployed in a TX-RAMP Level 2 or FedRAMP Moderate authorized environment. Can TXCC confirm whether (a) a fully on-premises solution (with no cloud-hosted management, logging, or threat intelligence components) is acceptable and exempt from TX-RAMP requirements, and (b) if hybrid architectures are permitted, whether vendor-hosted threat intelligence and signature update services (e.g., manufacturer cloud feeds) are subject to TX- RAMP/FedRAMP authorization or treated as commercially available threat intelligence?

Answer: Partially answered in RFO documents, see RFO Sections 2.2 and 10; Vendor-hosted threat-intelligence or signature-update feeds that only provide one-way security content to TXCC and do not receive, store, process, or analyze TXCC data may be treated as commercial security-update services. If any feed, cloud sandbox, telemetry service, analytics function, or support service receives TXCC data or derived outputs, the applicable TX- RAMP/FedRAMP requirements apply in addition to any TXCC-specific or other legal requirements.

19. Section 3.1(j) requires support for TXCC-approved fail-open or fail-close design by interface, traffic class, or deployment zone. Does TXCC have a preferred default posture (fail-open or fail-close) for the initial deployment, and will this decision be made by TXCC during the design phase post-award, or is the Vendor expected to recommend a posture in the proposal?

Answer: TXCC does not have a single default fail-open or fail-close posture for all interfaces, traffic classes, or deployment zones. The Vendor should recommend a fail-open/fail-close design by traffic class, interface, and zone, with risk analysis, operational impact, alerting, and rollback procedures. TXCC will approve the final posture during design and implementation. Availability-critical paths may be candidates for fail-open with compensating monitoring, while high-risk or tightly controlled paths may require fail-close or other fail-safe handling.

20. Section 3.4 requires the Vendor to develop an Acceptance Test Plan that demonstrates throughput and latency under "the agreed acceptance test traffic profile." Can TXCC provide (a) representative traffic mix characteristics (e.g., percentage HTTP/HTTPS, SMTP, DNS, file transfer), (b) typical session counts and concurrent connections, and (c) any specific test tools or methodologies TXCC requires for acceptance validation (e.g., Ixia, Spirent, customer-supplied PCAPs)?

Answer: Partially answered in RFO documents, see RFO Section 3.4; no details can be provided on traffic mix, vendors should ensure that the offered solution supports any mix of traffic at full protection up to the throughput required by the RFO.

21. The RFO scope focuses on inline network FCI, but Section 2.5 references integration with broader security tooling. Can TXCC clarify whether endpoint detection and response (EDR), endpoint management, or secure access service edge (SASE) capabilities are (a) within scope of this RFO, (b) optional add-ons that vendors may propose, or (c) outside scope and managed separately by TXCC? If within scope or optional, please indicate the approximate endpoint count.

Answer: Endpoint detection and response, endpoint management, and SASE capabilities are not part of the required scope of this RFO unless expressly included in the Vendor's proposed architecture to meet the inline FCI requirements and approved by TXCC in writing. Vendors may identify optional value added capabilities separately for evaluation clarity, but the base response should focus on managed inline FCI, telemetry, analytics, reporting, and required integrations. No endpoint count is provided for this RFO.

22. Section 8 states that "Exhibit D includes one cost for the turnkey solution" and Section 8.D requires additional cost breakdown to be itemized in the Vendor's response. Can TXCC clarify (a) whether Year 1 pricing should reflect a single annual rate equal to subsequent renewal years (with implementation costs amortized across the contract term), or whether Year 1 may be priced higher to reflect one-time deployment costs, and (b) whether annual price escalation in renewal years (e.g., 3% CPI adjustment) is permitted in the Vendor's response?

Answer: Vendors must provide the required solution price in Exhibit D and itemize additional cost breakdowns in the response. Year 1 pricing may include clearly identified one-time implementation, deployment, and acceptance costs if included in the Vendor's solution pricing. Any renewal-year pricing, escalation, CPI adjustment, or other price-change mechanism must be stated explicitly in the Vendor's response and is subject to TXCC negotiation and acceptance; no escalation is implied unless included in the final Contract and explicitly agreed to upon by TXCC.

23. Section 2.7(d) requires data retention 'only for the period authorized by TXCC.' Can TXCC specify (a) the expected log retention period (30, 90, 180, 365 days), (b) the anticipated daily log volume in GB, and (c) whether long-term archival storage (1+ year) is required for forensic or compliance purposes?

Answer: Logs will be streamed to a SIEM for retention. see RFO Section 2.5.

24. Section 10.11 of Appendix A references background and criminal history investigations. Can TXCC specify (a) the required clearance level (e.g., standard background, CJIS, fingerprint-based), (b) whether TXCC will conduct the checks or require Vendor to perform them, and

(c) the typical processing time?

Answer: Partially answered in RFO documents, see Appendix A Section 10.11; we require proof of U.S. citizenship housed in the United States for all personnel.

25. Deployment model: Would TXCC consider a cloud-delivered security architecture acceptable if all external components are fully disclosed, approved by TXCC, and hosted in a TX-RAMP Level 2 or FedRAMP Moderate-or-higher environment?

Answer: Answered in RFO documents, see RFO Sections 2.2 and 10.

26. Sensor model: Does TXCC require the proposed solution to provide physical or virtual sensors deployed by the vendor, or would TXCC also accept a solution that combines existing boundary controls, telemetry sources, and approved integrations to achieve the required visibility and analytics outcomes?

Answer: Answered in RFO documents, see RFO Section 1.2.1 (equivalent architectures and technical approaches are acceptable if they meet or exceed requirements) and RFO Section 2.5.

27. Routing scope: For the requirement to take over control of unallocated IPv4 Texas State Government IP space and provide a routing solution, does TXCC expect the vendor to operate native routing infrastructure directly, or would an approach that integrates with existing carrier, edge, or customer-managed routing components be acceptable?

Answer: TXCC allows either native routing infrastructure operated by the Vendor, integration with existing carrier/edge/customer-managed routing components, or a hybrid approach, so long as the Vendor demonstrates that the approach satisfies TXCC-approved routing, visibility, security, monitoring, and change-control requirements. The Vendor may not originate, re-home, advertise, withdraw, or alter routes for Texas address space without documented TXCC authority and an approved written change.

28. Inspection boundary: Can TXCC confirm whether the baseline scope is limited to telemetry, metadata, packet headers, flow records, routing data, and security event data, with payload/content inspection only required when separately authorized in writing?

Answer: Answered in RFO documents, see RFO Sections 1.2.1, 1.2.2, 2.3(a), and 3.1(a)-(c).

29. DPI requirement: Where the RFO references deep-packet inspection, decryption, traffic manipulation, and autonomous enforcement, are all of those functions mandatory on day one, or may vendors propose a phased approach in which certain capabilities are enabled only after TXCC approval and change control?

Answer: Answered in RFO documents, see RFO Sections 3.1, 3.2, 3.4, and 4.

30. Managed service responsibility: May the response be submitted by a prime contractor with OEM and subcontractor support, with 24x7 monitoring, maintenance, and support responsibilities shared across the team, so long as the prime remains fully accountable to

TXCC?

Answer: Answered in RFO documents, see RFO Sections 12.4, 12.5, and Appendix A Sections 10.7-10.8.

31. Scale assumptions: Can TXCC provide the expected number of sites, insertion points, bandwidth tiers, peak throughput ranges, and data retention assumptions needed for vendors to scope architecture and pricing accurately?

Answer: TXCC is not publishing exact site counts, insertion-point counts, bandwidth tiers, or retention volumes in the question response. Vendors should price the required base turnkey capability and state assumptions for site count, insertion points, throughput, storage, retention, and expansion. Vendors should also provide optional unit pricing or tiered pricing for additional TXCC-approved sites, bandwidth, and storage so TXCC can evaluate scalability.

32. Required integrations: Which integrations should be treated as mandatory at go-live versus optional/future-state for SIEM, case management, ticketing, IAM, administrative authentication, and other TXCC-approved tools?

Answer: At go-live, mandatory integrations must include export of logs, alerts, health metrics, audit records, and operational telemetry to TXCC-approved logging/SIEM and monitoring destinations; administrative authentication through TXCC-approved identity/MFA controls; and notification or ticket creation through TXCC-approved ticketing or case-management processes. Optional or future-state integrations may include bidirectional case management, SOAR workflows, EDR/SASE interoperability, custom API actions, and broader TXCC tool-stack integrations.

33. Global sensing architecture: For the requirement to leverage an existing deployed global sensing architecture, what level of proof is TXCC looking for—existing production references, architecture diagrams, operational metrics, or all of the above?

Answer: TXCC requires proof commensurate with the claim. Vendors should provide architecture diagrams, operational metrics, data sources, geographic or network coverage summaries, existing production references, evidence of contractual rights to use any partner sensing fabric, data-governance controls, and examples of how the sensing capability improves detection or reporting. Customer-identifying details may be redacted where necessary, but the Vendor must provide enough evidence for TXCC to evaluate maturity and scale.

34. Acceptance testing: Can TXCC share additional detail on the acceptance test profile, including target latency thresholds, failover criteria, traffic mix, and the specific response actions and dashboards that must be demonstrated?

Answer: The Acceptance Test Plan must demonstrate, at minimum, contracted throughput with inspection features enabled, measured latency under the approved traffic profile, HA/failover behavior, response actions, dashboards, audit logging, reporting, alerting, and integration with required destinations. TXCC does not prescribe one test tool in the question response; vendors may propose Ixia, Spirent, equivalent tools, synthetic traffic, or TXCC-approved sample data. Numeric latency targets, failover thresholds, and exact traffic mix should be finalized in the approved Acceptance Test Plan.

35. Does TXCC expect the proposed solution to cover both IT and OT environments at initial deployment, or can OT coverage be proposed as an expansion phase?

Answer: Initial deployment must focus on TXCC-designated IT/network boundaries unless

TXCC identifies specific OT environments for inclusion. Vendors must demonstrate that the proposed architecture can support OT visibility and safety-aware monitoring where approved, but OT coverage may be proposed as a phased expansion. Any OT deployment must be passive-first unless explicitly approved, must avoid disruption to safety or control processes, and must follow TXCC-approved change control.

36. For hosted components, is TXCC requiring vendor platform authorization, underlying cloud authorization, or both for TX-RAMP / FedRAMP compliance?

Answer: For hosted components that store, process, transmit, manage, or analyze TXCC data, TXCC requires both an authorized hosting environment and an authorized vendor cloud service/platform, unless TXCC's procurement and security review determines that a specific component is not a cloud computing service or does not handle TXCC data.

Underlying cloud authorization alone should not be treated as sufficient when the vendor's SaaS, managed platform, or analytics service also handles TXCC data.

37. Can TXCC clarify whether role-based access, MFA, provisioning/de-provisioning, and privileged access controls must be native in the proposed platform, or whether integration with TXCC’s existing IAM stack is acceptable?

Answer: Native controls or integration with TXCC's existing IAM stack are both acceptable if the proposed solution meets TXCC requirements for RBAC, MFA, least privilege, privileged access control, provisioning and de-provisioning, session accountability, and audit logging.

Integration with TXCC-approved identity and administrative authentication controls is preferred where feasible; the solution should not require replacement of TXCC's IAM stack unless TXCC expressly approves that approach.

38. Is TXCC open to solutions where autonomous enforcement is initially limited to advisory or reversible policy actions pending operational validation and written approval?

Answer: Yes. TXCC prefers autonomous enforcement to begin in advisory, monitor-only, simulation, or reversible low-risk modes pending operational validation and written TXCC approval. Production autonomous enforcement must require approved playbooks, risk review, logging, rollback procedures, exception handling, and change-control approval.

39. Can TXCC clarify the expected data retention period, preferred storage location, and any specific evidentiary handling or chain-of-custody standards vendors should price against?

Answer: TXCC has not established a fixed retention period or WORM/immutability requirement in the RFO for raw telemetry, parsed events, or forensic-grade artifacts.

Vendors must propose configurable retention by data type and identify hot/searchable retention, archive retention, tamper-evident or immutable storage options, storage location, deletion/erasure procedures, and cost impacts. Forensic-grade artifacts, payload content, decrypted content, and preserved files must be retained only when directed by TXCC and for the duration specified by TXCC.

40. Can TXCC provide the expected quantity of monitored sites, internet access points, boundary locations, and remote collection points that should be included in the initial pricing model?

Answer: TXCC is not publishing specific quantities of monitored sites, internet access points, boundary locations, or remote collection points in the question response. Vendors must price the solution required by the RFO and may propose additional value, added elements.

TXCC may provide more detailed quantities during negotiation or post-award design if appropriate.

41. Can TXCC provide the required or estimated throughput/bandwidth ranges by location, including any assumptions for burst traffic, encrypted traffic mix, and future growth?

Answer: The RFO establishes a minimum of 30 Gbps per direction under the agreed acceptance test traffic profile. TXCC is not publishing location-by-location throughput, burst, encrypted-traffic mix, or future-growth estimates in the question response. Vendors should state assumptions, design for scalability, and provide optional bandwidth-tier pricing for future expansion.

42. What retention period should vendors assume for logs, metadata, alerts, derived outputs, and preserved artifacts for forensics or legal review?

Answer: TXCC has not established a fixed retention period or WORM/immutability requirement in the RFO for raw telemetry, parsed events, or forensic-grade artifacts.

Vendors must propose configurable retention by data type and identify hot/searchable retention, archive retention, tamper-evident or immutable storage options, storage location, deletion/erasure procedures, and cost impacts. Forensic-grade artifacts, payload content, decrypted content, and preserved files must be retained only when directed by TXCC and for the duration specified by TXCC.

43. Should pricing include vendor-supplied storage, compute, and backhaul capacity for the full term, or does TXCC expect any of those components to be provided by TXCC or another third party?

Answer: Answered in RFO documents, see RFO Sections 2.1, 2.2.1, and 8(A).

44. For any required hardware, virtual appliances, or sensors, should vendors price those as a one-time acquisition, as a subscription/managed service, or in another pricing structure?

Answer: Answered in RFO documents, see RFO Section 8(D).

45. Does TXCC want pricing based on a single enterprise turnkey price only, or may vendors also include an itemized breakout for software, services, hardware, support, and optional components for evaluation clarity?

Answer: Answered in RFO documents, see RFO Section 8(D).

46. Should vendors include implementation services, project management, testing, training, and documentation in the base quote, or may any of those be priced as optional line items?

Answer: Answered in RFO documents, see RFO Section 2.1.1 & Section 8(D).

47. For the required 24x7 monitoring and support, should pricing assume the vendor provides a fully managed service for the entire term, or is a co-managed model with TXCC personnel acceptable?

Answer: Vendors should assume a fully managed 24x7 service with remote operations acceptable for steady-state work, supported by on-site personnel only as needed for installation, maintenance, break/fix, or TXCC-directed activities. All personnel with access to

TXCC systems, data, or facilities must be US citizens housed in the United States and meet TXCC-approved access, background, training, and confidentiality requirements.

48. Can TXCC clarify the expected staffing model for the awarded vendor, including whether on-site personnel, cleared resources, or Texas-based resources are expected during implementation or steady-state operations?

Answer: Vendors should assume a fully managed 24x7 service with remote operations acceptable for steady-state work, supported by on-site personnel only as needed for installation, maintenance, break/fix, or TXCC-directed activities. All personnel with access to TXCC systems, data, or facilities must be US citizens housed in the United States and meet TXCC-approved access, background, training, and confidentiality requirements.

49. What assumptions should vendors use for service transition and production commencement timing, especially if long-lead hardware, third-party provisioning, or circuit changes are required?

Answer: Answered in RFO documents, see RFO Sections 4, 5, and 11.4.

50. Should the quote include all third-party licensing and subscription costs required to deliver the full solution, including any OEM, cloud, data transport, or support dependencies?

Answer: Answered in RFO documents, see RFO Section 8.

51. Can TXCC confirm whether vendors should price optional expansion to additional sites or bandwidth tiers now, or only the initial deployment scope?

Answer: Vendors should price the required solution and may propose additional value, added elements.

52. Are there any required assumptions around incident response SLAs, patching obligations, maintenance windows, and uptime commitments that should be reflected as separate commercial cost drivers in Exhibit D pricing?

Answer: Answered in RFO documents, see RFO Sections 2.6, 7, and 8(A).

53. If the response includes subcontractors or OEM partners, should their costs be rolled into a single turnkey quote, or may they be identified separately for transparency so long as the prime remains accountable?

Answer: Answered in RFO documents, see RFO Section 12.4 & 12.5.

54. Can TXCC provide any additional guidance on the anticipated evaluation emphasis between technical fit and price when alternative architectures meet the requirement in different ways?

Answer: Responses will not be compared to each other, only evaluated against the solicitation requirements using the same evaluation criteria for each response.

55. Page 10. G. Take over control of unallocated IPv4 Texas State Government IP Space. What does this mean? Do you want unallocated space to be rehomed and pointed to another data center? Or is this administrative "take over" where our people help in assigning IP address.

Answer: 'Take over control of unallocated IPv4 Texas State Government IP space' means supporting TXCC in establishing, validating, monitoring, and operationalizing TXCC-approved control over designated unallocated state IPv4 resources. It does not authorize the Vendor to unilaterally re-home prefixes, originate BGP announcements, change registry records, or redirect traffic. Activities may include inventory, authority validation, routing design, route monitoring, RPKI/IRR support, source-address validation, route filtering, and execution of TXCC-approved written changes.

56. The RFO calls for the vendor to take back control of unallocated IPv4 Texas State Government IP space. What is the current announcement state of the in-scope prefixes?

Which AS number(s) currently originate them, and is TXCC requesting BGP origination from a TXCC-controlled AS or from a vendor-controlled AS? Is a target prefix list available?

Answer: ‘Take over control of unallocated IPv4 Texas State Government IP space' means supporting TXCC in establishing, validating, monitoring, and operationalizing TXCC-approved control over designated unallocated state IPv4 resources. It does not authorize the Vendor to unilaterally re-home prefixes, originate BGP announcements, change registry records, or redirect traffic. Activities may include inventory, authority validation, routing design, route monitoring, RPKI/IRR support, source-address validation, route filtering, and execution of TXCC-approved written changes. Technical details on Texas routing may be shared on a need-to-know basis during the project.

57. Could TXCC clarify what "take over control of unallocated IPv4 Texas State Government IP space" requires of the vendor? Specifically: (a) must the vendor establish administrative authority over the address space (ARIN registration, transfer, or coordinator processes), or

(b) operationally exercise authority that TXCC has already established (BGP advertisement, route-server, RPKI, source-address validation, route filtering)?

Answer: See answer to question 55.

58. Is the routing solution expected to manage allocated and in-use Texas state IPv4 space as well as unallocated space, or only the unallocated space?

Answer: Yes. The Vendor is expected to operationally support TXCC-approved control over designated address space, not independently establish legal ownership or authority over state address resources unless expressly directed by TXCC. Vendor responsibilities may include supporting ARIN/registry documentation, BGP advertisement, route-server configuration, RPKI/ROA support, source-address validation, route filtering, monitoring, and reporting under TXCC-approved written authority and change control.

59. What evidence does TXCC require to constitute "proof of authority" for an IP routing change — registry record, attorney letter, both, other?

Answer: Proof of authority must include documented TXCC authorization for the change, evidence of registry authority or control where applicable, and a TXCC-approved change record. Depending on the prefix and change type, acceptable evidence may include ARIN Org/POC records, an authorization letter from an authorized TXCC or state official, carrier authorization documentation, RPKI/ROA records, IRR records, and, where needed, confirmation from TXCC OGC.

60. The RFO requires a routing solution as part of the deliverable. Please confirm peering points, expected transit relationships, expected eBGP peer count, multi-homing requirements, and DDoS protection or scrubbing posture expectations.

Answer: Peering, transit, multi-homing, and DDoS/scrubbing details will be finalized during design and implementation. Vendors should propose a secure, resilient routing approach, identify assumptions, and describe available DDoS mitigation and route-security options.

61. What scope of routing solution does TXCC expect — overlay only (SD-WAN), backbone routing (BGP / IGP), or both? Are there existing peering relationships (commercial transit, peering exchanges, sister-agency interconnects) that must be honored?

Answer: See answer to question 60.

62. Is RPKI Origin Validation required for all outbound BGP announcements, and does TXCC have existing RPKI infrastructure or expect the vendor to deploy it?

Answer: Vendors should support RPKI Origin Validation, ROA management support, route filtering, and monitoring for all TXCC-approved outbound announcements where technically and administratively feasible. If TXCC does not already have the necessary RPKI/ROA processes for a designated prefix, the Vendor should support TXCC in establishing them under TXCC authority. Vendors should not assume authority to create or modify ROAs without TXCC written approval.

63. The objective includes mapping and enumerating Texas networks. Which Texas state government networks are in scope at award — TXCC-operated networks only, all Texas executive-branch agencies, K-12, higher education? Is active scanning permitted, or is passive enumeration the only authorized method?

Answer: The scope of award will be limited to TXCC-operated networks and other networks for which TXCC has explicit legal and operational authority. Vendors must not actively scan, enumerate, probe, or otherwise interact with networks outside TXCC-approved scope.

Passive enumeration and telemetry analysis should be the default. Active scanning may be used only with written TXCC authorization, approved rules of engagement, documented scope, time window, rate limits, notification plan, and safety controls.

64. The RFO requires the vendor to leverage an existing deployed global sensing architecture.

Is greenfield deployment disqualifying, or is partnered access to an existing global sensing fabric (vendor-operated or third-party) acceptable to satisfy this requirement? When the RFO refers to an architecture that can be "blended with the Texas state information grid," does TXCC require the prime vendor to own and operate that architecture today, or is teaming with a partner that operates it acceptable?

Answer: A greenfield-only sensing architecture does not, by itself, satisfy the requirement to demonstrate an existing deployed global sensing architecture. TXCC accepts partnered access to an existing vendor-operated or third-party sensing fabric if the prime contractor fully discloses the relationship, demonstrates contractual rights and data-governance controls, and remains accountable to TXCC. The prime need not own every component if the proposed teaming model is disclosed and compliant. The prime contractor is always responsible for any subcontractors.

65. What scale of "existing deployed" is expected — number of sensors, geographic distribution, traffic volume? Are there specific industries or geographies (state, federal, international) the sensor fleet must already cover?

Answer: This is a new indefinite-quantity capability, and TXCC is not providing historical usage or volume estimates in the response. TXCC guarantees no minimum purchases.

Vendors must price the required base capacity, state assumptions, and provide for a solution that will address additional sites, bandwidth, storage, and services.

66. Does TXCC have a target sensor count, or is the vendor designing to coverage objectives?

At sensor sites, will TXCC provide rack space, floor space, power and cooling, and network drops, or are those vendor responsibilities?

Answer: Encrypted-traffic metadata visibility is required by default. TLS decryption/inspection must be supported but will be used only for TXCC-approved traffic classes, insertion points, and use cases. If RFO 371-00013 and RFO 371-00014 are awarded to different vendors, interoperability will occur through TXCC-approved APIs, log exports, telemetry streams, and governance processes. Vendors must not assume unrestricted sharing of payloads, decrypted content, or sensitive derived outputs between solutions.

67. The RFO references monitoring across IT and OT environments. Which OT environments are in scope at award (e.g., transportation, water, electric grid, capitol facilities)? Which OT vendors and protocols are already in place at TXCC, and is a Modbus / DNP3 / EtherNet-IP / BACnet / PROFINET protocol set sufficient, or are others (DNP3 Secure Authentication, IEC 61850, S7) needed?

Answer: Vendors must provide evidence of production-scale sensing maturity, such as geographic diversity, number and type of data sources, uptime, data volume ranges, detection use cases, sector relevance, operational metrics, and references. Coverage relevant to state government, critical infrastructure, and public-sector environments will be treated as especially relevant.

68. The RFO calls for encrypted-traffic metadata analysis. Is TXCC asking for TLS metadata-only visibility, or is there an expectation of integrating with TLS-decryption infrastructure? If 371- 00013 and 371-00014 are awarded to different vendors, how does TXCC expect the two solutions to interoperate?

Answer: Partially answered in RFO documents, see RFO Sections 3.1(c) and 2.5; Before production use, autonomous enforcement capabilities must be supported by artifacts sufficient for TXCC approval, which may include playbook or rule descriptions, decision logic summaries, test results, dry-run logs, tabletop or validation results, risk assessment, rollback procedures, exception handling, audit logging, and evidence of human approval points. Interoperability among different vendors and TXCC is possible and should occur through TXCC-approved data sharing, integration, governance, and change-control processes.

69. What governance mechanism does TXCC anticipate for the §2.7 "written TXCC + General Counsel approval" workflow when payload inspection beyond defaults is requested? Is there an expected response time once a vendor or analyst submits a request?

Answer: Requests for payload inspection beyond approved defaults should be submitted through a TXCC-approved written workflow, such as a change request or incident-specific authorization request. The request should identify the mission need, traffic/data scope, duration, inspection method, data minimization controls, retention period, access controls, legal/privacy considerations, rollback plan, and approving officials.

70. For autonomous enforcement ("policy-governed, logged, reversible, and approved by TXCC before production use"), what specific pre-production approval artifacts does TXCC expect

— playbook code review, tabletop exercise results, dry-run logs, all of the above?

Answer: Partially answered in RFO documents, see RFO Sections 3.2(c) and 3.4(e); Vendor recommended autonomous enforcement capabilities are welcome. TXCC coordinates operational maneuver.

71. Are there protocols where TXCC requires only header / flow-record analysis even if the vendor's platform is technically capable of payload inspection (e.g., judicial communications, attorney-client traffic patterns)?

Answer: Yes. TXCC may designate protocols, traffic classes, users, systems, or environments for header, metadata, or flow-record analysis only, even if the platform is technically capable of payload inspection. Vendors must support policy-based exclusions and inspection limitations for confidential, sensitive, regulated, privileged, or legally protected communications as directed by TXCC.

72. Does TXCC have an existing SIEM (Splunk, Elastic, Sentinel, Sumo Logic, other) that the unified data environment must integrate with, or is the prime vendor expected to provide the SIEM as part of this contract?

Answer: TXCC is not identifying a specific SIEM product in the question response. Vendors must support integration with TXCC-approved SIEM, log-management, monitoring, ticketing, and case-management tools using supported methods such as syslog, API, file export, and other standards-based mechanisms. Vendors may propose SIEM or data-environment components only if needed to meet RFO requirements and must clearly identify them in the response.

73. What level of AI autonomy is acceptable at go-live — AI-assisted analyst prioritization, AI-assisted detection authoring, or AI-driven autonomous enforcement under policy guardrails?

Answer: At go-live, TXCC will consider any proposed AI-assisted analyst prioritization and AI-assisted detection authoring with human review. AI-driven autonomous enforcement in production is not approved by default and may be enabled only after TXCC-approved policy guardrails, validation, logging, rollback procedures, and written authorization.

Vendors must clearly distinguish advisory AI, analyst-assist AI, and autonomous enforcement capabilities in their response.

74. What data retention period does TXCC require for raw telemetry, parsed events, and forensic-grade artifacts, and is immutable / WORM storage required for any of the above?

Answer: TXCC has not established a fixed retention period or WORM/immutability requirement in the RFO for raw telemetry, parsed events, or forensic-grade artifacts.

Vendors must propose configurable retention by data type and identify hot/searchable retention, archive retention, tamper-evident or immutable storage options, storage location, deletion/erasure procedures, and cost impacts. Forensic-grade artifacts, payload content, decrypted content, and preserved files must be retained only when directed by

TXCC and for the duration specified by TXCC.

75. Does TXCC plan to provide commercial threat-intel feeds (CrowdStrike, Mandiant, Recorded

Future, ISAC feeds) for correlation, or is the prime vendor expected to source these in addition to OEM-provided intel?

Answer: Answered in RFO documents, see RFO Sections 2.1.1(c), 2.1.1(h), and 3.2(e).

76. What is the existing identity stack at TXCC (IdP, MFA, PAM, IGA), and to what extent must the new IAM and access-logging capability federate with it versus replace it?

Answer: TXCC will not disclose its existing identity stack in the question response. Vendors must support federation or integration with TXCC-approved identity, MFA, privileged access, provisioning/de-provisioning, and administrative authentication controls where feasible. The solution must not require replacement of TXCC's existing IAM stack unless TXCC expressly approves that approach.

77. What retention period and immutability requirements apply to access logs (admin, user, system)? Are there specific compliance regimes (CJIS, IRS Pub 1075, HIPAA, FERPA) the logs must support?

Answer: TXCC is not identifying its existing identity stack in the question response. Vendors must support federation or integration with TXCC-approved identity, MFA, privileged access, provisioning/de-provisioning, and administrative authentication controls where feasible. The solution must not require replacement of TXCC's existing IAM stack unless TXCC expressly approves that approach.

78. Are there constraints on cloud-delivered MFA versus on-prem MFA, and is FIPS 140-3 certification required for the MFA component?

Answer: Cloud-delivered MFA or on-premises MFA may be acceptable if the approach complies with TXCC security, data-location, TX-RAMP/FedRAMP, and access-control requirements. The RFO does not establish a blanket FIPS 140-3 requirement for MFA.

Vendors must identify any FIPS-validated cryptographic modules used by the proposed MFA solution and any limitations, dependencies, or hosted-service authorization requirements.

79. For the 48-hour critical patch SLA, is the requirement applied to OEM-issued patches, vendor-managed-platform patches, or all components in the supply chain (including third-party libraries)?

Answer: Partially answered in RFO documents, see RFO Section 2.6, which states a 72-hour critical security patch requirement rather than 48 hours; the intent is that all critical weaknesses in the solution are patched within the SLA so that the solution is not vulnerable to the exploit.

80. The RFO sets a 48-hour critical-patch window. Does this window apply to vendor-distributed signature, rule, and threat-intelligence updates as well as platform software patches, or only to the platform itself?

Answer: Partially answered in RFO documents, see RFO Section 2.6, which states a 72-hour critical security patch requirement rather than 48 hours; the intent is that all critical weaknesses in the solution are patched within a 48-hour SLA so that the solution is not vulnerable to the…