Designing Networks With DoD IL5 in Mind: Campus, Data Center, IT, and OT Security

A network is not "Department of Defense (DoD) Impact Level 5 (IL5) compliant" by itself. A network can, however, be designed to support a mission system categorized at IL5 or pursuing a DoD IL5 authorization. That distinction matters. IL5 is about the mission system, the authorization boundary, the data being protected, the controls that are inherited or implemented, and the evidence the environment can produce.

The practical design question is this: if Controlled Unclassified Information (CUI) or National Security System (NSS) mission data can move through campus, data center, cloud, information technology (IT), and operational technology (OT) environments, can the network restrict that movement, produce evidence of what happened, survive failure, and support an authorization conversation without relying on undocumented assumptions?

Design principle: start with data boundaries, authorization boundaries, identity, segmentation, logging, encryption, and evidence. Do not select a network fabric before the control mapping, boundaries, and evidence model are clear.

What IL5 Means For Network Design

The Defense Information Systems Agency (DISA) maintains the DoD Cloud Computing Security Requirements Guide (CC SRG), which is used to assess cloud service offerings (CSOs) and support DoD Provisional Authorizations (PAs). IL5 applies to CUI that needs stronger protection than Impact Level 4 and to some NSS use cases, with the Authorizing Official (AO) making the final impact-level determination. Public cloud provider summaries, such as Microsoft Azure's IL5 overview, are useful implementation context, but the controlling authority is the applicable DoD guidance, authorization package, mission owner, and AO decision. FedRAMP+ means DoD-specific additions and requirements beyond the Federal Risk and Authorization Management Program (FedRAMP) baseline, including location, separation, and personnel-access considerations.

That does not mean a campus fabric, data center fabric, firewall pair, or cloud region is automatically enough. A DoD PA for a cloud service provider's offering does not give the mission system its Authorization to Operate (ATO). The mission owner still has to define the boundary, select in-scope services, configure the tenant, control identity, protect routes and keys, harden workloads, monitor activity, respond to incidents, and maintain the System Security Plan (SSP), Security Assessment Plan (SAP), Security Assessment Report (SAR), and Plan of Action and Milestones (POA&M) where applicable.

Interactive authorization flow

DoD PA Supports The Mission ATO; It Does Not Replace It

Open each step to separate provider authorization, mission boundary design, connection approval, and operating authorization.

Step 1: Provider CSO PA

A DoD PA is tied to a specific CSO, service scope, region, feature set, and support path. It is inherited context for the mission system, not the mission authorization itself.

Step 2: Mission boundary and controls

The mission owner and system team define data flows, users, administrators, routes, logging, backup, support artifacts, identity, encryption, and continuous-monitoring evidence.

Step 3: ATO decision

The AO makes the risk decision for the assessed mission boundary using the authorization package, inherited controls, implemented controls, findings, exceptions, and operating evidence.

Scope And Language Guardrails

The safest language is precise language. Say the network is designed to support an IL5 authorization boundary, not that the network is IL5 certified. Say a cloud service has a DoD PA only for the specific CSO, region, feature set, and support path in scope. Say a control is implemented only when there is configuration, monitoring, ownership, and evidence that the control is operating.

Do Not Claim	Use This Instead	Why It Matters
The network is IL5 compliant.	The network is designed to support a mission system pursuing or operating under IL5 authorization.	The AO authorizes a system boundary, not a generic topology.
FedRAMP High equals IL5.	FedRAMP High is part of the assessment basis; DoD-specific requirements and scope still matter.	FedRAMP High does not automatically satisfy DoD IL5 expectations.
Private connectivity means controlled data movement.	Private connectivity still needs routing policy, inspection, identity, logging, and approval.	A private path can still leak routes, bypass inspection, or move CUI to the wrong place.
STIG compliance means the environment is secure.	Security Technical Implementation Guide (STIG) results are one evidence source in a broader control set.	Hardening does not replace monitoring, incident response, segmentation, or recovery.
FIPS-compatible encryption is enough.	Use Federal Information Processing Standards (FIPS)-validated modules where policy requires them and document configuration responsibility.	Compatibility language is not the same as validated cryptographic module use.

Enterprise Ownership Model

An IL5-aware network crosses organizational lines. The mission owner owns mission risk and data handling. The AO owns the authorization decision. The Information System Security Manager (ISSM) and Information System Security Officer (ISSO) own control execution and assessment readiness with the system team. Network operations owns forwarding, segmentation, wireless, routing, and availability. The Security Operations Center (SOC) owns monitoring and response. Cloud platform teams own tenant guardrails and service scope. OT owners own safety, availability, vendor access, and change windows. Contracting and legal own data-handling language, support terms, subcontractor flowdown, and incident-reporting obligations.

