The DoD's Zero Trust Strategy sets a hard deadline: by FY2027, all DoD information systems must achieve a "Target Level" zero trust implementation. That means all 90 zero trust capability activities defined in the DoD ZT Reference Architecture must be implemented — not planned, not in progress, implemented.
For programs that haven't started this work, 2027 is closer than it feels. Zero trust is an architectural transformation, not a software install. Here's what the mandate requires and how Rutagon implements it in production cloud systems.
What DoD Zero Trust Actually Requires
The DoD Zero Trust Strategy defines zero trust across 7 pillars:
- User — Identity-centric access with continuous validation
- Device — Device health and compliance as access conditions
- Application and Workload — Application-level access controls and micro-segmentation
- Data — Data tagging, classification, and access logging
- Network and Environment — Software-defined segmentation, encrypted transit
- Automation and Orchestration — Automated response to detected threats
- Visibility and Analytics — Continuous monitoring, behavioral analysis, SIEM/SOAR
The 90 capability activities are distributed across these pillars at two levels:
- Target Level (90 activities): Required by 2027 for all DoD systems
- Advanced Level (beyond Target): The frontier of zero trust maturity
The Core Zero Trust Principle in Infrastructure Terms
Zero trust's foundational principle — "never trust, always verify" — has a specific infrastructure expression in cloud environments. It means:
No implicit trust based on network location. A workload inside the perimeter gets no more inherent trust than one outside. Every access request is authenticated, authorized, and logged regardless of where it originates.
No long-lived credentials or sessions. Static API keys, long-running service account tokens, and persistent administrative sessions are incompatible with zero trust.
Continuous validation. Authentication and authorization happen at every access attempt, not once at session establishment.
Here's what that looks like in Rutagon's production systems:
Identity-First Access (User Pillar)
All human access to DoD systems flows through a SAML/OIDC federated identity provider, with MFA enforced. For CAC/PIV card users:
# Identity provider configuration for CAC/PIV authentication
resource "aws_iam_saml_provider" "dod_idp" {
name = "dod-cac-piv-idp"
saml_metadata_document = file("${path.module}/idp-metadata.xml")
}
resource "aws_iam_role" "dod_user_role" {
name = "dod-user-federated-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = {
Federated = aws_iam_saml_provider.dod_idp.arn
}
Action = "sts:AssumeRoleWithSAML"
Condition = {
StringEquals = {
"SAML:aud" = "https://signin.amazonaws-us-gov.com/saml"
}
}
}]
})
}Session duration is bounded. Privilege elevation for administrative actions is just-in-time — scoped to the specific session and automatically revoked on completion.
Service-to-Service Authentication (Application Pillar)
No microservice in a zero trust system trusts another based on network IP. Service mesh-level mutual TLS (mTLS) verifies both sides of every service-to-service call:
# Istio PeerAuthentication: require mTLS for all service communication
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT# Istio AuthorizationPolicy: only payment-service can call order-service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: order-service-authz
namespace: production
spec:
selector:
matchLabels:
app: order-service
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/payment-service"]
to:
- operation:
methods: ["POST"]
paths: ["/api/orders/*"]This policy means only payment-service with the verified service account identity can POST to order service endpoints. A compromised workload elsewhere in the cluster cannot make this call, even if it's on the same network segment.
Network Micro-Segmentation (Network Pillar)
Software-defined micro-segmentation replaces broad network trust zones:
# Security group enforcing micro-segmentation: app tier can only reach DB tier
resource "aws_security_group_rule" "app_to_db" {
type = "egress"
from_port = 5432
to_port = 5432
protocol = "tcp"
source_security_group_id = aws_security_group.db_tier.id
security_group_id = aws_security_group.app_tier.id
description = "App tier to PostgreSQL only"
}
# DB tier accepts connections only from app tier
resource "aws_security_group_rule" "db_from_app_only" {
type = "ingress"
from_port = 5432
to_port = 5432
protocol = "tcp"
source_security_group_id = aws_security_group.app_tier.id
security_group_id = aws_security_group.db_tier.id
description = "Accept PostgreSQL only from app tier"
}Each tier is isolated. A lateral movement attempt within the VPC hits a security group deny wall.
Continuous Monitoring and Behavioral Analysis (Visibility Pillar)
Zero trust requires continuous monitoring of access patterns, not just access events:
- GuardDuty: Behavioral analysis of API calls, DNS, and network traffic for anomaly detection
- CloudTrail with Insights: Unusual API activity patterns flagged in real-time
- Security Hub: Aggregated findings routed to the Security Operations function within defined SLAs
- UEBA-equivalent: CloudWatch contributor insights or third-party tooling to detect account behavior anomalies
The Path to DoD ZT Target Level
The 90 capability activities at Target Level span all 7 pillars. Programs approaching the 2027 deadline should prioritize:
FY2025 priority actions:
- User pillar: MFA enforcement universally, conditional access policies, privileged access workstation requirements
- Device pillar: Endpoint detection response (EDR) on all devices accessing the system
- Network pillar: Macro-segmentation in place, traffic encryption enforced
FY2026 priority actions:
- Application pillar: Service mesh with mTLS, micro-segmentation fully deployed
- Data pillar: CUI tagging and access logging in place
- Automation pillar: SOAR playbooks for common threat response scenarios
FY2027 completion:
- Advanced monitoring and behavioral analytics
- Data pillar full DLP implementation
- Automation pillar: automated response to all Tier 1 threats
The zero trust architecture we build today is the authorization posture that survives 2027. See our related work on eliminating long-lived credentials with zero trust and security automation capabilities.
Contact Rutagon to discuss zero trust architecture →
Frequently Asked Questions
What is the DoD's 2027 zero trust mandate?
The DoD Zero Trust Strategy requires all DoD information systems to achieve "Target Level" zero trust implementation by FY2027. Target Level encompasses all 90 zero trust capability activities defined in the DoD ZT Reference Architecture across 7 pillars: User, Device, Application and Workload, Data, Network and Environment, Automation and Orchestration, and Visibility and Analytics. Systems that don't meet the mandate may face authorization challenges and contract non-compliance.
What does "never trust, always verify" mean in cloud infrastructure?
In cloud infrastructure terms, zero trust's "never trust, always verify" means: no access is granted based on network location alone (being inside the VPC doesn't mean trust), all service-to-service communication is authenticated via mutual TLS or equivalent cryptographic verification, all access requests are authorized against explicit policies (not implicit trust), and all access events are logged and analyzed for anomalies. Every action requires fresh verification — there's no permanent trust state.
What is service mesh mTLS and why does zero trust require it?
Mutual TLS (mTLS) is a cryptographic protocol where both sides of a service-to-service connection verify each other's identity using certificates. In a service mesh (like Istio), mTLS is enforced automatically for all inter-service communication. Zero trust requires this because IP-based trust is inadequate — knowing a request came from IP 10.0.1.5 doesn't tell you if the service at that IP is legitimate or has been compromised. mTLS verifies workload identity cryptographically, not positionally.
How long does it take to implement zero trust architecture for a DoD system?
Full Target Level zero trust implementation for a DoD system typically takes 18–36 months for a system that's starting from a traditional perimeter security model. Systems with existing identity federation, cloud-native architecture, and some DevSecOps maturity can often achieve Target Level in 12–18 months. The most time-consuming elements are typically: establishing conditional access policies across all user populations, deploying service mesh for application-level mTLS, and implementing the visibility and analytics capabilities required for behavioral monitoring.
Does implementing zero trust require migrating to cloud?
No — zero trust principles apply to on-premise, hybrid, and cloud environments. However, cloud-native architectures in GovCloud provide natural starting points for several zero trust pillars: OIDC-based identity, managed Kubernetes with Istio service mesh capability, native security logging, and IaC-enforced configuration management. Cloud-native systems are often faster to bring to zero trust maturity than legacy on-premise systems that must have these capabilities retrofitted.