Why Government CISOs Need a Procurement-Specific Guide for Zero Trust

Government procurement of cybersecurity platforms is fundamentally different from commercial purchasing. A government CISO cannot simply evaluate a product, select a vendor, and issue a purchase order. The acquisition must navigate contract vehicles (GSA MAS, EIS, OASIS+, Polaris GWAC), comply with FAR and DFARS requirements, satisfy the Authorizing Official through the RMF process, demonstrate alignment with Executive Order 14028 and OMB M-22-09, and produce documentation that survives audit – all before a single component is deployed.

The challenge intensifies when the platform crosses network boundaries. A government procurement cross network zero trust platform must secure connectivity between classification levels, between IT and OT zones, between agency infrastructure and external partners, and between on-premises systems and cloud services. Each boundary introduces additional compliance requirements, authorization considerations, and architectural constraints that standard ZTNA procurement guides do not address.

As of early 2025, only 14% of DoD target-level Zero Trust activities had been completed. The FY 2026 NDAA allocated $15 billion for cyber modernization. Agencies are under simultaneous pressure to move faster and procure smarter. This guide provides the procurement framework that government CISOs need to acquire cross-network Zero Trust connectivity platforms through existing acquisition vehicles, with defensible requirements, structured evaluation criteria, and compliance documentation from day one.

What Procurement Vehicles Support Cross-Network Zero Trust Acquisition?

Government CISOs do not need new contracting authority to procure Zero Trust platforms. Existing vehicles already support this acquisition category – the challenge is selecting the right vehicle for the scope and timeline.

Mapping Acquisition Vehicles to Zero Trust Platform Procurement

Vehicle	Best For	Timeline	Key Considerations
GSA MAS (Multiple Award Schedule)	Single-agency procurement; defined scope; commercial products	2–6 months from requirement to award	SIN 54151S (IT Professional Services) and 518210C (Cloud and Cloud-Related IT Services); streamlined ordering procedures; best value determination required
GSA EIS (Enterprise Infrastructure Solutions)	Network infrastructure and telecommunications; multi-site deployments	6–12 months	BIC-designated; includes ZTA use cases; Task Order Unique CLINs (TUCs) for customized solutions; EIS sunsets 2032
OASIS+ / Polaris GWAC	Complex IT services; multi-domain requirements; integration-heavy deployments	4–8 months per task order	OASIS+ Phase II opened January 2026; Polaris first awards issued late 2025; suitable for deployments requiring significant integration services
Agency-specific IDIQ	Agency with existing IDIQ covering cybersecurity/network services	2–4 months per task order	Fastest path if an existing vehicle covers the scope; may limit competition
OneGov Agreement	Standardized enterprise-wide pricing; commercial software	Weeks to months	GSA negotiates pre-set terms; primarily for widely-used commercial products; expanding into cybersecurity in 2026
Direct contract (FAR Part 15)	Unique requirement; no existing vehicle covers scope	12–18 months	Full and open competition; longest timeline; most procurement overhead; use only when no existing vehicle fits

The Vehicle Selection Decision

For most government procurement cross network zero trust platform acquisitions, GSA MAS provides the fastest path for initial deployment, while EIS supports the network infrastructure components for larger multi-site rollouts. The GSA Zero Trust Architecture Technology Book explicitly maps EIS services to each pillar of the CISA Zero Trust Maturity Model, providing direct procurement-to-compliance traceability.

For defense agencies, DFARS-specific requirements (including CMMC alignment and ITAR considerations) may require agency-specific vehicles or OASIS+ task orders that incorporate cleared personnel and classified facility requirements.

What Should the Requirements Document Include?

The requirements document is where most government Zero Trust procurements succeed or fail. Requirements that are too generic attract solutions that check boxes but do not address cross-network connectivity. Requirements that are too vendor-specific risk protest. The following framework balances technical precision with competitive fairness.

Mandatory Technical Requirements

These are pass/fail criteria. A solution that does not meet every mandatory requirement is eliminated from evaluation.