Owner	Design Responsibility	Security Concern	Evidence Expected
Mission owner / AO	Data categorization, impact level, authorization boundary, accepted risk.	Wrong boundary or unapproved inherited-control assumption.	Authorization package, risk decisions, boundary diagram.
ISSM / ISSO	Control mapping, assessment readiness, POA&M tracking, continuous monitoring.	Controls implemented without evidence or owner.	SSP, control traceability, assessment artifacts, exceptions.
Network operations	Campus, data center, cloud routing, segmentation, firewalls, telemetry paths.	Route leaks, unmanaged paths, flat segments, missing deny logs.	Route tables, firewall rules, segmentation matrix, failover tests.
SOC / incident team	Detection content, escalation workflow, log retention, incident evidence.	Logs collected but not actionable or retained.	SIEM queries, alerts, runbooks, incident tickets, tabletop results.
OT owner	Industrial access, vendor sessions, maintenance windows, safety constraints.	IT controls disrupting process safety or availability.	Industrial demilitarized zone policy, vendor logs, passive-monitoring records.
Contracting / vendor owner	CUI handling, support access, subcontractor flowdown, data return, exit terms.	Support or managed service path outside the boundary.	Contract clauses, service scope, support personnel terms, incident-reporting terms.

Interactive ownership swimlane

Who Owns Each Part Of The Boundary

Use the swimlane to check that each lifecycle stage has an accountable owner and evidence artifact.

How to read the swimlane

A blank cell is not a free pass; it means that owner is not normally accountable for that activity. The review question is whether every stage has a named owner, evidence artifact, and escalation path.

Reference Architecture

The reference model below is intentionally network-centric. It does not replace the Risk Management Framework (RMF), National Institute of Standards and Technology (NIST) controls, agency policy, or AO direction. It shows the engineering areas that must be explicit before an IL5 design conversation is credible.

Diagram and table abbreviations include Network Access Control (NAC), Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Authentication, Authorization, and Accounting (AAA), security group tags (SGTs), Data Loss Prevention (DLP), Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA), Programmable Logic Controller (PLC), Ethernet VPN (EVPN), Virtual Extensible LAN (VXLAN), virtual routing and forwarding (VRF), VXLAN network identifier (VNI), intrusion detection system (IDS), intrusion prevention system (IPS), Identity and Access Management (IAM), Multi-Factor Authentication (MFA), Privileged Access Management (PAM), Public Key Infrastructure (PKI), Domain Name System (DNS), Role-Based Access Control (RBAC), Security Information and Event Management (SIEM), Security Orchestration, Automation, and Response (SOAR), Network Operations Center (NOC), Security Impact Analysis (SIA), and Architecture Decision Record (ADR).

Architecture diagram

IL5-Aware Network Reference Model

The network supports the authorization boundary by separating user, workload, OT, management, security, logging, and cloud paths.

Interactive Topology Explorer

Topology is worth adding when it explains enforcement, routing, failure domains, and evidence collection. The diagrams below are intentionally scenario-based: each one highlights a design question the network team must be able to answer during architecture review and operations.

Interactive topology review

Where Traffic Flows, Where Policy Fires, Where Evidence Lands

Open each topology and read it as a path review: source, route, enforcement point, control owner, and proof.

Topology 1: Campus user to mission application

Use this when: reviewing campus segmentation, wireless access, user-to-application policy, and whether identity actually drives network access.

Topology 2: Data center fabric with inspection and route-control

Use this when: reviewing EVPN/VXLAN, route leaking, firewall service insertion, management isolation, backup isolation, and cloud boundary handoff.

Topology 3: IT, OT, cloud, and partner boundary

Use this when: reviewing hybrid scope, partner links, cloud service paths, support data, OT safety boundaries, and whether logs or tickets carry CUI.

Start With Data And Authorization Boundaries

IL5-aware design starts before the first virtual routing and forwarding (VRF) instance or firewall rule. Identify where CUI is created, processed, stored, transmitted, displayed, logged, backed up, exported, and supported. Logs, packet captures, screenshots, help desk tickets, monitoring data, backup copies, and analytics exports can pull systems into scope even when the primary application path looks clean.

Boundary Question	Network Design Response	Evidence To Keep
Where can CUI flow?	Document approved paths between campus, data center, OT edge, cloud, partners, security tools, backups, and support systems.	Data-flow diagram, firewall policy, route table, proxy policy, approved service list.
Who can administer the environment?	Separate management paths from user traffic; require identity, privileged access, session logging, and break-glass approval.	Identity and Access Management (IAM) export, Multi-Factor Authentication (MFA) policy, Privileged Access Management (PAM) log, jump-host recording.
Which services are in scope?	Use only authorized regions, services, managed features, images, marketplace components, and support paths for the intended boundary.	CSO service list, region list, FedRAMP package, DoD PA letter where available, architecture decision record.
Where does inspection occur?	Force north-south and selected east-west paths through firewalls, intrusion detection system (IDS), intrusion prevention system (IPS), proxies, or service gateways.	Firewall rules, IDS/IPS policy, denied-flow tests, packet capture, Security Information and Event Management (SIEM) event IDs.
What must survive failure?	Define failure domains for access closets, spines, leaves, borders, firewalls, identity, Domain Name System (DNS), time, logging, and backup paths.	Failover test results, Recovery Time Objective (RTO), Recovery Point Objective (RPO), incident runbook.

Scope diagram

Authorization Boundary And Data Scope Map

