Table Of Contents
SC-7 (Boundary Protection) is one of the most frequently misunderstood Federal Risk and Authorization Management Program (FedRAMP) controls. It’s not because the control itself is unclear, but because years of prescriptive guidance shaped how teams thought it had to be implemented. As cloud architectures evolved, those assumptions increasingly conflicted with how modern systems are actually built. This post focuses on what SC-7 requires at its core, how FedRAMP guidance now frames acceptable approaches to isolation, and what “logical separation” means in practice across different cloud service models.
What Changed and Why
SC-7 has undergone significant transformation. In August 2025, FedRAMP published RFC-0013: SC-7 Boundary Protection Balance Improvement Release, which fundamentally changed how Cloud Service Providers (CSPs) can meet this control. Although the NIST security control language did not change, FedRAMP modified its FedRAMP Guidance to align with modern isolation technologies, not just Layer 3 subnetting. FedRAMP recognizes that with today’s technology, network and system component isolation can be achieved through other means and this should be left to the CSP to determine best approach and implement.
New to FedRAMP or looking for a broader overview? Learn how we approach FedRAMP readiness and engineering support.
Old FedRAMP Isolation Approach:
- FedRAMP Subnetting White Paper prescribed Layer 3 subnetting
- VLANs, security groups, and VPCs were explicitly stated as insufficient
- Rigid requirements didn’t align with modern cloud-native architectures
- Created friction for serverless, container-based, and microservices architectures
New FedRAMP Isolation Approach:
- Subnetting White Paper rescinded on August 8, 2025
- Allowing technology-agnostic approach to logical separation
- Focus on outcomes (effective boundary protection) rather than prescriptive or check-box methods
Why the Change?
This change was made to remove arbitrary prescriptive language from the SC-7 security control requirements and allows for the use of modern technologies to provide for logical isolation between components and component locations. This prevents restricting CSPs to only Layer 3 subnetting mechanisms and allows for technologies such as security groups, NACLs, VPCs, VLANs, etc. Without this change, many CSPs would have to undergo major network redesigns without the security benefits in order to participate in the FedRAMP space. This very thinking aligns with FedRAMP 20x in that the focus is on security outcomes.
FedRAMP 20x Key Security Indicators encourage logical separation of resources using a multi-layered approach, whereas legacy Rev 5 required Layer 3 subnetting, explicitly stating that other isolation mechanisms were simply insufficient. This was potentially blocking CSPs from leveraging modern isolation mechanisms available in cloud platforms. FedRAMP has introduced a balanced improvement approach with the publication of many balance improvement releases with the goal of bridging the gap between Rev 5 and 20x.
Learn more -> FedRAMP 20x in Plain English: What’s New, What’s Next, and Why It Matters
What SC-7 Actually Requires
At its core, SC-7 has three main parts:
SC-7(a): Monitor and control communications at:
- External managed interfaces to the system
- Key internal managed interfaces within the system
SC-7(b): Implement subnetworks or managed interfaces for all external connections.
SC-7(b): Connect to external networks or information systems only through managed interfaces with boundary protection devices.
Key term to support new approach – Managed Interface: Gateways, routers, firewalls, virtualization components, or encrypted tunnels implemented within a security architecture are considered managed interfaces. Enforcing isolation for publicly accessible components using any of the previously mentioned interface devices is key to preventing flow of unrestricted traffic to internal network components.
Key Clarifications
What “logical separation” now means: You can achieve SC-7(b) through various modern approaches:
- Layer 3 subnetting (still valid, but no longer the only option)
- Virtual Private Clouds (VPCs) configured with security groups
- Software-Defined Networking (SDN) micro segmentation
- Cloud-native network security services
- Service meshes with appropriately configured network policies
- Virtual Local Area Networks (VLANs)
Primary requirement of SC-7: Whatever isolation method is chosen, it must logically separate network resources to prevent unwanted network traversal. Publicly accessible network traffic must not be permitted to traverse to internal system components without explicit authorization.
Common system architectures and their standard methods to isolation
Traditional physical system and/or virtual machine-based:
- Layer 3 subnetting remains a perfectly valid approach
- 3-tier approach: Separate subnets for web, application, and database tiers
- Firewalls, load balancers, etc. at the perimeter and between web, application, and database tiers
- Document subnet architecture and traffic flows in network/dataflow diagrams
Container-based:
- Kubernetes networking
- Service meshes (Istio, Linkerd)
- Ingress controllers, reverse proxies
Serverless:
- VPC integration provides network-level boundary
- API gateway boundaries
- Security groups and NACLs control traffic flows
- Encryption, access mechanisms for user and components
In the realm of component isolation within the context of FedRAMP, below are two common misconceptions:
- Layer 3 subnets are a MUST. Although this was a hard requirement prior to rescinding the subnetting whitepaper, this is no longer the case, as there are many technical methods for achieving component isolation.
- Internal traffic (east/west traffic) does not need boundary protection or control; however, SC-7(a) is clear that key internal management interfaces are required to be managed/controlled. CSPs may determine which key internal management interfaces are at play here.
Final note
If you have an existing Rev 5 authorization with traditional subnetting:
- You’re not required to change to meet any additional isolation recommendations; however, it is worth considering other isolation approaches where it makes sense based on your current architecture or even future changes.
- New isolation approaches should be considered significant changes due to their impact on configurations and may introduce some level of system re-architecture.
Unsure whether your isolation model satisfies SC-7 intent?
Whether you’re using traditional subnetting, cloud-native segmentation, or a hybrid approach, the key is demonstrating effective boundary protection—not just naming the technology.
If you’d like a second set of eyes on your SC-7 implementation before it becomes an assessment discussion, we’re happy to walk through it with you.
Schedule a FedRAMP architecture review.
About the Author
