Zero trust has moved from security concept to federal mandate. Executive Order 14028 and OMB M-22-09 require federal agencies to achieve specific zero trust objectives. State and local governments are following suit, recognizing that perimeter-based security is inadequate for modern threats and distributed work.
This guide provides a comprehensive framework for zero trust implementation in government contexts, addressing the unique challenges agencies face in transforming security architecture.
Understanding Zero Trust
The Zero Trust Paradigm
Traditional security assumed trusted internal networks protected by perimeters. Once inside the perimeter, access was broadly granted. This model fails in modern environments:
Perimeter dissolution: Cloud services, remote work, and mobile access mean there is no meaningful perimeter.
Lateral movement: Attackers who breach perimeters move freely within networks. Most destructive attacks exploit internal trust.
Credential compromise: Phishing and social engineering harvest credentials that bypass perimeter controls.
Insider threats: Not all threats come from outside. Trusted insiders can misuse access.
Zero trust addresses these failures by eliminating implicit trust:
"Never trust, always verify": Every access request is evaluated regardless of network location or previous access.
Least privilege: Access is granted to specific resources based on current need, not broad entitlements.
Assume breach: Systems are designed assuming attackers may be present, limiting damage they can cause.
Zero Trust Core Principles
Identity-centric security: Identity becomes the primary security perimeter. Strong authentication and authorization for every access.
Microsegmentation: Networks divided into small segments with access controlled between them. Lateral movement is blocked.
Continuous verification: Access is not once-and-done. Continuous evaluation of user behavior, device health, and risk signals.
Comprehensive visibility: Logging, monitoring, and analytics across all access to detect anomalies.
Automation: Security decisions at speed and scale require automation. Human-in-the-loop is too slow.
The Federal Zero Trust Mandate
OMB M-22-09 Requirements
OMB established specific requirements across five pillars:
Identity:
- Agency staff use enterprise-managed identities
- Phishing-resistant MFA for agency staff
- MFA for public users where appropriate
- Internal systems don't rely on network location for authentication
Devices:
- Comprehensive device inventory
- Endpoint detection and response (EDR) on all devices
- Device compliance checked for access decisions
- Encrypted communications and storage
Networks:
- DNS queries encrypted
- HTTP traffic encrypted
- Environmental isolation for workloads
- Microsegmentation controls
Applications and workloads:
- Continuous testing and vulnerability management
- External, independent security assessments
- Dedicated application security programs
- Internet accessibility for agency applications
Data:
- Data categorization and protection
- Automated access decisions based on data classification
- Enterprise data governance
- Logging of access to sensitive data
Implementation Timeline
Agencies face defined timelines for zero trust maturity. Progress is measured against specific metrics and reported to OMB.
Zero Trust Implementation Framework
Pillar 1: Identity
Identity is the foundation of zero trust:
Enterprise identity management:
Central directory: All users (employees, contractors, partners) have enterprise-managed identities.
Identity lifecycle: Automated provisioning, updates, and deprovisioning. Orphan accounts eliminated.
Single sign-on: Users authenticate once; credentials aren't scattered across applications.
Federation: Identity works across agency boundaries where needed.
Strong authentication:
Phishing-resistant MFA: FIDO2/WebAuthn, PIV/CAC credentials. SMS and email OTP are not phishing-resistant.
Continuous authentication: Session evaluation beyond initial login. Behavioral analytics and risk signals.
Passwordless: Where possible, eliminate passwords entirely. Reduce credential theft surface.
Authorization evolution:
Attribute-based access control (ABAC): Access decisions based on user attributes, resource attributes, and context.
Just-in-time access: Elevated privileges granted on-demand for limited duration.
Separation of administration: Administrative access through separate processes and identities.
Pillar 2: Devices
Untrusted devices shouldn't access sensitive resources:
Device inventory:
Comprehensive visibility: Know every device connected to agency resources.
Asset management integration: Inventory feeds access decisions.
Unmanaged device policies: Clear policies for personal devices and BYOD.
Device health assessment:
Configuration baselines: Devices must meet security configuration standards.
Patch status: Current operating systems and applications.
Security tooling: Required security agents present and functioning.
Real-time signals: Device health checked continuously, not just at enrollment.
Endpoint detection and response (EDR):
Continuous monitoring: Detection of suspicious behavior on endpoints.
Investigation capability: Forensic tools for incident investigation.
Response automation: Automated containment of compromised devices.
Pillar 3: Networks
Network architecture must prevent lateral movement:
Encrypted communications:
TLS everywhere: All HTTP traffic encrypted. Internal and external alike.
Encrypted DNS: DNS queries encrypted (DoH or DoT).
Encrypted data at rest: Storage encryption for devices and servers.
Microsegmentation:
Application-level segmentation: Access controlled between specific applications and services.
Workload isolation: Environments separated based on sensitivity.
East-west traffic control: Lateral movement blocked by default. Explicit allow required.
Software-defined perimeter:
Application invisibility: Applications not exposed to network until authentication and authorization complete.
Connection-based access: Each access establishes new authorized connection.
Pillar 4: Applications and Workloads
Applications must be secured in development and operation:
Application security:
Secure development: Security integrated into development lifecycle.
Continuous testing: Automated security testing in CI/CD pipelines.
Vulnerability management: Known vulnerabilities identified and remediated.
Penetration testing: Regular independent security assessments.
Workload protection:
Container security: Security controls for containerized workloads.
Serverless security: Controls appropriate for serverless architectures.
Runtime protection: Detection and prevention during application execution.
Access architecture:
Internet accessibility: Applications accessible from internet (through appropriate controls) rather than relying on network location.
API security: APIs protected with authentication, authorization, and monitoring.
Pillar 5: Data
Data protection is the ultimate objective:
Data categorization:
Classification framework: Data classified by sensitivity and regulatory requirements.
Automated classification: Data discovery and classification at scale.
Labeling: Data tagged with classification for policy enforcement.
Data protection:
Encryption: Sensitive data encrypted in transit and at rest.
Access controls: Fine-grained access based on classification and user attributes.
Data loss prevention: Controls preventing inappropriate data exfiltration.
Rights management: Persistent protection traveling with data.
Data monitoring:
Access logging: Comprehensive logging of data access.
Anomaly detection: Analytics identifying unusual access patterns.
Audit capability: Ability to review data access history.
Cross-Cutting Capabilities
Visibility and analytics:
Log aggregation: Centralized collection of identity, device, network, application, and data logs.
Security analytics: SIEM and SOAR capabilities for detection and response.
User behavior analytics: Baseline and anomaly detection for user activity.
Automation and orchestration:
Policy automation: Access decisions at machine speed.
Response automation: Containment and remediation without human delay.
Security orchestration: Coordinated action across security tools.
Governance and operations:
Policy management: Central management of zero trust policies.
Continuous monitoring: Ongoing assessment of zero trust posture.
Incident response: Adapted procedures for zero trust environment.
Implementation Approach
Assessment
Before implementing, understand current state:
- Current architecture against zero trust maturity model
- Gaps requiring investment
- Dependencies and prerequisites
- Quick wins versus longer-term initiatives
Prioritization
Focus on highest-impact areas first:
- Identity typically offers best starting point—foundation for other pillars
- Protect highest-value data and applications early
- Balance quick wins with strategic investments
Phased Implementation
Zero trust is a multi-year journey:
- Phase 1: Foundation (identity strengthening, visibility, inventory)
- Phase 2: Pilot (microsegmentation for select applications, enhanced authentication)
- Phase 3: Expansion (broad implementation across pillars)
- Phase 4: Optimization (continuous improvement, automation maturity)
Key Takeaways
-
Zero trust is architecture transformation, not product purchase: Products enable zero trust; implementing zero trust requires architecture change.
-
Identity is the foundation: Until identity is strong, other pillars can't reach maturity. Start with identity.
-
Visibility before control: You can't protect what you can't see. Inventory and telemetry enable security decisions.
-
Progress over perfection: Zero trust is a journey. Make meaningful progress while moving toward comprehensive implementation.
-
Automation is essential: Zero trust at scale requires automated decisions. Manual processes can't keep pace.
Frequently Asked Questions
How long does zero trust implementation take? Full zero trust maturity typically takes 3-5 years for large agencies. Meaningful progress and risk reduction can happen much faster for priority areas.
How much does zero trust implementation cost? Costs vary enormously based on current state and scope. Agencies should budget for technology, integration, and organizational change. Zero trust can also reduce costs by simplifying network architecture.
Can we implement zero trust incrementally? Yes—phased approaches are recommended. Start with identity and priority applications; expand over time. Each phase delivers security value.
What about legacy systems that don't support modern authentication? Legacy systems can often be accessed through jump hosts, privileged access management, or proxies that enforce zero trust controls. Modernization remains important but isn't prerequisite.
How do we measure zero trust progress? CISA's Zero Trust Maturity Model provides assessment framework. Track maturity across pillars including specific capabilities and metrics.
Does zero trust work for classified systems? Zero trust principles apply to classified environments with appropriate adaptations. Implementation aligns with applicable security requirements.