CUI scope follows data, logs, support paths, backups, and exports. The primary app path is only one part of the boundary.

Threat Model For The Boundary

A useful IL5-aware network design starts with explicit failure and abuse cases. The question is not only whether the normal path works; it is whether the design constrains stolen credentials, mistaken route advertisements, vendor access, cloud service drift, support artifacts, and recovery operations.

Concern	Likely Path	Network Control	Security Control	Evidence
Credential theft	Compromised user or administrator attempts lateral movement.	Management VRF, jump host, firewall policy, device role segmentation.	MFA, PAM, AAA, session recording, access review.	PAM record, denied firewall log, AAA log, SIEM alert.
Route leak	Wrong VRF import/export, cloud route table, partner advertisement, or default route.	Prefix filters, route maps, route target review, max-prefix, explicit default-route ownership.	Change review, peer review, rollback test.	Routing table export, route policy, denied-flow test.
Data exfiltration	DNS tunnel, software-as-a-service (SaaS) upload, cloud storage export, unmanaged proxy, support ticket.	Resolver enforcement, egress firewall, proxy policy, approved destination list.	DLP, DNS analytics, data owner approval, contract terms.	DLP alert, DNS log, proxy log, destination approval.
Cloud scope drift	New service, feature, marketplace image, region, support path, or logging target enters use.	Private endpoint inventory, route filters, egress inspection, service-policy guardrails.	CSO scope review, AO/ISSM threshold decision, configuration policy.	Service inventory, policy export, architecture decision record.
OT pivot	Enterprise user, cloud workload, vendor session, or compromised tool tries to reach a controller.	Industrial DMZ, brokered telemetry, no direct routing, passive monitoring.	OT owner approval, vendor access workflow, maintenance windows.	Firewall deny log, vendor session record, passive sensor evidence.
Evidence tampering	Attacker or administrator deletes logs, changes configs, or alters backup history.	Separated log path, immutable backup target, restricted management path.	SIEM retention, privileged access approval, configuration integrity.	Retention proof, config diff, backup immutability check.

Zero Trust And Control Crosswalk

Zero Trust Architecture is not a separate overlay placed next to the network. For an IL5-aware design, Zero Trust principles have to show up in campus access, routing, segmentation, inspection, identity, telemetry, recovery, and change control.

Zero Trust / Control Goal	Network Implementation	Operational Evidence	Review Question
Verify explicitly	NAC, EAP-TLS, device certificates, identity-aware access, admin MFA.	Authentication logs, device posture, certificate inventory, PAM sessions.	Can we show who, what device, what role, and what path was used?
Use least privilege	VRFs, VNIs, SGTs, firewall zones, route filters, default-deny inter-zone policy.	Policy matrix, route table, denied-flow tests, rule reviews.	Can each allowed path be tied to a mission owner and expiration or review cycle?
Assume breach	East-west inspection, microsegmentation, no broad campus trust, protected management plane.	Firewall logs, flow records, IDS/IPS events, lateral-movement tests.	Can a compromised user or workload move laterally without hitting enforcement?
Continuously monitor	Flow telemetry, DNS logs, route-change logging, configuration drift, SIEM correlation.	SIEM queries, alert records, retention proof, drift reports.	Can operations detect boundary changes, denied flows, and suspicious routes quickly?
Protect data paths	Approved egress, cloud service scope, DLP, encryption, backup isolation, support artifact controls.	DLP events, key inventory, backup access review, support workflow.	Can CUI leave through logs, tickets, backups, packet captures, or exports?
Recover deliberately	Immutable backups, tested restore, failover paths that preserve policy, break-glass workflow.	Restore test, failover report, break-glass record, post-incident review.	Can the environment recover without reopening broad access?

Campus Fabric Design

Campus networks are where users, devices, wireless clients, printers, cameras, phones, building systems, visitors, and administrators attach. The mistake is treating campus segmentation as a virtual local area network (VLAN) exercise. VLANs attach devices; they do not by themselves demonstrate least privilege, identify users, or produce sufficient audit evidence.

• Use Network Access Control (NAC), 802.1X, Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), device certificates, posture, profiling, and fallback rules to classify endpoints before they reach sensitive paths.
• Treat Media Access Control (MAC) Authentication Bypass (MAB) as an exception path, not a normal path. MAB entries need owners, device type, allowed destination set, review date, and a quarantine behavior when the device does not match expectations.
• Separate user, privileged admin, guest, contractor, voice, printer, camera, Internet of Things (IoT), OT, security tooling, and management access where risk requires it.
• Use VRFs, virtual networks (VNs), group-based policy tags such as security group tags (SGTs), firewall zones, or microsegmentation to express policy. Do not let addressing convenience become the security model.
• Require default-deny or default-restrict inter-segment behavior. Every allow rule should have a source, destination, protocol, owner, business reason, expiration or review date, and log requirement.
• Keep Dynamic Host Configuration Protocol (DHCP), DNS, Network Time Protocol (NTP), Public Key Infrastructure (PKI), identity, logging, backup, and monitoring in named service segments with explicit access policy.
• Use access-layer protections such as DHCP snooping, Dynamic Address Resolution Protocol (ARP) Inspection, Internet Protocol version 6 (IPv6) Router Advertisement (RA) Guard, storm control, port security where appropriate, and switch management hardening.
• Restrict wireless access by device type, user role, posture, and data-handling need. Guest wireless should not share a policy domain with managed devices.
• Define fail-open and fail-closed behavior for NAC, identity, certificate, and controller outages before production. A secure design still needs a mission-approved degraded mode.
• Do not allow broad direct campus access to data center or cloud workloads because the user is "inside" the building. Zero Trust Architecture (ZTA) assumes no implicit trust based only on network location.