Requirement Category	Specific Requirement	Why It Matters	Verification Method
Architecture	Zero inbound firewall ports on protected networks	Eliminates the primary attack vector for ransomware in government OT environments	Architectural diagram review + external scan during pilot
Architecture	On-premises deployment option with no data routing through vendor cloud infrastructure	Required for classified and sensitive environments where data cannot traverse commercial cloud	Deployment architecture review; data flow diagram verification
Architecture	Support for multiple network boundaries (IT/OT, classified/unclassified, agency/external) from a single platform	Cross-network capability is the core requirement; multiple platforms for different boundaries defeats consolidation	Architecture review + pilot demonstration across two boundary types
Identity	Per-session MFA for every access request (not just initial login)	DoD ZT framework and OMB M-22-09 require continuous authentication; VPN-level MFA is insufficient	Configuration review + pilot testing
Identity	Native PIV/CAC integration through AD/LDAP certificate chain	Federal identity infrastructure requirement; solutions requiring workarounds for PIV/CAC create compliance gaps	PIV/CAC authentication test during pilot
Identity	Named individual accounts for all users including vendors (no shared credentials)	Session attribution requires named identity; shared credentials make incident investigation impossible	Policy configuration review
Access Control	Application-level access to specific resources (not network-level access)	Least privilege principle; network-level VPN access enables lateral movement	Policy demonstration: user accesses one workstation, cannot reach others
Access Control	Per-workstation/per-application access policies with time-window and approval workflow support	Granular policy enforcement required by NIST 800-207 and DoD ZT capability outcomes	Policy configuration + scenario testing
File Sharing	Integrated bidirectional file sharing with CDR (Content Disarm & Reconstruction) scanning	Cross-network file exchange without CDR is a malware delivery vector; separate products fragment the audit trail	File transfer test with known-malicious test files
File Sharing	SMB protocol support with Kerberos/NTLM authentication and SMB Signing	Required for compatibility with existing government file sharing infrastructure	SMB share access test from standard Windows workstation
Audit	Session recording (video + keystroke capture) for all interactive sessions	Required for classified environments; critical for incident investigation and compliance evidence	Session recording playback review
Audit	Unified audit trail across all connectivity types (application access + file sharing + data transfer) with single Syslog feed	Fragmented logs from multiple products increase MTTI and create compliance gaps; consolidated audit reduces investigation time by 95%	SIEM integration test; log completeness review
Compliance	Mappable to CISA ZTMM v2.0 across all five pillars	Required for OMB M-22-09 compliance reporting	Vendor-provided compliance mapping document
Deployment	Deployable on standard VMs (no specialized hardware)	Eliminates hardware procurement cycle; enables phased deployment within existing infrastructure	Deployment architecture specification review

Desirable Technical Requirements

These are scored criteria that differentiate competitive solutions. Higher capability earns more evaluation points.

Requirement	Scoring Criteria
Device posture assessment at every session (OS, EDR, encryption, patch level)	Full posture check = 10 pts; partial = 5 pts; none = 0 pts
Approval workflow integration (ServiceNow, ITSM)	Native API integration = 10 pts; manual workflow = 5 pts; not supported = 0 pts
Support for legacy OT protocols (RDP to SCADA, SSH to engineering workstations)	Full OT support = 10 pts; IT-only = 0 pts
Deployment within 2 weeks for initial pilot (excludes full migration)	≤ 2 weeks = 10 pts; 2–4 weeks = 5 pts; > 4 weeks = 0 pts
Vendor provides phased migration methodology with rollback criteria per phase	Documented methodology = 10 pts; ad hoc approach = 0 pts

How Should the Evaluation Be Structured?

Evaluation Factors and Weighting

Government CISOs should weight evaluation factors to reflect the operational reality that cross-network connectivity platforms are security infrastructure, not commodity IT products. The recommended weighting:

Factor	Weight	Rationale
Technical Capability	40%	Does the solution meet all mandatory requirements? How does it score on desirable requirements?
Security Architecture	25%	Zero inbound ports, on-premises data path, application-level isolation, session recording – the architectural properties that determine actual security posture
Past Performance	15%	Demonstrated deployments in government and defense environments; references from agencies with similar classification and OT requirements
Management Approach	10%	Migration methodology, phased deployment plan, rollback procedures, training and knowledge transfer
Price	10%	Total cost of ownership including licensing, deployment, integration, and ongoing support – not just unit price

Why Security Architecture Warrants Separate Weighting

Most government IT procurements weight Technical Capability and Price as the primary factors. For cross-network Zero Trust platforms, this is insufficient. Two solutions may both claim “zero trust” capability, but one routes all traffic through a vendor cloud while the other keeps all traffic on-premises. One opens inbound firewall ports while the other eliminates them. One requires separate products for file sharing and session recording while the other integrates them.

These architectural differences are not feature comparisons – they are fundamental security posture decisions that determine whether classified data stays within agency-controlled infrastructure and whether the agency’s attack surface increases or decreases. Weighting architecture separately ensures these decisions are evaluated on their security merit, not buried in a feature checklist.

The Pilot Demonstration

Every government procurement cross network zero trust platform should include a pilot demonstration as part of the evaluation. The pilot validates that the solution actually delivers what the vendor claims – in the agency’s environment, with the agency’s identity infrastructure, across the agency’s network boundaries.

Pilot scope (minimum 2 weeks):

