Zero-Trust Networking: CIDR as an Explicit Trust Boundary
Zero-trust architecture rejects the idea that being inside a network perimeter makes traffic trustworthy. CIDR blocks become explicit policy statements about what can talk to what, not implicit trust zones.
Traditional perimeter security assumed that traffic inside the corporate network could be trusted and traffic outside could not. A VPN or a firewall at the edge defined the boundary. Zero-trust architecture inverts this assumption: no traffic is implicitly trusted, regardless of its network location. Every connection must be authenticated, authorised, and encrypted — even between internal services. CIDR blocks become explicit policy statements, not implicit trust zones.
The Problem with Perimeter Security
When a corporate network uses 10.0.0.0/8 internally, a typical firewall rule might allow "all traffic from 10.0.0.0/8 to 10.0.0.0/8." This means any compromised internal host — a laptop infected with malware, a vendor laptop, a misconfigured server — can freely communicate with any other internal system. Lateral movement is easy. Zero-trust eliminates this flat internal network assumption.
Microsegmentation with CIDR
Zero-trust networks use microsegmentation: each workload tier gets its own CIDR block, and firewall rules explicitly enumerate which source CIDRs can reach which destination CIDRs on which ports. For example:
- Web tier (
10.0.1.0/24) can reach app tier (10.0.2.0/24) on port 8080 - App tier can reach database tier (
10.0.3.0/24) on port 5432 - Database tier cannot initiate connections to the web or app tiers
- No tier can reach any other tier on any other port
This is the CIDR-based firewall rule approach applied consistently. The CIDR assignment for each tier is the trust boundary — being in the 10.0.2.0/24 app subnet grants only the privileges that subnet has been explicitly given.
AWS Implementation: Security Groups and Subnet Boundaries
In AWS, this translates to security groups that reference specific subnet CIDRs rather than the entire VPC CIDR. Each application tier sits in its own subnet. Security group rules use subnet CIDRs (or other security group IDs) as sources, not 0.0.0.0/0 or the full VPC CIDR. Combined with VPC flow logs for traffic visibility, this gives you the observability to detect anomalies and enforce the intent of your segmentation policy.
Beyond CIDR: Identity-Based Policy
CIDR-based segmentation is a network-layer control. Pure zero-trust goes further — it authenticates workload identity at the application layer (mutual TLS, service mesh, or IAM-based policies) regardless of the source IP. An attacker who pivots into your 10.0.2.0/24 subnet cannot reach the database if database access requires a valid certificate from the application's identity authority, not just a source IP in the right range. CIDR segmentation is a necessary foundation; cryptographic identity is the roof.
Starting Point
You do not need to implement full zero-trust on day one. Start by auditing your current security group rules and identifying any that use 0.0.0.0/0 or the entire VPC CIDR as a source. Replace them with the specific subnet CIDR of the actual sources. Use the CIDR calculator to verify that each subnet is correctly bounded. Each tightened rule is a step toward an explicitly segmented network.