Data Center Fabric Design

Data center fabrics are attractive because they make scale, mobility, and automation easier. For IL5-aware environments, the fabric must also make boundaries explicit. A leaf-spine design with Ethernet VPN (EVPN), Virtual Extensible LAN (VXLAN), VRFs, and VXLAN network identifiers (VNIs) can be useful, but only if route leaking, service insertion, east-west inspection, and operations are designed deliberately.

• Keep the routed underlay simple and predictable: stable addressing, Equal-Cost Multipath (ECMP), explicit maximum transmission unit (MTU), fast convergence, and no user or workload policy hidden in transport links.
• Use overlays for tenant, mission, management, storage, backup, security-tooling, and shared-services separation. Name each VRF or VNI after its policy purpose, not only its application owner.
• Constrain route leaking to controlled points. Every leak should have a policy owner, route filter, log source, rollback plan, and validation test.
• Design service insertion deliberately. If a service leaf, firewall cluster, load balancer, or proxy is the enforcement point, test the normal path, failover path, asymmetric path, and bypass path.
• Be explicit about EVPN Type-5 route advertisement, route targets, import and export policy, summarization, default-route ownership, and blackhole routes for denied destinations.
• Avoid stretching Layer 2 across data centers unless the application requirement is documented and the failure mode is accepted. Using Layer 2 extension to compensate for application constraints usually creates audit and recovery problems.
• Do not let distributed anycast gateways bypass inspection. If workloads can route locally on a leaf, decide which flows are enforced at the host, distributed firewall, fabric policy, service leaf, or physical firewall.
• Isolate management, console, backup, storage, key-management, and telemetry paths. These paths are often more sensitive than production user traffic because they can administer or reconstruct the environment.

Routing And Route-Control

Routing is one of the easiest places to accidentally defeat segmentation. The authorization boundary should have a routing contract: which prefixes exist, which VRFs can exchange them, which devices can advertise them, which paths are inspected, and which logs show the policy was followed.

Route-Control Surface	Security Concern	Required Control	Validation Evidence
Underlay routing	Workload policy hidden in transport links.	Keep user and workload routes out of the underlay; limit underlay to infrastructure reachability.	Routing table export, prefix inventory, underlay peer review.
EVPN route targets	Wrong import/export policy joins separated segments.	Review route targets and import/export policy per VRF/VNI.	EVPN table, route-target matrix, denied route-leak test.
Border Gateway Protocol (BGP) peers	Route injection, accidental transit, or partner leak.	Use prefix lists, max-prefix, peer authentication where supported, route maps, and explicit local preference policy.	BGP neighbor config, policy hit counters, route dampening or withdrawal test.
Default routes	Unexpected internet, cloud, or partner egress.	Assign default-route ownership and force egress through approved inspection.	Traceroute, firewall logs, cloud route table, egress deny test.
Cloud connectivity	Private link bypasses inspection or expands scope.	Filter routes, constrain DNS, inspect egress, and confirm service/region scope.	Cloud routing export, private endpoint inventory, DNS query logs.
Rollback routing	Emergency rollback reopens broad paths.	Predefine rollback routes and blocked-state tests.	Change record, rollback test, post-rollback denied-flow evidence.

Segmentation Policy Matrix

The policy matrix should be structured enough to review. If a path cannot be written in a table with owner, enforcement point, log source, and validation test, it is not ready for an IL5-aware boundary.

Source Zone	Identity / Device Class	Destination Zone	Protocol / Port	Enforcement Point	Inspection	Log Source	Owner	Review	Validation Test
Managed campus	Cleared user, compliant device	Mission app	Hypertext Transfer Protocol Secure (HTTPS) / 443	Firewall plus app policy	Required	Firewall, proxy, identity	App owner	Quarterly	Allow only approved role.
Guest	Unmanaged user	Internal CUI segment	Any	Campus firewall	Deny	Firewall deny log	Network security	Continuous	Guest-to-CUI deny.
Printer	MAB exception	Print service	Internet Printing Protocol (IPP) / 631	Access policy plus firewall	Limited	NAC, firewall	Endpoint owner	Monthly	Printer cannot initiate lateral access.
OT DMZ	Telemetry broker	Data center historian	Approved application port	Industrial firewall	Required	Firewall, passive sensor	OT owner	Per change	No direct controller path.
Admin network	PAM-approved admin	Network devices	Secure Shell (SSH), HTTPS, Terminal Access Controller Access-Control System Plus (TACACS+)	Jump host and management firewall	Session recording	PAM, AAA, SIEM	Network operations	Monthly	Admin path requires MFA and approval.