• Deploy platform infrastructure (Access Controller + Gateway) in agency test environment
• Integrate with agency Active Directory / PIV infrastructure
• Configure 5 test sessions across at least 2 network boundaries (e.g., IT-to-OT and classified-to-unclassified)
• Demonstrate per-session MFA, device posture check, and session recording
• Execute bidirectional file transfer with CDR scanning
• Run external scan to verify zero discoverable services
• Export audit trail to agency SIEM; verify log completeness
• Demonstrate rollback: remove platform, verify legacy connectivity is unaffected

Evaluation during pilot:

Pilot Criterion	Pass/Fail	Notes
Platform deploys with zero inbound firewall rules	Pass/Fail	Any inbound rule = automatic fail
PIV/CAC authentication works natively	Pass/Fail	Workarounds or third-party bridges = fail
Session recording captures complete session (video + keystroke)	Pass/Fail	Partial capture = fail
CDR scanning blocks test malware in file transfer	Pass/Fail	Any unscanned file crossing boundary = fail
External scan returns zero results	Pass/Fail	Any discoverable service = fail
Unified audit trail in SIEM contains complete session records	Pass/Fail	Missing fields or fragmented records = fail

What Compliance Documentation Should the Vendor Provide?

Government procurement requires compliance documentation at acquisition time, not after deployment. The vendor should provide the following as part of their proposal response:

Pre-Award Documentation

Document	Purpose	What to Look For
CISA ZTMM Pillar Mapping	Demonstrates how the solution addresses each of the five ZTMM pillars and cross-cutting capabilities	Coverage across all five pillars; specific capability outcomes cited; maturity stage supported for each pillar
NIST SP 800-207 Alignment	Maps solution architecture to Zero Trust Architecture tenets	Per-request access decisions; continuous verification; least privilege enforcement; data-plane/control-plane separation
IEC 62443 FR Mapping (if OT applicable)	Maps solution to Foundational Requirements for OT security	FR1-FR7 coverage; specification of which security levels (SL1-SL4) the solution supports
Data Flow Diagram	Shows exactly where data travels during all session types	Verification that no data routes through vendor-controlled infrastructure for classified use cases
Architecture Security Assessment	Independent or vendor-provided assessment of the platform’s security architecture	Focus on attack surface analysis: inbound ports, internet-facing components, authentication chain, encryption standards
Supply Chain Risk Management (SCRM) documentation	Addresses EO 14028 requirements for software supply chain security	SBOM availability; secure development practices; vulnerability disclosure process; origin of components

Post-Award / Pre-Deployment Documentation

Document	Purpose
Deployment architecture for agency environment	Site-specific architecture showing component placement, network boundaries, and data flows
Security assessment report (SAR) for RMF	Supports the AO’s authorization decision; maps platform to applicable NIST 800-53 controls
Ongoing assessment plan	Defines how the platform will be continuously monitored and assessed per FISMA requirements

What Are the Common Procurement Mistakes – and How to Avoid Them?

Mistake 1: Procuring ZTNA as a Point Solution

What goes wrong: The agency procures a ZTNA solution for application access, then discovers it does not handle file sharing across classification boundaries. A separate procurement for an SMB proxy follows. Then another for session recording. The result is the same multi-vendor patchwork the agency was trying to escape – just with newer products.

How to avoid it: The requirements document must specify cross-network connectivity as the scope – application access AND file sharing AND session recording AND unified audit – in a single platform. The evaluation criteria must penalize solutions that require supplementary products to achieve full coverage. Solutions like truePass Gravity that integrate all three layers (reverse-access infrastructure, SMB Proxy with CDR, and Zero Trust application access) in a single platform should score higher than architectures requiring 2–3 separate procurements.

Mistake 2: Specifying Cloud-Delivered ZTNA Without Data Path Analysis

What goes wrong: The agency selects a cloud-delivered ZTNA solution based on FedRAMP authorization and feature comparison, without analyzing where data actually travels. After deployment, the compliance team discovers that classified or CUI data is routing through the vendor’s commercial cloud infrastructure – violating data sovereignty requirements.

How to avoid it: The requirements document must include a mandatory data flow analysis. For any environment handling classified, CUI, ITAR-controlled, or law enforcement sensitive data, the requirements should specify on-premises deployment with no vendor cloud data path. The truePass platform operates entirely within agency-controlled infrastructure – all traffic stays on-premises with zero dependency on external cloud services.

Mistake 3: Accepting Network-Level Access as “Zero Trust”

What goes wrong: The vendor claims “Zero Trust” but the solution provides VPN-like network-level access after authentication. Users can reach any device on the network segment – not just their authorized resource. The agency has a “Zero Trust” product in the ATO package but network-level lateral movement is still possible.

How to avoid it: The pilot demonstration must include a lateral movement test: after authenticating to one resource, the evaluator attempts to reach an adjacent resource on the same network. If the attempt succeeds, the solution does not provide application-level isolation and does not meet Zero Trust least-privilege requirements.

Mistake 4: Not Including Legacy Gateway Decommission in the SOW