IT And OT Security

IT and OT should not be collapsed into one policy model. OT environments may include Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA), programmable controllers, sensors, safety systems, vendor support paths, and legacy protocols that cannot tolerate aggressive scanning or frequent change. The goal is not to force OT systems into an IT-style change cadence. The goal is to control what crosses the boundary.

Domain	Design Pattern	Security Requirement	Validation Evidence
Campus IT	NAC, role-based segmentation, wireless policy, managed endpoint posture.	Users and devices reach only approved apps and services.	Endpoint session logs, SGT or policy assignment, denied-flow tests.
Data center IT	VRF/VNI separation, firewalls, microsegmentation, service insertion.	Mission workloads, management, backup, and security tools are isolated by policy.	Route tables, firewall logs, workload policy, change tickets.
OT edge	Industrial demilitarized zone (DMZ), telemetry broker, passive monitoring, vendor access gateway.	Controllers are not directly reachable from user or cloud networks.	Boundary firewall logs, one-way or brokered telemetry design, vendor session records.
Cloud boundary	Private connectivity, service scope review, route filtering, identity federation, egress inspection.	Only approved services, regions, and paths are used for the mission boundary.	Service inventory, route policy, cloud audit logs, FedRAMP/DoD scope artifacts.
Security operations	SIEM, Security Orchestration, Automation, and Response (SOAR), immutable log storage, incident workflow.	Authentication, policy changes, denied flows, privileged access, and boundary crossings are visible.	Log-retention proof, correlation rules, alert records, incident tabletop output.

Boundary diagram

IT/OT Boundary Protection Model

Enterprise users and cloud tools should not directly reach controllers. Broker access through an industrial DMZ with logging and safety-owner approval.

Security Control Stack

An IL5-aware network design should cover every major security surface, not only firewalls. The network needs identity, segmentation, encryption, management-plane protection, hardening, vulnerability management, monitoring, backup, and change-control evidence.

• Identity and access: require IAM, MFA, PAM, Authentication, Authorization, and Accounting (AAA), Terminal Access Controller Access-Control System Plus (TACACS+) or Remote Authentication Dial-In User Service (RADIUS), certificate-based device identity, and periodic access review.
• Segmentation: use VRFs, VNs, SGTs, firewall zones, microsegmentation, host policy, and explicit route leaking. Test both allowed and denied paths.
• Boundary inspection: route internet, partner, cloud, remote access, and sensitive east-west flows through approved inspection points.
• Encryption: use Transport Layer Security (TLS), Internet Protocol Security (IPsec), Media Access Control Security (MACsec), and Federal Information Processing Standards (FIPS)-validated cryptographic modules where policy requires them.
• Management plane: separate out-of-band (OOB) management, jump hosts, console access, secrets, key management, configuration repositories, and emergency access.
• Hardening: apply Security Technical Implementation Guides (STIGs), secure baselines, approved images, configuration checks, Endpoint Detection and Response (EDR), and vulnerability scanning.
• Logging and evidence: collect identity logs, flow logs, firewall logs, DNS logs, admin activity, configuration changes, route changes, authentication failures, and denied-policy events into a SIEM and protected storage.
• Resilience: test backup restore, controller failure, firewall failover, identity outage, DNS failure, route withdrawal, log collector failure, and loss of management access.
• Governance: update the SSP after new routes, software as a service (SaaS) integrations, logging targets, backup destinations, identity providers, monitoring agents, vendors, or data exports are added.

Control matrix

Security Control Coverage Matrix

Each security surface needs prevention, enforcement, observation, and proof. Missing one column creates an authorization or operations gap.

Security Services That Need Design Detail

The control stack needs implementation detail because several common services create hidden scope and evidence gaps. DNS, data loss prevention (DLP), vulnerability management, cryptography, and management access are frequent weak points in otherwise well-segmented networks.

Service	Security Need	Concern	Evidence
DNS security	Force internal resolvers, block direct external DNS, log queries, govern DNS over HTTPS (DoH) and DNS over TLS (DoT), and validate Domain Name System Security Extensions (DNSSEC) where applicable.	Rogue DNS can bypass inspection, hide exfiltration, or produce split-horizon confusion.	Resolver policy, firewall denies, DNS logs, sinkhole events, tunneling detection.
Data loss prevention (DLP)	Label CUI, govern email/web/SaaS/object storage, restrict uploads, and preserve blocked-upload evidence.	Encryption, cloud storage, and SaaS exports can move CUI outside the boundary.	DLP alerts, blocked upload logs, approved destination list, exception register.
Vulnerability management	Run authenticated scans where safe, track firmware, prioritize known exploited vulnerabilities, and link exceptions to POA&Ms.	Scanning without ownership creates dashboards, not risk reduction. OT may require passive assessment.	Scan reports, retest records, patch tickets, exception expiry, OT approval.
Cryptography	Document TLS versions, ciphers, certificate lifecycle, key rotation, revocation, Key Management Service (KMS), and Hardware Security Module (HSM) ownership.	FIPS-compatible is not the same as FIPS-validated or correctly configured.	Certificate inventory, crypto baseline, FIPS certificate reference, key rotation log.
Management plane	Use OOB management, privileged workstations, PAM, session recording, role-based access control (RBAC), and break-glass testing.	Admin paths often bypass normal inspection and can become the highest-risk route.	PAM record, AAA log, jump-host capture, break-glass test, access review.

Shared Responsibility Matrix

Responsibility	Typical Owner	Network Implication	Evidence
Impact-level determination	Mission owner and AO	Network design must support the approved boundary and data flow, not invent it.	Boundary decision, data categorization, authorization package.
Cloud service authorization	Cloud service provider (CSP), DISA, FedRAMP, mission owner	Only in-scope CSOs, regions, and services should be used.	FedRAMP package, DoD PA, service-in-scope list.
Routing and segmentation	Network architecture and operations	VRFs, route leaks, firewall paths, campus policy, and fabric overlays must match the boundary.	Routing matrix, policy matrix, route-leak tests.
Identity and privileged access	IAM, security, platform teams	Admin paths require MFA, PAM, AAA, session logging, and break-glass control.	Access review, PAM logs, AAA logs, approval records.
Monitoring and incident response	Security Operations Center (SOC), Network Operations Center (NOC), incident team	Logs must show boundary crossings, denied flows, admin activity, policy changes, and route changes.	SIEM events, retention proof, incident runbooks, tabletop results.
OT safety and availability	OT owner, safety owner, operations leadership	Industrial access must be brokered, logged, and approved without breaking safety requirements.	Industrial DMZ policy, vendor-access records, passive-monitoring output.

Interactive responsibility stack

Inherited Controls Are Only One Layer

Open each layer to see what can be inherited, what must be configured, and what the mission team still owns.

Provider / CSO PA

Useful inherited context, but only for the specific service offering, region, feature set, and support model in scope.

Network boundary

This is where the network team owns route control, VRF/VNI separation, inspection paths, management isolation, cloud/partner handoff, and validation evidence.

Mission workload and AO decision

Application controls, data handling, backup, support artifacts, monitoring, findings, and risk acceptance remain mission-boundary responsibilities.

Procurement And Contracting Controls

Network design can be undermined by contracts that do not match the boundary. If a managed service, SaaS platform, support vendor, logging provider, backup provider, or subcontractor can access CUI, logs, packet captures, screenshots, incident records, or system metadata, the procurement language needs to match the technical design.

Contract Topic	Network / Security Impact	Review Question	Evidence
Service scope	Only approved CSO, region, support model, and managed feature should touch the boundary.	Is every service and support path in scope for the intended use?	Service inventory, provider authorization artifacts, architecture decision record.
CUI handling	Support tickets, logs, crash dumps, and screenshots may contain CUI.	How is CUI handled, stored, transmitted, returned, and destroyed?	Contract clause, support workflow, data-disposition record.
Incident reporting	Security events must move quickly to the mission team and SOC.	What triggers notification, and what evidence is preserved?	Incident clause, notification test, contact roster.
Subcontractors	Third parties can create hidden access and data paths.	Do subcontractor flowdown and support access match the boundary?	Subcontractor list, flowdown clause, access review.
Exit and decommission	Routes, accounts, keys, backups, and retained logs must be closed deliberately.	How are data return, destruction, key revocation, and account removal proven?	Exit checklist, destruction attestation, decommission ticket.

Material Change Gates

Many environments are well controlled on assessment day and drifted six months later. Treat the following changes as boundary-impact events that need security impact analysis, rollback, validation, and evidence updates.

Interactive change gate

Boundary-Impact Change Flow

A material network change should leave behind the same thing a good design does: owner, policy, validation, rollback, and evidence.

Normal change path

Screen for boundary impact, get the right owner approvals, update route/firewall/IAM/logging controls, validate allowed and denied paths, then update the evidence package and SSP when required.

Emergency path

Emergency changes still need bounded execution, rollback, after-action review, evidence capture, and a threshold decision if the change altered scope, data flow, or inherited-control assumptions.

Change	Security Concern	Required Gate	Evidence Update
New route or route leak	Unapproved reachability across VRFs, cloud, partner, or OT boundaries.	Network security review, route-filter test, rollback plan.	Routing matrix, route table, denied-flow proof.
New firewall allow rule	Permanent exception without owner or expiration.	Business owner, inspection decision, review date, log requirement.	Rule ticket, hit counter, SIEM event, expiration record.
New cloud service or region	Service not in scope for the intended authorization.	CSO/region scope review and AO/ISSM threshold decision.	Approved service list, policy export, SSP update.
New logging or backup target	Logs or backups carrying CUI leave the boundary.	CUI-flow review, retention review, access review.	Data-flow diagram, storage policy, access log.
New identity provider or admin path	Privileged access bypasses MFA, PAM, or session recording.	IAM/PAM review, break-glass test, role review.	Access matrix, session capture, approval record.
OT vendor access	Direct reach to controllers or safety systems.	OT owner approval, maintenance window, session recording.	Vendor log, firewall rule, passive-monitoring record.
New data export or SaaS integration	CUI leaves the approved system path.	DLP review, destination approval, contract review.	DLP policy, export log, data owner approval.