What goes wrong: The agency deploys the new platform but the legacy VPN, jump server, and SMB proxy remain operational because the SOW did not include decommission planning. The attack surface increases – the agency now has the legacy stack plus the new platform.

How to avoid it: The SOW must include phased legacy gateway replacement with explicit decommission milestones, external scan validation at each milestone, and success criteria that include the removal of legacy inbound firewall rules.

Mistake 5: Evaluating on Price Per User Without Total Cost of Ownership

What goes wrong: The agency selects the lowest per-user license cost, then discovers that the solution requires separate products for file sharing ($X), session recording ($Y), CDR scanning ($Z), and integration services to connect them all. The total cost exceeds the higher-priced consolidated platform.

How to avoid it: The price evaluation must require vendors to quote the total cost of ownership for all connectivity types specified in the requirements – not just application access. The cost comparison table should include:

Cost Element	Vendor A (Consolidated)	Vendor B (Point Solution + Supplements)
Platform license	Quoted	Quoted
File sharing / SMB proxy	Included	Separate procurement required: $____
Session recording	Included	Separate procurement required: $____
CDR scanning	Included	Separate procurement required: $____
Integration services (connecting 3+ products)	Not required	Required: $____
SIEM integration (number of log sources)	1 feed	3–4 feeds: integration labor $____
Annual maintenance (all products)	Single contract	Multiple contracts: $____
Estimated vendor count	1	3–4

What KPIs Should the CISO Track After Procurement?

Procurement is not the finish line – it is the starting point. The government CISO must establish measurable KPIs for OT connectivity security from day one to demonstrate that the investment is producing results:

KPI	Baseline (Legacy Stack)	Target (Post-Deployment)	Measurement Frequency
Inbound Port Exposure Index	Document before deployment	0	Monthly (firewall audit + external scan)
Connectivity Consolidation Ratio	Products ÷ connectivity types	≤ 0.4	Quarterly
Session Attribution Coverage	% sessions with full identity + recording	95%+	Monthly
Mean Time to Investigate (MTTI-OT)	Hours per session reconstruction	< 15 minutes	Per incident
Zero Trust Coverage	% sessions meeting all 5 ZT criteria	90%+	Monthly

These KPIs provide the evidence base for the agency’s next budget cycle, ATO renewal, and IG audit response.

What Does the Procurement Timeline Look Like End-to-End?

Phase	Timeline	Key Activities	Deliverables
Requirements Development	Weeks 1–4	Define cross-network scope; map to CISA ZTMM; draft mandatory/desirable requirements; identify acquisition vehicle	Requirements document; acquisition strategy memo
Market Research	Weeks 5–8	Issue RFI; conduct vendor demonstrations; analyze responses against requirements; validate vehicle selection	Market research report; vendor shortlist
Solicitation	Weeks 9–16	Issue RFQ/RFP through selected vehicle; evaluate proposals; conduct pilot demonstrations	Evaluation report; pilot results
Award	Weeks 17–20	Best value determination; award notification; debrief unsuccessful offerors	Contract award; SOW with decommission milestones
Deployment Phase 1	Weeks 21–28	Deploy platform; integrate identity; migrate interactive access; decommission VPN + jump server	Phase 1 completion; external scan verification
Deployment Phase 2	Weeks 29–36	Migrate file sharing; CDR validation; one-way flow evaluation	Phase 2 completion; full audit trail operational
ATO / Compliance	Weeks 37–40	RMF security assessment; ATO documentation; compliance mapping; KPI baseline	ATO decision; KPI dashboard operational

Total timeline from requirements to operational ATO: approximately 10 months. For agencies using existing IDIQ vehicles with pre-competed task orders, the procurement phases (Weeks 1–20) can compress to 8–10 weeks.

Conclusion

Government procurement cross network zero trust platforms is not a standard IT acquisition. It requires procurement-specific planning that addresses classification boundaries, federal identity infrastructure, on-premises data sovereignty, legacy gateway decommission, and compliance documentation that satisfies both the acquisition authority and the Authorizing Official.

The framework in this guide – vehicle selection, requirements template, evaluation criteria with architectural weighting, mandatory pilot demonstration, compliance documentation requirements, TCO-based price evaluation, and post-procurement KPIs – provides the structure that government CISOs need to execute this acquisition defensibly and efficiently.

The mandate is clear: EO 14028, OMB M-22-09, DTM 25-003, and the CISA ZTMM all require Zero Trust implementation. The budget is allocated: $15 billion in the FY 2026 NDAA. The acquisition vehicles exist: GSA MAS, EIS, OASIS+, Polaris. What remains is the procurement execution – and the agency that starts with the right requirements, the right evaluation structure, and the right deployment partner for government and defense environments will reach operational Zero Trust faster than the agency that procures point solutions and discovers the gaps after award.