High Availability And Failure Domains

High availability is not only dual links and redundant switches. An IL5-aware environment needs failure-domain thinking for identity, DNS, NTP, PKI, PAM, logging, backup, firewall state, route policy, controller clusters, cloud circuits, and OOB management. Decide which failures should fail closed, which may fail open under mission-approved degraded mode, and which require manual approval.

Failure Domain	Design Question	Preferred Behavior	Evidence
Campus access closet	Can managed endpoints retain policy during uplink or switch failure?	Redundant uplinks, documented NAC behavior, no broad fallback VLAN.	Closet failover test, endpoint policy log.
Leaf/spine/border	Does route convergence preserve inspection and segmentation?	ECMP convergence without route leak or firewall bypass.	Route withdrawal test, flow test, firewall log.
Firewall / service insertion	Does failover preserve state and policy?	Fail closed or mission-approved degraded mode.	Firewall failover report, denied-flow test.
Identity / PAM	Can admins and users authenticate safely during outage?	No shared accounts; break-glass path is approved and logged.	Break-glass test, access review, session record.
DNS / NTP / PKI	Can core services fail without breaking validation or logging?	Redundant services with monitored integrity.	Resolver test, time-source check, certificate validation.
SIEM / log storage	What happens when log forwarding fails?	Local buffering, alert on failure, protected retention.	Log pipeline failure test, retention proof.
Backup / recovery	Can the environment recover from deletion or ransomware?	Immutable backups, separated admin, restore tested.	Restore test, backup access review, recovery record.

Validation Test Matrix

A design review is not complete until engineers can validate the controls. The point is not to produce a perfect screenshot set. The point is to create evidence that an assessor, security engineer, and network engineer can independently understand.

Test	Expected Result	Evidence Artifact
Approved services and regions	Only services, regions, images, and managed features in scope for the intended authorization are used.	Cloud inventory, service-scope list, policy compliance export.
Public exposure	No public Internet Protocol (IP) address, listener, or route exists unless explicitly approved and inspected.	External scan, cloud configuration export, firewall rule review.
Campus segmentation	User, admin, guest, IoT, OT, and security-tooling segments can reach only approved destinations.	NAC logs, firewall logs, denied-flow tests, policy matrix.
Data center route leak	Only approved prefixes move between VRFs or VNIs, with route filters and logs.	Border Gateway Protocol (BGP) table, route-map export, packet test.
East-west inspection	Sensitive workload-to-workload flows hit the expected enforcement point.	Firewall logs, IDS/IPS events, workload policy, flow records.
Management access	Administration requires MFA, least privilege, session logging, and approval.	PAM session record, AAA log, change ticket, break-glass test.
Encryption	TLS, IPsec, MACsec, or other approved encryption is active where required.	Configuration export, packet capture, certificate inventory, FIPS validation reference.
OT boundary	Cloud, campus, and user networks cannot directly reach controllers or safety systems.	Industrial DMZ rules, denied-flow test, vendor access log.
Logging pipeline	Authentication, flow, DNS, firewall, admin, and policy-change logs reach SIEM and protected storage.	SIEM query, retention settings, log-integrity evidence.
Recovery	Backups restore, routes reconverge, and critical logs remain available after failure.	Restore test, failover report, RTO/RPO record.

Evidence flow

Validation Evidence Pipeline

Every design claim needs a testable artifact. A diagram without evidence is not enough for authorization readiness.

Audit Evidence Catalog

Control Family	Network Evidence	Owner	Freshness	System Of Record
Access Control (AC) / Identification and Authentication (IA)	MFA policy, PAM sessions, AAA logs, access reviews, device identity records.	IAM and security	Monthly or per change	IAM, PAM, SIEM
Audit and Accountability (AU)	Firewall logs, flow logs, DNS logs, admin activity, route changes, retention proof.	SOC and NOC	Continuous	SIEM and log archive
Configuration Management (CM)	Golden configs, STIG output, drift detection, change records, rollback tests.	Platform and network operations	Per change	Configuration repository
System and Communications Protection (SC)	Segmentation matrix, route filters, encryption settings, boundary inspection logs.	Network security	Quarterly or per change	Firewall manager, route repository, SIEM
Contingency Planning (CP) / Incident Response (IR)	Restore tests, failover results, incident tickets, tabletop records.	Operations and incident team	Quarterly or exercise-based	Backup system, IT service management, SIEM
Risk Assessment (RA) / System and Information Integrity (SI)	Vulnerability scans, exception register, retest records, known exploited vulnerability triage.	Security engineering	Continuous	Scanner, POA&M tracker
Supply Chain Risk Management (SR)	Service scope, support terms, subcontractor access, vendor evidence.	Procurement and vendor owner	Contract renewal or service change	Contract repository

Common Overclaims To Avoid

• "FedRAMP High equals IL5." FedRAMP High is important, but IL5 also depends on DoD-specific requirements, separation, personnel access, service scope, and authorization decisions.
• "The cloud region is IL5, so the workload is IL5." The exact service, feature, region, support model, tenant configuration, and mission boundary still matter.
• "Encryption removes scope." Encryption reduces risk. It does not automatically remove CUI handling, storage, logging, backup, or support paths from scope.
• "VLANs are segmentation." VLANs can help attach devices. Enforcement requires routing boundaries, policy, inspection, identity, and logs.
• "Zero Trust is a product." Zero Trust is an operating model built from identity, device posture, least privilege, telemetry, policy enforcement, and continuous evaluation.
• "Scanning means authorization readiness." Vulnerability scans are one evidence source. Authorization readiness also needs architecture, policy, ownership, incident response, recovery, and continuous monitoring.

Implementation Sequence

1. Confirm data categorization, CUI categories, NSS status, and AO expectations.
2. Define the authorization boundary: users, workloads, networks, management, security tools, backups, support paths, cloud links, OT links, and external dependencies.
3. Select authorized services and regions. Confirm CSO, service, feature, and support-path scope before building.
4. Build the landing zone: identity, private connectivity, routing, DNS, logging, egress control, key management, backup, and management access.
5. Design campus segmentation: NAC, device posture, wireless, guest, admin, OT, printer, voice, IoT, and user policy.
6. Design data center segmentation: underlay, overlay, VRFs, VNIs, route leaks, east-west enforcement, storage, backup, and management paths.
7. Define OT boundary controls with safety-owner approval, passive visibility, industrial DMZ design, and vendor remote-access rules.
8. Apply hardening: STIGs, baselines, patching, vulnerability scanning, EDR, configuration-as-code, and peer review.
9. Instrument evidence: SIEM, flow records, audit logs, configuration history, access reviews, backup tests, and incident records.
10. Run validation tests before assessment and repeat them after material changes.

Lifecycle Governance

The design does not stop at deployment. An IL5-aware network has to keep its security posture and evidence trail true while routes, identities, cloud services, vendors, firmware, certificates, workloads, and mission needs change.

Lifecycle Stage	Network / Security Work	Governance Output
Design	Define data flows, authorization boundary, service scope, routing, segmentation, management, logging, backup, and OT dependencies.	Architecture decision records, boundary diagram, policy matrix.
Build	Implement landing zone, fabrics, identity paths, firewalls, DNS, logging, encryption, backup, and management controls.	Configuration repository, baseline exports, implementation checklist.
Assess	Run denied-flow tests, route-leak tests, failover tests, admin-access tests, logging tests, and restore tests.	Validation package, evidence catalog, POA&M entries.
Operate	Monitor route changes, authentication, firewall policy, DNS, cloud service use, endpoint posture, vulnerabilities, and OT boundary events.	Continuous monitoring dashboard, SIEM alerts, exception register.
Change	Review new routes, new services, vendor access, support paths, data exports, certificate changes, and logging or backup targets.	Security impact analysis, updated SSP, rollback and retest evidence.
Recover	Test restore, failover, break-glass access, incident communications, log preservation, and return-to-service sequencing.	Incident record, recovery test, lessons learned, control updates.
Decommission	Remove routes, accounts, keys, firewall rules, certificates, backups, monitoring agents, and vendor access.	Decommission ticket, destruction record, access-removal proof.

Interactive lifecycle loop

Keep The Boundary True Over Time

Each lifecycle stage changes the evidence set. The loop is the operating model behind the topology.

What changes in each loop

The topology, control mapping, route policy, evidence catalog, and SSP must stay synchronized. A change that is not reflected in evidence becomes an operations problem first and an authorization problem later.

Final Thought

An IL5-aware network is less about a special topology and more about disciplined boundaries. The campus fabric must know who and what is attaching. The data center fabric must make route and workload policy explicit. The OT boundary must protect safety and availability. The security stack must produce evidence. The operating model must keep the SSP current when the network changes. That is the difference between a security-oriented diagram and a network that can support a formal authorization review.

References

• DISA: DoD Cloud Authorization Process
• DoD Cloud Security Playbook Volume 1
• Microsoft Azure: Department of Defense Impact Level 5 overview
• DoD Zero Trust Strategy
• DoD Zero Trust Reference Architecture Version 2.0
• NIST SP 800-207: Zero Trust Architecture
• NIST Risk Management Framework
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations
• NIST SP 800-53 Rev. 5: Security and Privacy Controls
• NIST SP 800-137: Information Security Continuous Monitoring
• NIST SP 800-171 Rev. 3: Protecting CUI in Nonfederal Systems
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• National Archives CUI program
• FedRAMP: What is in an authorization package
• FedRAMP documents and templates
• NIST Cryptographic Module Validation Program: FIPS 140-3 standards
• DoD Cyber Exchange: Security Technical Implementation Guides
• DISA: DISN Connection Process Guide
• Electronic Code of Federal Regulations (eCFR) 48 Code of Federal Regulations (CFR) 252.239-7010: Cloud Computing Services
• eCFR 48 CFR 252.204-7012: Safeguarding Covered Defense Information and Cyber Incident Reporting
• eCFR 48 CFR 252.204-7021: Contractor Compliance With the Cybersecurity Maturity Model Certification Level Requirements